WO2011044621A1

WO2011044621A1 - Need matching and tracking system

Info

Publication number: WO2011044621A1
Application number: PCT/AU2010/001346
Authority: WO
Inventors: Lapmun Leung; Sachin Sharma; Sudeep Karki
Original assignee: Shalaki Pty Ltd
Priority date: 2009-10-16
Filing date: 2010-10-12
Publication date: 2011-04-21

Abstract

Disclosed is a need matching and tracking system having a first client-side interface operated by a first user for submitting a need of the first user, the need specifying a plurality of requirements characterising the need; one or more second client-side interfaces operated by one or more second users for submitting a plurality of offers in response to the need, each offer specifying a plurality of details characterising the offer, and at least one of the plurality of offers specifying a detail not specified by the plurality of requirements; a database for storing the need and the plurality of offers, the database being in communication with the first client-side interface and the second client-side interface; and a web server for presenting the need to a plurality of users. The first client-side interface effects browsing and consideration by the first user of all submitted offers, and further facilitates the selection of one offer out of the plurality of submitted offers for acceptance by the first user.

Description

Title of Invention: NEED MATCHING AND TRACKING SYSTEM Technical Field

[1] The disclosed invention relates to a system and method for advertising needs,

matching needs, and making offers on advertised needs. More specifically, the disclosed invention relates to an online system and method for allowing a first user to advertise a need, and a second user to submit and negotiate an offer to the first user's need, in an environment guided and controlled by the system.

Background

[2] In a traditional economy, people who have a need for a particular goods or service visit a goods and services provider to have their need met. Often, people visit several goods and services providers in order to secure competitive prices and/or quality. Such practices are time consuming, and further limited by an individual's local knowledge, knowledge of their need, networks, geography, and the like.

[3] Often, comparisons are made between offers from only well-known providers and/or providers that a person knows. Moreover, such comparisons are often made on goods or services that are not in fact the most suitable goods/services for the person's need, but the comparison is nonetheless made because the person knows of no better alternative solution to their need. This places a limit on the person getting the best offer and/or the best goods/service for their need.

[4] On the providers' side, providers rely mostly on potential clients to contact them. In order to generate a sufficient base of clientele, providers pursue generally indirect means such as advertising and word-of-mouth in order to lure clientele to them. There exist few direct means that allow providers to directly contact clients having known needs, which needs the providers feel they can offer a solution for. Moreover, providers of different goods and services can often accomplish the same or similar result, albeit by different means. However, different providers of goods or service rarely have an opportunity to speak to a person with a need about how their particular goods or service could meet that person's need.

[5] It would be desirable if people with needs for a goods or service were able to more efficiently compare between the goods and services offered by various providers, and to receive learned input on various solutions to their needs. It would further be desirable if providers were able to more directly contact clients with known needs, and offer solutions that clients may not have considered or known about.

Disclosure of Invention

Summary [6] According to an aspect of the present disclosure, there is disclosed is a need matching and tracking system having a first client-side interface operated by a first user for submitting a need of the first user, the need specifying a plurality of requirements characterising the need; one or more second client-side interfaces operated by one or more second users for submitting a plurality of offers in response to the need, each offer specifying a plurality of details characterising the offer, and at least one of the plurality of offers specifying a detail not specified by the plurality of requirements; a database for storing the need and the plurality of offers, the database being in communication with the first client-side interface and the second client-side interface; and a web server for presenting the need to a plurality of users. The first client-side interface effects browsing and consideration by the first user of all submitted offers, and further facilitates the selection of one offer out of the plurality of submitted offers for acceptance by the first user.

Description of Drawings

[7] Fig. 1 illustrates a need matching and tracking system according to the present

disclosure.

[8] Fig. 2 illustrates a process of registering a User.

[9] Fig. 3 illustrates a process of submitting a Need.

[10] Fig. 4 illustrates a process of making an Offer.

[11] Fig. 5 illustrates a process of clarifying a Need.

[12] Fig. 6 illustrates a process of clarifying an Offer.

[13] Fig. 7 illustrates a process of amending a Need.

Detailed Description

[14] Disclosed is a system that allows a first group of users to advertise a particular need (hereinafter referred to as a 'Need' or 'Needs') to a second group of users , and for the second group of users to offer one or more particular solutions (hereinafter referred to as an 'Offer' or Offers) to an advertised Need. The Offers accepted by the system need not exactly match the Need, and may instead be an alternative to the originally advertised Need. The first group of users having a particular Need are hereinafter referred to as 'Needers', while the second group of people offering a particular solution to an advertised Need are hereinafter referred to as 'Vendors'.

[15] The Needs advertised by Needers in the system seek to attract Offers from Vendors.

The Offers submitted by Vendors may indicate a direct servicing of an advertised Need (e.g. a price for the exact goods/service) or may indicate an alternative proposal and preferably including a reason why the alternative proposal is a suitable or better solution to the advertised Need. The Offers submitted by various Vendors are reviewed by the Needer, and the system allows for further negotiation and clarification between the Needer and the Vendors, all of which are recorded by the system. Ultimately, the most appealing Offer (if any) after all negotiation between a Vendor and a Needer is concluded is chosen by the Needer.

[16] In an exemplary operation, a Needer who has a Need to go on a holiday to Europe advertises their Need on the system. Additional details may be added by the Needer to their advertised Need, such as activities they wish to partake in while in Europe, when they would like to travel, how they want to travel , and so forth . Once the Need for a holiday to Europe is finalized by the Needer, the system advertises this Need to the attention of potential Vendors. One of more Offers to the Need are received by the system from Vendors, and forwarded to the Needer. The one or more Offers may include itineraries that exactly match that requested by the Needer, and itineraries that do not exactly match that requested by the Needer. The disclosed system provides an opportunity for the Needer to review each of the one or more Offers received from the Vendors, and to negotiate/clarify with the one or more Vendors regarding respective Offers. The disclosed system also provides an opportunity for each of the one or more Vendors to initiate negotiation/clarification with the Needer to better explain their Offer, and/or answer queries from the Needer.

[17] Negotiations/clarifications exchanged between the Needer and a specific Vendor are kept private between the Needer and the specific Vendor. As a result of one or more exchanges of negotiations/clarifications between a Needer and a specific Vendor, the Needer may submit an amendment to the originally advertised Need and have this amendment attached to the originally advertised Need as an addendum, available for all other Vendors to view.

[18] All negotiations/clarifications exchanged between a Needer and a specific Vendor, and all amendments to the originally advertised Need are recorded by the system. In this manner, a 'paper trail' that beings from the originally advertised Need and ends at a finalised, and mutually agreed upon Offer (which may be vastly different to the originally advertised Need) is established. A level of security and certainty is hence provided to both the Vendor and Needer in the case of possible disputes.

[19] The system of the disclosed invention, unlike conventional online auction and

shopping sites, takes away the burden of searching, researching, and shopping from the Needer and instead places the Needer in a default position for obtaining competitively priced and tailored solutions to their Needs. Importantly, the system of the disclosed invention allows Offers that do not exactly match the originally advertised Need to be submitted for the consideration of the Needer, and thereby present the Needer with a variety of solutions which the Needer may not have considered or known about. Additionally, the system of the disclosed invention provides more initiative and proactive power to the Vendors, to sell, market, and educate the public about their goods and services.

[20] Users of the system may be both a Needer and a Vendor, at the same time or at

different times. As a Vendor, users are provided with an opportunity to set up a Vendor Profile. The Vendor Profile allows the Vendor to provide information about their area of expertise, qualification, technical field, industry, and the like, which information is viewable by Needers. Further, the Vendor Profile allows a Vendor to indicate one or more categories of Needs in which the Vendor is interested, and to thereby be automatically notified of Needs advertised under such categories. In a preferred embodiment, the system analyses a user's Vendor Profile and automatically links the Vendor with categories of Needs which the system believes may be of relevance (e.g. categories of Needs which may be serviceable by the Vendor) to the Vendor.

[21] By way of a user's Vendor Profile, the user is automatically notified of newly

submitted Needs that match their Vendor Profile. Newly submitted amendments of existing Needs are also matched to Vendors by way of Vendor Profiles, to determine if any new Vendors may be newly relevant to an advertised Need as a result of an amendment made to the originally advertised Need.

[22] In a similar fashion to the Vendor Profile, users as Needers, are provided with an opportunity to set up a Needer Profile. The Needer Profile allows Needers to provide information about their hobbies, activities, interests, tastes, style, and the like, which the system uses to identify with one or more Vendors whose goods/services may be of interests to the Needer.

[23] Fig. 1 illustrates an implementation of the system 1-1000 of the disclosed invention.

The system 1-1000 includes clusters of Web Servers 1-10, Database Servers 1-20, and Communications servers 1-30 , and a payment gateway 1-40. The Web Servers 1-10 serve user requests by interacting with the Database Servers 1-20 and the Communications servers 1-30 and acting as an interface between users 1-50 and the Database Servers 1-20 and Communications servers 1-30. Importantly, the web servers 1-10 generate and serve interfaces to the users 1-50, and by which interfaces the users 1-50 of the system access the system 1-1000 using client-side devices 1-60. The Database Servers 1-20 are used to persist and retrieve data, and in particular to store all details of Needs, Offers, and Users. The Communications servers 1-30 provide various notification services such as email, SMS, RSS feeds, broadcasting, intra-system

messaging, and the like. The payment gateway 1-40 provides a secure channel to and from payment authorities such as credit card authorities (e.g. Visa, American Express, Diners, Mastercard, etc.), banks, digital currency authorities (e.g. PayPal™), and the like.

[24] The Web Servers 1-10 are accessible via a network, such as the Internet 1-70, and via the interfaces generated and served by the web servers 1-10. The interfaces generated by the web-servers are for example web pages or web portals which are presented on an Internet accessible device 1-60. By way of interaction with the interfaces, the functions of browsing Needs stored in the Database Servers 1-20, submitting Needs to the Database Servers 1-20, making Offers to Needs stored in the Database Servers 1-20, registering with the system 1-1000, and all other user-permitted system interactions are facilitated.

[25] An operation of the system 1-1000 is described with reference to Figs. 2 to 7.

[26] Beginning with a registration process illustrated in Fig. 2, a new user enters identification and other personal details with the Database Server via a web page presented by the Web Server (step 2-10). The identification and personal details entered by the new user include, for example, whether the new user is an individual, business, company, or other legal entity, name, address, contact details, interests, hobbies, description of their business (if any) and expertise, areas/industries of relevance, payment methods, and so forth. As part of the registration process, the system 1-1000 preferably attempts to build a Vendor Profile and Needer Profile for the user (step 2-20), and links the newly registered user with relevant categories of advertised Needs, and also with relevant Vendors who may offer goods/services of interest to the user (step 2-30). Additions and changes to a user's Vendor Profile and Needer Profile may be manually submitted by the user at any time after the registration process.

[27] Following registration, the system 1-1000 is open to the user to advertise a Need, browse advertised Needs, submit Offers to Needs, further update their Vendor/Needer Profile, user details, and the like.

[28] Referring to Fig. 3, a process of posting a need on the system 1-1000 is described. At step 3-10, a user accesses the system 1-1000 via an interface generated and served by the Web Servers 1-10. At step 3-20, the system 1-1000 confirms that the user is a registered user, and if the user is not a registered user the user is forwarded to the aforementioned registration process (steps 2-10 to 2-30). Otherwise, the user acting as a Needer is presented with their home page at step 3-30, from which a link to a form for advertising a new Need is accessed and filled in (step 3-40). The form for advertising a new Need includes, but is not limited to, input fields for:

1. Type of Need (i.e. buy, sell, swap, lease, joint venture, finance needed,

finance offered, custom, etc.)

2. Short description

3. Long description

4. Cost of Need

5. Delivery charges and mechanism

6. Location of Goods/Service

7. Classification/Category of Need 8. Contact details

9. Expiry Date

10. Evaluation End Date

11. Quantity needed

12. Quality desired

13. Additional documents (i.e., Images, Designs, Videos, Presentations,

Brochures, Text documents, Scans, Blue prints, etc.)

[30]

[31] At step 3-50, a new Need is submitted to the Database Servers 1-20 upon the

submission of one or more of the above details. Additional documents may be optionally submitted with the above Need, which documents may comprise specific terms and conditions, contract clauses, further explanations of the Need, warranties, documents to be signed/witnessed, forms to be filled out, certificates, and the like. Preferably, the types of documents that may be submitted are limited by the system 1-1000, whereby the submission of malicious files is prevented. At step 3-60, the system 1-1000 verifies all details and calculates applicable charges in a system-unique currency known as 'neps', described later below. The user's account is checked for a sufficient balance of 'neps' at step 3-70. If the Needer has insufficient 'neps' in their account, the Needer is first prompted to buy additional 'neps' to proceed (step 3-80). The system 1-1000 then debits the user's account for payable 'neps', and activates the Need for other users to search for it (step 3-90) by indicating in the Database Server that the submitted Need is now active.

[32] Upon activation of the Need, the system 1-1000 notifies relevant Vendors of the newly advertised Need (step 3-100). Vendors who are relevant to a Need are identified via their Vendor Profiles. The notifications sent to the relevant Vendors are effected by the Communications servers 1-30, using means such as email, SMS, RSS feed, custom integration, intra-system messaging, and the like.

[33] With reference to Fig. 4, a process of making an Offer to a Need on the system

1-1000 is described. Steps 4-10 and 4-20 are the same as those of steps 3-10 and 3-20 in Fig. 3, and confirm that a user has been registered with the system. At step 4-30, the user acting as a Vendor is presented with their homepage where they may either browse advertised Needs, or in the case of responding to an automatic notifications sent by the Communications server 1-30, be presented with one or more advertised Needs that the system 1-1000 believes matches their Vendor profile. At step 4-40, the Vendor identifies a Need to which they would like to make an Offer, and fills in an Offer Form attached to the advertised Need. The Offer Form requests details such as:

[34] 1. Short description

2. Long description 3. Cost of Offer

4. Delivery charges and mechanis

5. Location of Goods/Service

6. Contact details

7. Expiry Date of Offer

8. Quantity offered

9. Quality of Offer

10. Additional documents

[36] At step 4-50, an Offer to the advertised Need is submitted upon the provision of one or more of the above details. As with the process of advertising a Need, the additional documents may comprise specific terms and conditions attached with the Offer, contract clauses, further explanations of the Offer, warranties, documents to be signed/ witnessed, documents that have been signed/witnessed, plans/schematics, and the like. Preferably, the types of documents that may be submitted are limited by the system 1-1000, whereby the submission of malicious files is prevented. At step 4-60, the system 1-1000 verifies the details submitted by the Vendor, and calculates any charges applicable in 'neps'. Then, the system 1-1000 determines if the user's account has sufficient 'neps' (step 4-70). If the Vendor has insufficient 'neps', the Vendor is prompted to first purchase more 'neps' (step 4-80). The system 1-1000 then debits the user's account for payable 'neps', and activates the submitted Offer at step 4-90 by indicating in the Database Server that the submitted Offer is now active.

[37] Upon activation of the Offer, the owner of the Need is notified of the newly activated Offer by the Communications server 1-30 using means such as email, SMS, RSS feed, custom integration, intra-system messaging, and the like (step 4-100).

[38] The storing of the submitted Offer in the Database Server serves as a 'paper trail' detailing any changes to the originally advertised Need, secondary agreements between the Needer and the Vendor, additional/revised terms and conditions, and the like.

[39] With reference to Fig. 5, a process for clarifying and/or negotiating a Need is

described. The process for clarifying and/or negotiating a Need allows Vendors to seek more information on a Needer's Need, in particular, for situations where the Needer does not appear to be well versed with the subject matter of their Need, where the Needer has provided inaccurate, ambiguous, or contradictory information, and the like. This process further allows a Vendor to educate the Needer on how a Vendor's specific goods/service can resolve the Needer's Need, in particular for cases where the Offer submitted by the Vendor is not an Offer that the Needer had originally considered, or knew existed.

[40] At step 5-10, a user acting as a Vendor identifies a Need to clarify and is presented with a request-for-clarification form attached to the identified Need, for submitting a request for clarification. The form for submitting a request for clarification is preferably relatively open-ended, allowing the Vendor to express themselves freely, as opposed to being a structured form with specific and limited input fields. The form further preferably allows the Vendor to attach additional documents such as those described previously. The Vendor inputs into the form the nature of the clarification required, and/or an explanation of a Vendor's Offer to the advertised Need, and/or other constructive comments. If necessary, the Vendor also attaches to the form any additional documents such as diagrams, schematics, photos, legal documents, and so forth.

[41] At step 5-20, the Vendor submits the request for clarification form, which form is then stored in the Database Servers 1-20. The system 1-1000 attaches the submitted request-for-clarification form to the original Need (step 5-30), but is viewable only by the Vendor who submitted the form and the Needer. At step 5-40, the Communications servers 1-30 to notify the owner of the Need of the request for clarification. At step 5-50, the owner of the Need is presented with the request-for-clarification form, and receives a response form that is similarly relatively open-ended and unstructured and allows for additional documents to be attached, in which form further clarification of the Need is provided. At step 5-60, the clarification is submitted to and stored in the Database Servers 1-20, and attached to the identified Need. At step 5-70 the Communications servers 1-30 notify the Vendor that a clarification from the Needer has been provided.

[42] Figure 6 illustrates a process for clarifying and/or negotiating an Offer. The process for clarifying and/or negotiating an Offer allows a Needer to seek more information from one or more Vendor regarding their respective Offers. In this manner, the Needer is able to query a Vendor on their Offer in situations, for example, where a submitted Offer is substantially different to that of the advertised Need.

[43] At step 6-10, a user acting as a Needer identifies an Offer previously submitted to the Needer's advertised Need, and is presented with a request-for-clarification form attached to the identified Offer. The form for submitting a request for clarification is preferably relatively open-ended, allowing the Needer to express themselves freely. The form further preferably allows the Needer to attach additional documents such as those described previously. The Needer inputs into the form the nature of the clarification required, and attaches thereto any additional documents if necessary.

[44] At step 6-20, the request-for-clarification form is submitted, which form is then

stored in the Database Severs 1-20. The system 1-1000 attaches the submitted request- for-clarification form to the identified Offer (step 6-30), and is viewable only by the Needer and the Vendor who submitted the identified Offer. At step 6-40, the Commu- nications servers 1-30 notify the owner of the identified Offer of the request for clarification. The owner of the identified Offer is presented with the request- for-clarification form, and receives a response form that is similarly relatively open- ended and unstructured, and which allows for additional documents to be attached. At step 6-50, the Vendor provides further clarification of the Offer in the response form and the clarification is submitted to and stored in the Database servers 1-20. At step 6-60, the clarification is attached to the Offer, and made viewable to the Needer and owner of the identified Offer. At step 6-70, the Communications servers 1-30 notify the Needer that a clarification from the Vendor has been provided.

[45] The requests for clarification, and the corresponding clarifications sent in reply are time stamped to indicate chronological order. Multiple requests for clarification and clarifications may be exchanged between Vendors and the Needer, to ultimately result in an alteration of the originally advertised Need and the originally submitted Offer such that a finally agreed-upon arrangement between the Needer and the Vendor may be substantially different to that of the originally advertised Need. The storage of the requests for clarifications from the Vendor and the clarifications provided by the Needer in the Database Servers 1-20 serve as a 'paper trail' that evince the final agreement between the Vendor and the Needer.

[46] The requests for clarification and the clarifications exchanged between Vendors and the Needer, including any additional documents submitted therewith, are private and made viewable only to the Vendor and the Needer. Moreover, these exchanges are the only means of contact and communication between Vendor and Needer provided by the system 1-1000. In this manner, a complete 'paper trail' of the exchanges between Vendor and Needer is stored by the system 1-1000, whereby any future disputes between Vendor and Needer can be more readily resolved.

[47] Figure 7 illustrates a process of amending a Need, resulting in a re-categorizing of the Need and a search for newly relevant Vendors.

[48] At step 7-10 a Needer identifies a Need to amend, and submits an amendment form at step 7-20. At step 7-30, the amendment form is attached to the Need for public view, but the originally advertised Need is not itself changed. At step 7-40, the system 1-1000 re-categorizes the Need based on the submitted amendments, and records any changes of category in the Database servers 1-20. At step 7-50, the Vendor Profiles stored in the Database severs 1-20 are again searched (the first search having occurred when the Need was first activated - see step 3-90), and any newly found relevant Vendors notified of the identified Need and its attached amendment form.

[49] The system 1-1000 of the disclose invention preferably charges Vendors and Needers a system-specific currency known as 'neps' for respectively submitting an Offer and submitting a Need. It should be understood, however, that either the Vendor or the Needer may be instead charged, rather than charging both parties. Units of 'neps' are purchasable using real currency, and by way of various payment methods such as credit cards, debit cards, bank/wire transfers, PayPal™, and the like. Payment between Vendors and Needers is preferably also conducted in 'neps'.

[50] In conducting transactions between Vendors and Needers, and between users and the system, in 'neps', the complexities with arranging payment between international parties, parties which accept one method of payment and not another, parties which have available to them only selected methods of payment, and the like, are ameliorated.

[51] Using the system-specific currency of 'neps', users of the system 1-1000 are required to transact using real currency with only a single party, namely the system. Accordingly, costs such as currency exchange fees/commissions, bank/wire transfer fees, postal cheque fees, and the like are minimized in view that a fewer number of large transactions can be made to purchased a stockpile of 'neps', compared with a larger number of small transaction which would have to be made if real currency were transacted for each purchase. Further, the likelihood of users being able to pay via a preferred payment method is increased since the system is more likely to offer a wider range of payment methods, than an individual user.

[52] The purchase of 'neps' using real currency is facilitated by way of the payment

gateway 1-40 and a payment webpage presented by the Web Servers 1-10. The cost of 'neps' is preferably floated against accepted real currencies, such that the cost of a 'nep' rises and falls in accordance with the strength of the real currency being used in a purchase of 'neps'.

[53] Although the invention has been described herein with reference to a number of specific embodiments, it will be appreciated by those skilled in the art that the invention can be embodied in many other forms.

Claims

A need matching and tracking system, comprising:

a first client-side interface operated by a first user for submitting a need of the first user, the need specifying a plurality of requirements characterising the need;

one or more second client-side interfaces operated by one or more second users for submitting a plurality of offers in response to the need, each offer specifying a plurality of details characterising the offer, and at least one of the plurality of offers specifying a detail not specified by the plurality of requirements;

a database for storing the need and the plurality of offers, the database being in communication with the first client-side interface and the second client-side interface; and

a web server for presenting the need to a plurality of users, wherein

the first client-side interface effects browsing and consideration, by the first user, of all submitted offers, and

the first client-side interface further facilitates the selection of one offer out of the plurality of submitted offers for acceptance by the first user.

The need matching and tracking system according to claim 1, further comprising a communications server for facilitating negotiation between the first user and one of the second users regarding the need and an offer corresponding to the one second user, and wherein the database further stores all negotiation between the first user and the second user.

The need matching and tracking system according to claim 2, wherein the communications server further facilitates the exchange of documents between the first user and the second user, and the database further stores all documents exchanged between the first user and the second user.

The need matching and tracking system according to claim 1, wherein the first client-side interface communicates with the database to present all of the plurality of offers to the first user.

The need matching and tracking system according to claim 4, wherein the first client-side interface effects communication between the first user and the database, the connection enabling the first user to select one offer out of the presented offers.

The need matching and tracking system according to claim 1, further comprising a communications server for facilitating communication between the system and the first user, between the system and the second user, and between the first user and the second user.

The need matching and tracking system according to claim 6, wherein the communications server automatically notifies one or more second users of the submitted need upon the first client-side interface submitting the need, the one or more second users being determined by the database to be relevant to the submitted need.

The need matching and tracking system according to claim 2, wherein the database further stores a vendor profile for each second user, the vendor profile indicative of a goods or service suppliable by the second user, and

the communications server notifies selected second users of the need upon the first client- side device submitting the need, the selected second users being selected in accordance with the vendor profile corresponding to each second user.

The need matching and tracking system according to claim 8, further comprising a first client-side device for presenting the first client-side interface to the first user, and one or more second client-side devices for presenting the one or more second client-side interfaces to the one or more second users.

A need matching and tracking method for matching a need of a first user with the goods and services of one or more second users, the method comprising the steps of:

receiving details of the need from the first user and storing the need in a database, the need specifying a plurality of requirements characterising the need;

publicly displaying the need on an online networked medium accessible by the one or more second users;

accepting offers via the online networked medium from the one or more second users and storing the offers in the database, the accepted offers containing details characterising each offer, at least one of the offers having a detail not specified by the plurality of requirements;

presenting, via a first client-side interface, all of the accepted offers via the online networked medium to the first user for the first user's review;

allowing and providing communication via the online networked medium between the first user and the one or more second user to negotiate the requirements characterising the need in view of the details characterising each offer;

storing the negotiations between the first user and the one or more second users in the database; and

formalising an offer from one of the second users to the first user, in accordance with the negotiations stored in the database.

The need matching and tracking method according to claim 10, wherein at least one of the offers has a detail mismatched with a corresponding requirement of the need.

The need matching and tracking method according to claim 10, further comprising a step of a communications server effecting communication of one or more negotiations between the first user and the second user, the negotiations being with respect to the need and a corresponding offer, and storing the one or more negotiations in the database.

The need matching and tracking method according to claim 12, further comprising a step of attaching one or more documents to one or more of the negotiations communicated between the first user and the second user.

The need matching and tracking method according to claim 10, further comprising a step of selecting one offer out of the presented offers. The need matching and tracking method according to claim 10, further comprising a step of generating a vendor profile for each second user, the vendor profile being generated in accordance with a goods or service suppliable by the second user.

The need matching and tracking method according to claim 15, further comprising a step of a communications server notifying selected second users of the submitted need upon submission of the need, the selected second users being selected in accordance with a corresponding vendor profile of each second user and the requirements characterising the need.