WO2000041087A1 - Matching service providers with customers and generating product/service sourcing data - Google Patents

Abstract

The computer systems and methods provide a service (101) for qualified members (112) to order goods/services from qualified providers (120) of those goods/services. The service stores a request issued by a member; electronically searches at least one database (109) to identify the providers capable of addressing the request; displays to the member a list of these providers; and forwards the request to the desired providers. The service limits (111) the number of service providers (120) as well as the number of the members (112) who can use the service. The service providers and members are preferably approved (114) by the service before their admission to using the service. The identification of suggested products/services is preferably based on analyzing the request, stored information about the purchasing habits of the service providers and the member issuing the request and on the vendors' product specifications.

Description

COMPUTER SYSTEM AND METHOD FOR MATCHING

SERVICE PROVIDERS WITH CUSTOMERS AND FOR

GENERATION OF PRODUCT/SERVICE SOURCING DATA

FIELD OF THE INVENTION

This invention relates to an electronic marketplace for matching providers of goods and services with customers. It also relates to a system for identifying goods and services useful for responding to an electronic request.

BACKGROUND OF THE INVENTION

Electronic marketplaces employing computer technology and communications over the Internet are well known. They include business-to- business and business-to-consumer marketplaces. Typically, such marketplaces are limited to online catalogues with searching (e.g., by key words) capabilities. It is also known to use the Internet for issuing an electronic request for proposal or quote and receiving a response.

Such known electronic marketplaces, however, suffer from a variety of limitations, which are particularly apparent in business-to-business sites. For example, they do not provide a convenient and sufficiently automated way of enabling a user to issue a request for proposal, identifying the entities suitable for addressing the request and conveniently presenting a list of such provider entities in an unbiased manner. Further, there is a need for a convenient and automated mechanism to provide the request for proposal to several such entities based on a selection made by a user. In addition, traditional electronic marketplaces are largely driven by advertisement revenues and, therefore, in the effort to increase the membership, they do not provide a rigorous qualification process for admitting participants. Thus, typically, the number of participants is essentially unlimited, bound only by the constraints of a computer system supporting the marketplace. Consequently, such marketplaces provide insufficient reliability and integrity for business users. Further, such existing marketplaces frequently charge a commission based on transactions on the marketplace, so that their main concern is the volume of business and not the quality of service. Owners of some of these marketplaces may even offer their services in competition with the users. In brief, there is a need to provide a truly professional marketplace that combines a high level of integrity, ease of customer interaction, and sufficient automation.

In addition, a service provider who receives an electronic request for proposal usually needs to research the products that it should use in order to provide the requested service. Such a search may be difficult and time consuming regardless of whether it is done online or manually. Further, by habit such a service provider may be limited to always using the same products even if better alternatives become available. Thus, there is a need to develop a system that automatically processes a request, such a request for proposal, so as to suggest goods or services that a service provider can use in order to meet the requirements.

SUMMARY OF THE INVENTION

In the preferred embodiment, the disclosed system provides a network- based computer system that implements a service that provides an efficient, secure, and quality marketplace for the Information Technology and Telecommunications requirements of modern businesses. In other embodiments the service can be used for other applications such as financial and industry- specific services. The invention is not limited to any specific industry supported by the marketplace, which can also service multiple industries. Preferably, the system employs communication over the Internet.

The preferred service provides business owners, managers, MIS and procurement professionals and other users (generally referred to as the "members") with reliable sources for Information Technology and . Telecommunications ("IT") goods and services. Preferably, only a limited number of IT firms in specific geographic markets within distinct IT categories participate as providers of goods and services (those firms are called "Information Technology Providers," or "ITPs," or "ITP/members"). In general, the service can be employed for any providers of goods or services to interact with customers. Preferably, the service is a professional, "members only" marketplace. The members are, for example, business owners and managers, MIS, and procurement professionals qualified as such by the service. Members are preferably qualified by membership in professional associations or business organizations. ITP/members (Information Technology Provider companies or ITP's) serve the members. Such entities are generally referred to as providers and are not limited to a specific industry. The providers preferably have achieved and maintained a high degree of competence, excellence and professionalism within their respective fields. Preferably, ITP/members (providers) must maintain specific standards in dealing in the preferred marketplace.

The service facilitates transactions between members and ITP/members through a customized Request for Proposal ("RFP") system. Members have the ability to browse through ITP/member websites or specific brochure-ware for specific services and/or have the service automatically send their RFPs to selected ITPs. In general, the system is not limited to RFP's, but can be used for any other request (e.g., a request for a quote) broadly referred to as a project brief. In general, the terminology, such as RFP, project brief and the like is used interchangeably and should be construed broadly as an electronic request as understood by a person skilled in the art.

The service preferably does not share in any of the revenues generated by ITP/member transactions, nor does it act as consultant for or enter into any business relationship with the ITP/members other than the service itself. The service assures member privacy and security by adhering to strict guidelines and practices on privacy and security, preferably including a certification from TRUSTe or a similar group. Both members and ITP/members must adhere Jo rules of professionalism and behavior when participating in the service. Members and ITP/members are required to report the transactions with the ITP/members in order to insure ITP quality and to provide accountability to members. The preferred service for qualified members and providers executes software that includes the steps of storing a project brief (e.g., request for proposal) issued by a member; electronically searching at least one database to identify the providers capable of addressing the request for proposal; displaying (preferably in a substantially random order) to the member a list of providers that are capable of addressing the request (project brief); selecting desired providers from the list of providers; and forwarding the request for proposal to the desired providers. The project brief (request) can be submitted so that the identity of the user is not revealed.

The system preferably limits the number of service providers as well as the number of its members who can use the sen/ice. This number is determined by the service administration based on the quality considerations and is not based on computer performance constraints. The service providers and members are preferably approved by the system administration before their admission to using the service.

The users of the service necessarily reveal their business practices and preferences as a result of using the service. Such information is valuable to markets and advertisers and is conventionally sold by other electronic marketplace operators without any benefits provided to its users. In the present system, such information is owned by the participants and if it is sold, the participants are paid for data and the service preferably receives a commission.

The preferred system generates a sourcing bar in response to a project brief and forwards it to the service providers and/or members. The sourcing bar provides a list of suggested goods and services that the providers .of the service may be able to use for the jobs specified in the project brief. This information is preferably displayed to each provider and may be attached to the project brief or provided separately thereafter. The identification of such suggested products or services is preferably based on analyzing stored information about the purchasing habits of the service provider and the member issuing the project brief as well as on the vendors' product specifications. Historical information reflecting industry trends in connection with similar requests can also be analyzed. The information considered can be broadly classified into three categories. First, the data specifically included in the project brief and application forms, such as the products explicitly identified as preferred and excluded, is considered the most relevant one. Next in relevance is historical information about the purchasing habits of the specific member and provider. This information may include historical data relating to members' and providers' previous project briefs and the products they customarily chose. Finally, historical information regarding a large cross-section of members, providers and vendors is considered in identifying the products for the sourcing bar. After eliminating irrelevant or explicitly excluded products or services, the system rates the remaining products and services based on the information discussed above and selects the most relevant ones to be included into the sourcing bar.

The service summarized above is implemented using computer technology and discussed in more detail below.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 symbolically illustrates the operation of the system of the preferred embodiment in connection with a request from a potential new user to register with the system.

Figs. 2 and 2A illustrate software steps supporting member's interaction with the preferred service.

Figs. 3 and 3A illustrate software steps supporting ITP/member's (provider's) interaction with the preferred service.

Fig. 4 depicts a preferred record stored in the system database for a member. Fig. 5 illustrates a preferred record stored for an ITP/member (provider).

Figs. 6 - 6G illustrates a methods and systems for membership approval.

Fig. 7 illustrates a member qualification fee process.

Figs. 8 and 8A illustrate a blind RFP process.

Fig. 9 illustrates a reply to a blind RFP process.

Figs. 10 - 10D illustrate ITP/member qualification process.

Figs. 11 and 11 A illustrate member desktop resident interface.

Figs. 12 and 12A illustrate ITP/member desktop resident interface.

Figs. 13 and 13A illustrates member complaint and recommendation procedures.

Figs. 14 and 14A illustrate ITP/member complaint and recommendation procedures.

Fig. 15 illustrates member monthly survey procedure.

Fig. 16 illustrates ITP/member monthly survey procedure.

Fig. 17 illustrates RFP entry and ITP characteristics.

Fig. 18 illustrates identification of relevant ITP(s).

Fig. 19 illustrates a marketplace that combines multiple services. Fig. 20 illustrates an example of a request for proposal (project brief) including an attached sourcing bar.

Fig. 21 illustrates computer processing of a project brief so as to construct a sourcing bar.

Fig. 22 illustrates software steps of sourcing bar construction process.

Fig. 23 illustrates level 1 member searches.

Fig. 24 illustrates level 1 vendor searches.

Fig. 25 illustrates level 1 provider searches.

Fig. 26 illustrates level 1A member searches.

Fig. 27 illustrates level 1 A vendor searches.

Fig. 28 illustrates level 1 A provider searches.

Fig. 29 illustrates level 2 member searches.

Fig. 30 illustrates level 2 vendor searches.

Fig. 31 illustrates level 2 provider searches.

Fig. 32 illustrates a table of relevance values of information .streams.

Fig. 33 illustrates a table of contribution potentials for information sources.

Figs. 34A - 34W illustrate a user interface of one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The service is implemented at least in part using software technology. This software may be hosted on one or more servers and function as an internet application. The system may be configured using a database server and a web server on the same or different hosts. The host machines may run Unix operating system or Microsoft NT operating system. The host hardware can range from Pentium-based to multiprocessing technology.

The service software, which is resident at the host interacts with computers of the users of the service over a computer network. Preferably, the network is the internet and the communication is as known in the art for internet-based services. As known in the art, the communications network can also be a local area network, wide area network, extranet or intranet. A user interacts with a service usually using a personal computer. Such user's personal computers may also be connected into an intra-net network, for example, a network internal to a company, as known in the art. In this case, a user accesses the service over the local network which in turn provides external communication with the service, as known in the art.

Fig. 1 symbolically illustrates the operation of the system of the preferred embodiment in connection with a request from a potential new user to register as a member or ITP/member of the service. As illustrated, the new user accesses the website of the service of the preferred embodiment, as illustrated by 101. Since the user is not yet registered as a member, the login procedure provided for a member of the service is not available to this user. Instead, this user accesses an application page, as illustrated by 103, which displays information that guides the new user through the registration process.

First, the user indicates by making an interactive selection whether he/she desires to become a member or an ITP/member. Based on this information, control flow proceeds to block 104, which denotes computer software that initiates the registration for an ITP/member or 105 which denotes computer software for initiating the registration for a member. If the user desires to become an ITP/member, the system electronically collects the necessary information from the user (as discussed subsequently)at 106 and transmits it for processing to Intellexchange 107. Intellexchange 107 hosts human operators who may be required to make decisions based on the information provided to them by one or more computers executing the software supporting the service of the preferred embodiment. The human operators associated with Intellexchange 107 have access to various computer resources of the system as will become apparent from the subsequent discussion. In other embodiments, and depending on the implementation trade-offs, various functions performed by the operators of the Intellexchange 107 can be replaced by the corresponding computerized processing. Thus, in general, Intellexchange 107 denotes an operations support center where humans assisted by computer resources, and in some instances intelligent automated software, make judgments and decisions supporting proper operation of the service.

For a user who desires to become an ITP/member, the Intellexchange 107 processes the data supplied by the user and makes a determination based on the data entered at 106 and other data described subsequently in connection with Figs. 10 to 10-D.

If, the applicant desires to become an ordinary member, not an ITP/member, the membership request and related information is entered into an electronic form at 108. It should be noted that the data is entered into the system in a conventional fashion as customarily done in on-line (e.g., Internet) services. In response to the data provided by the member, the system initiates a query to a site-resident (i.e., local) database of professional association data .as symbolically illustrated by 109. The system needs to verify the professional association membership because in the service of the preferred embodiment, a person can join the service as a member if he/she is a member of an approved professional association. For this reason, the system of the preferred embodiment stores the membership data from certain professional association databases in its local database. For the other approved applications, the service may also have access rights to the databases resident on the associations' computers.

Based on the specific associations identified by the applicant, the system queries and updates the association data as subsequently discussed in connection with Figs. 6-A to 6-E. If the specified association is not found as one of the approved associations of the service, the processing discussed in connection with Fig. 6-F is performed. The listing of the approved associations, as well as membership data for some of the associations is stored in the associations' local database of the system of the preferred embodiment as symbolically illustrated by 109 and 130. This database also stores membership data for certain associations. It should be noted that Figs. 6-A, 6-B and 6-C relate to the database access techniques where the association databases are accessed electronically and they automatically provide an electronic confirmation of whether a given individual is in fact a member of the specified association. Figs. 6-D and 6-E illustrate a query to an association conducted by a human being through e-mail or other means.

If the specified association database is queried automatically through a software database query, the electronic response is then provided to the association membership interface 110. The interface 110 converts the response to the appropriate format and if the response is positive, transfers control to the certificate server illustrated as 111. The certificate server then issues a member folder, illustrated as 112, which is a record stored for a member of the service in the database of the service of the preferred embodiment. This database is discussed more fully subsequently. A member is also entitled to receive a member-specific interface as discussed in connection with Figs. 11 and 11 -A. Thus, at this point the new member is appropriately required to specify such an interface to the extent it is not already defined by the system.

If a prospective member is not a member of an approved association, the application is processed further at Intellexchange 107. Such an applicant may pay a qualification checking fee in order to be authorized to become a member. Also, as illustrated, certain association membership queries, which are not fully automated, are processed at Intellexchange which may approve a particular applicant in response to information received from a specified association. If an applicant has been approved with an aid of Intellexchange 107, the Intellexchange issues a verification of membership as symbolically illustrated at 114. Then, the new member folder is created as illustrated at 112. A new member also receives an interface as discussed above.

It should be noted that for ITP/members, whose approval process is not fully automated and requires processing by the Intellexchange, the same procedure is followed. That is, when the ITP/member has been approved, the verification 114 is provided to the Certificate Server 111 and the ITP/member folder is opened.

Fig. 2 illustrates software steps supporting members' interaction with the service. The user (member or ITP/member), discussed in connection with Fig. 2, has already been approved to use the service and has been issued a folder and an interface. First, the member accesses the website 101 provided by the service and logs onto the service by entering his/her identification into an electronic form at 201. This identification comprises user's ID and a personal password. The entered information is then confirmed by referring to the corresponding member folder or ITP/member folder stored in the system database. After the identification information has been confirmed, the processing for this user is transferred to the member's site resident interface as shown by 204 and 205. The site resident interface can be downloaded to the member's computer after the login procedure or may reside permanently on the user's screen as discussed more fully below. The homepage may provide information of interest to a particular user or to a user in a certain industry segment in addition to interfaces needed for using the service.

If the member is an ITP/member, the processing proceeds as described below in connection with Fig. 3. (If an ITP/member is acting as a member, he/she is also referred to as a member and Fig. 2 is applicable to his/her interaction with the service). If the current user is a member, control flow is transferred to block 207 where the system provides a user with a capability of electronically entering his/her RFP (Request For Proposal/Query). The request is structured with an aid of an electronic form in which the member enters his/her requirements of a desired service or product. After the system receives this information, at 208 it consults its database and searches for the ITPs that may be able to meet the requirement set forth in the RFP. Other criteria, such as a convenient geographical location for the member, are also considered during the search as understood by a person skilled in the art.

After the search has identified the relevant ITPs, control is transferred to block 209 where the list of ITPs is displayed to the member. This listing also includes links to websites (or other service-specific brochure-ware and other information) of the identified ITPs enabling a user to learn more about these ITPs from their website and/or a capability to display company precis for the selected ITPs.

After the user has completed his/her investigation, he/she specifies the ITPs that he/she wants to consider for the recipient of the RFP/query, see 210. Fig. 18 illustrates a form used by the members for selecting ITPs to whom to forward the RFP/query. As illustrated, it is an electronic form displaying the information regarding the identified ITP and a box next to each ITP allowing the user to indicate whether to submit the RFP/query to this ITP. Based on the data provided by the user, the system electronically sends the RFP to the selected ITPs. This may be accomplished using a "blind RFP" mechanism as discussed in detail in

Figs. 8 and 8-A. In general, the RFP is provided to the mail server shown as 211 which in turn sends the RFP to the mail boxes, e.g., 505, of the specified ITPs. Fig. 20 illustrates an example of an RFP/query that is provided to a designated ITP(in this example ABC Network Consultants). The mail server 211 is also used to provide the replies back to the member.

Fig. 2-A essentially shows the system discussed in connection with Fig. 2 except that the members and ITP/members have their computers already configured in accordance with the present service so that they access the system of the preferred embodiment by indicating an icon that appears on their screens as shown by 250 and 251 and discussed in further detail in connection with Figs. 11 and 12. From the local desktop (i.e., user's computer screen and related functionality), the members and ITP/members enter the website 101 and the processing continues as discussed in connection with the previous Fig. 2.

Fig. 3 shows the steps supporting ITP/member's interaction with the service. An ITP/member enters the service's website 101 and then logs on at 201. His/her identity is confirmed by consulting the ITP/member folder illustrated as 120. Thereafter, the computer screen and related functionality of the ITP/member is configured in accordance with this service as further described in connection with Fig. 12.

An ITP/member can also function as an ordinary member if it is interested in sending a request for a proposal (RFP) as illustrated in Fig. 2. Otherwise, the ITP/member retrieves from its ITP/member folder 120 requests for proposals (RFPs) that it has received and responds to them via e-mail using mail server 211. The mail service 211 provides the responses to the member mail boxes, e.g., 401 , of the members who sent RFPs to this ITP/member.

Fig. 3-A is essentially identical to Fig. 3 except that the ITP/member enters the service using the interface configuration 350 which has already been loaded into the local PC, as discussed in further detail in connection with Fig. 12.

Fig. 4 depicts a typical record stored in the system database for a member. Such a record is also referred to as a member folder. A collection_, of member folders are stored in the database of the system of the preferred embodiment using known database storage techniques so as to provide a convenient access to the records, i.e., member folders. Each member folder comprises member mailbox 401 which receives and stores e-mails as known in the art. A member can receive system-wide mail messages as well as external messages. Sub-record 402 stores member's ID and password as known in the art. The system uses this information to identify the member as an authorized member and also to enable a variety of other tasks such as addressing electronic communications to the member, and keeping appropriate statistics. Sub-record 403 stores transaction information which includes a historical record of the RFPs issued by the member and replies received from the ITP/members. Sub-record 404 stores complaints and recommendations entered by or about a given member. The member folder may store other information specific to a given member. For example, it may store the description of the personalized member interface.

The system database also stores records characterizing the ITP/members. A record kept for each ITP/member is illustrated in Fig. 5, and may be referred to as ITP/member folder. The ITP/member folder includes the ITP/member mailbox 501 which stores incoming and outgoing electronic mail, including incoming RFPs and outgoing replies to the RFPs. It also includes ITP/member ID and password sub-record 502, which allows to identify and authenticate the ITP/member and can be used for other purposes. Similarly, the ITP/member folder includes a sub- record 503 storing transaction information for the ITP/member including the history of received RFPs and RFP replies. The folder also includes sub-record 504 containing a history of complaints and recommendations of a given ITP/member and concerning this member. In addition, the ITP/member folder holds ITP characteristics 505 which includes data describing this ITP. The ITP characteristics are further detailed in Fig. 17. In addition, the ITP/member folder can hold other information such as a configuration of the ITP/member's homepage.

As illustrated in Fig. 17, sub-record 505 comprises ITP category 1701 , ITP location 1702 and ITP size 1703. The field ITP category 1701 specifies the services provided by a given ITP/member. The field ITP location 1702 specifies geographical location of this ITP/member. The field 1703, ITP size, provides the magnitude of jobs that a given ITP is capable of undertaking. Preferably, the ITP size determines the flat fee that an ITP pays for using the service. Referring back to Fig. 2, it illustrates that in response to an RFP defined by a member, the system generates a list of relevant ITPs after consulting the system database. This process is now better understood in connection with the ITP characteristics 505 illustrated in Fig. 17. Specifically, in response to an RFP, the system searches the database to identify the ITP/members which are conveniently located geographically and are capable of performing the tasks consistent with the RFP as ascertained on the basis of the ITP category and ITP size fields. By examining the records 505, the system generates the listing of relevant ITPs as shown at 209 in Fig. 2.

As discussed previously in connection with Fig. 1 , a new applicant can become a member if he/she is already a member of one or more of the approved professional associations. In this regard, the system of the preferred embodiment provides various mechanisms of ascertaining whether an applicant is a member of a specified association. In particular, the system stores an association database symbolically illustrated as 109, see Fig. 6. This database contains membership information of various professional associations. The resident database 601 periodically downloads membership data from a number of professional association databases illustrated as 602-606.

Thus, to verify if an applicant is a member of a given association, first, the local database is searched and if the person is found as a member of a given association, the database provides an appropriate verification. In this case, the applicant is approved and the processing proceeds as illustrated in Fig. 1. If, however, the person is not found in the local database of the service, other inquiries are performed as discussed below.

In particular, under one scenario, if the applicant is not found in the local professional association database 109, a request to update the local database is forwarded to the database resident on a computer of the professional association, collectively illustrated as 610, see Fig. 6-A. The association membership interface 110 manages the interaction between the local associations database and a remote database resident at a professional association computer. The interface 110 provides appropriate data conversions and query generations so as to assure compatibility between the databases and the query languages. The updated locally stored information is searched again to ascertain whether the specified association membership is in fact proper.

Alternatively, as illustrated in Fig. 6-B, certain professional association databases do not permit updating on demand but instead permit searching of their databases. In this case, the specified association database is searched and if the name of the applicant has been found, this information is provided through the interface 110 to the local association database 109 which is then updated with the located name. The subsequent processing then proceeds as illustrated in Fig. 1. A variation of this technique is illustrated in Fig. 6-C, which addresses a case when a particular association database permits only specific queries. In this case, the query is formulated by the system of the preferred embodiment, formatted by the interface 110 and then provided to the appropriate database resident at the association computer as symbolically illustrated by 610. The response to the query is provided through the interface 110. If applicant's membership has been verified, the association database is updated appropriately and the processing proceeds as shown in Fig. 1.

Certain associations may not allow others to search or query their databases. In this case, if the name provided by the applicant is not found in the local associations database and the specified association database does not have an external electronic search or query mechanism, personnel at Intellexchange

107 queries an administrator of the association regarding a particular member via e-mail, or telephone, or fax or mail, etc. (See Fig. 6-D illustrating e-mail inquiry and 6-E illustrating other inquiries by a human.

As illustrated in Fig. 6-F, in the event that the specified association is not found in the list of the approved associations maintained at the local database 109, the system displays additional questions to this applicant regarding this association. The response is then provided to Intellexchange 107 for evaluation as indicated at 650. If, based on the information about the association the Intellexchange determines that this association should be added as one of the approved associations, the local database is updated to list this new professional association as one of the approved associations. The applicant is then processed as a member of an approved association.

Further, as illustrated in Fig. 6-G, if it is determined that an applicant is not a member of any associations, the applicant is permitted to receive a provisional registration as a member of the service, provided that the applicant applies to and joins one of the approved associations. As part of this provisional registration procedure, the applicant is provided with links to the websites of the associations approved by the service as illustrated by 670. After completing the appropriate online application form, the new applicant receives a provisional membership and a member folder as discussed above. In addition, the local association database stores an appropriate time limit to convert the membership from the provisional to the ordinary one. At the end of this period, the appropriate professional association database is queried to verify whether the application of this member has been approved so that the member has joined one of the approved associations. In this case, the membership is converted from the provisional to the ordinary one. Otherwise, the membership privileges of this user are suspended and the user is notified automatically by e-mail.

As illustrated in Fig. 7, if a new member is not interested in joining an association and is not a member of one of the approved associations, the applicant can become a member by paying appropriate qualification fees. The fee can be paid either by providing a credit or debit card information on-line as shown by 702. In this case, after the payment has cleared, an appropriate notification is made to the certificate server that the member has been approved. Thereafter, a membership folder is issued for the new member. Alternatively, as shown by 701 , the payment can be made by non-electronic means. In this case, similarly, after the payment has cleared, the applicant becomes a member and is issued a membership folder and interface. As illustrated in connection with Figs. 2 (block 210) and 2-A, after a member has selected the ITPs that it desires to contact with its RFP, the member is provided with a capability to use a blind RFP mechanism. This mechanism forwards the RFP such that the recipient is unable to determine which entity has provided the RFP. This, among other things, assures privacy, protects from unwanted solicitation and assures fairness in the event that a recipient ITP/member would be inclined to favor more prominent customers.

Figs. 8 and 8-A illustrates the blind RFP mechanism. In this process, the member ID and password record 402 of the member folder 112 is consulted and the member ID is encoded such that the recipient is unable to determine the originator of the RFP. The system, however, stores the relationship between the encoded user ID and the particular user so as to properly forward the responses. Thereafter, the RFP is supplied through the mailbox 401 of the member to the ITP mailboxes 501 of the ITP/members. The transmitted RFP record 801 contains the encoded member ID which does not reveal the identify of the member. It is, however, sufficiently well described and stored in the system in association with the member ID so that the replies from the contacted ITP/members to the RFP can successfully reach the mailbox 401 of the member sending the RFP. As discussed previously, the RFP and the replies to each RFP issued by the member are stored in the RFP history and history of RFP replies records 404.

Fig. 8-A illustrates in further detail the blind RFP mechanism. As illustrated, the member ID, stored at the member ID and password record 402, is encoded using identification filter 801 , which using known techniques encodes the member ID and stores this data in the memory allocated in the certificate server 111. Then, at 802, the encoded user ID is combined with the RFP. This information is provided to the identified ITP/member mailboxes, e.g., 501 , by issuing an appropriate message from the member mailbox.

As illustrated in Fig. 9, the blind RFP is received at the selected ITP/member mailboxes addressed by the user IDs of the selected ITP/members. The ITP/members then reply to the RFP of an unidentified member based on the information about the member provided with the RFP which, as noted, does not reveal the identity of the originating member. The reply and the RFP are also stored in the RFP history and history of RFP replies folder 503. The address of the recipient of the reply is then decoded by the system so as to identify the proper mailbox of the member that originated the RFP. The reply is thereafter forwarded to the proper RFP member mailbox 401.

Fig. 10 illustrates the processing in connection with a request from a potential ITP/member to join the service. The ITP applicant, as illustrated in Fig. 1 , enters pertinent information in an electronic form provided by the system in response to applicant's request to become a member (see 106). This entered data is then provided to Intellexchange 107 for evaluation. The evaluation is performed with an aid of the Intellexchange personnel using varying degree of automation depending on a particular implementation of the system.

To approve an ITP applicant, the Intellexchange 107 initiates three inquiries. It consults accounting so as to obtain financial information about the applicant for the ITP/membership. It also consults sales in order to obtain additional information about the application as discussed below. In addition, it conducts searches in the ITP/member folders in the database stored locally on the certificate server.

The financial approval process is further illustrated in Fig. 10-A. As illustrated, the accounting initiates electronic and non-electronic queries to the sources of the appropriate financial information. The accounting queries a public business database such as Dunn & Bradstreet as illustrated by 1012. The accounting also queries banking and other credit references specified in the application of the potential ITP/member as illustrated by 1010 and 1011 , respectively. After the accounting obtains pertinent information, it evaluates the obtained data either electronically or electronically with human interaction so as to ascertain whether the applicant meets the ITP/member criteria. At the end of this process the accounting responds to Intellexchange with an indication whether the applicant has been cleared.

The non-financial approval procedure is illustrated in Fig. 10-B and 10-C. In Fig. 10-B, the sales contacts business references supplied by the applicant as symbolically illustrated by 1020 so as to receive responses pertinent to the approval process. This process is preferably performed by a human via e-mail or other communication means.

Fig. 10-C illustrates the internal qualification procedure. It comprises contacting ITP/members listed as business references of the ITP/member applicant by e-mail and receiving e-mail responses from these references. The ITP/members identified on the application are located by searching the local database so as to ascertain whether the specified references participate in the service to determine their user ID. The inquiries are then provided to the mailboxes of the identified ITP/members. They respond by contacting the Intellexchange 107 electronically with the reference information requested.

As illustrated in Fig. 10-D, the information received from these three sources of evaluation, i.e., the financial evaluation, the non-financial evaluation and the internal references are supplied to Intellexchange. At Intellexchange 107 this information is evaluated, in some implementations using computer processing, and, if the applicant has not been approved, a message is generated informing the member of the rejection as shown by 1040. Otherwise, if the member has been approved, the relevant information is supplied to the accounting which then instructs the certificate server to create an ITP/member folder and interface for the newly approved ITP/member.

The ITP/member pays for participation in the service via electronic means as known in the art relating to on-line secure payment systems. The service charges ITP/members a scalable flat fee payable periodically. The fee is not based on the size or number of the deals made by an ITP/member. It is also not based on the CPM (cost per million) structure frequently used in advertisements. The fee of the service is constant for a given size of an ITP/member. It is scalable because larger companies (who can perform more extensive work)are charged a higher flat fee.

As discussed previously, when a person becomes a member of the service, he/she is entitled to receive a customized "desktop" interface for his/her personal computer. Essentially, it is the desktop software replacing the environment of the native operating system, e.g., "Windows," and provides a variety of user-specific interactive environments. Such a desktop is illustrated on Fig. 11. It consists of a locally executable component, shown as 1101 , which comprises software that runs on the local computer. This software may include well known tools such as a wordprocessor, a database, a spreadsheet, a personal organizer as well as special applications included for a specific user. It also includes an on-line component directly interfacing with the service. This component is illustrated as 1102 and provides selections for the tasks performed in connection with the service such as complaints and recommendations, monthly surveys, negotiations regarding submitted RFPs, means for submitting RFPs, selected publicly available information which may be of interest to a particular user and other industry specific links and tools. The configuration of the desktop interface may be stored at the member folder and downloaded to the personal computer of the member over a network. This software can also be provided to the member offline on a diskette, CD Rom or another storage medium. Alternatively, as illustrated in Fig. 11-A, the user may not wish to install software that replaces his/her environment provided by the native operating system. Such a user is connected to a customized site resident interface when he/she logs onto the service. As noted, such a homepage provides capabilities needed for interfacing with the service as well as information requested by a specific user. The configuration of such a homepage may also be stored in the member folder.

Similarly, ITP/members may be provided with an environment which replaces the interfaces provided by the native operating system with an environment comprising locally executable tools as well as with on-line links to the functions provided by the service. For an ITP/member in addition to the locally resident tools 1201 , the member is provided with on-line links 1202 connecting his/her to the service capabilities of an ordinary member as well as with ITP/member links 1203. The ITP/member links comprise ITP complaints and recommendations, ITP monthly survey, e-mail replies to RFPs and a capability to "pick-up" (i.e., receive) the RFPs. Other links customized to a particular user may also be included. The customized desktop configuration can be provided to a user by downloading software on-line or it can be supplied on a storage medium, e.g., a diskette or a CD rom. Similarly, as in the case of members, the customized features of the ITP/member desktop may be stored in the ITP/member folder. As shown in Fig. 12-A, if the ITP/member does not desire to customize its desktop so as to replace the links to the native operating system, but simply needs to access the functions available by the service, it is provided with a customized homepage as illustrated in Fig. 12-A. The customized configuration of such a homepage may be stored in the ITP/member folder.

Figs. 13 and 13-A show a procedure for handling member complaints. When a member has a complaint about an ITP/member, it selects the complaints and recommendations icon on the on-line menu provided by the service on the customized interface. The complaint receives a routing number provided by the system and is then recorded in the member's folder and also provided to the folder of the ITP/member. Thus, the ITP/member that has been complained about is informed about the complaint. The complaints and recommendation subrecord of the member folder includes fields: complaint from ITP 1301 , recommended ITP 1302, complaint about ITP 1303, recommended by ITP 1304. In this case the complaint is recorded in complaint about ITP 1303. The complaints and recommendations of the ITP/member folder includes the fields 1310 complaint from member, 1311 recommended member, 1312 complaint about member, 1313 recommended by member. The member complaint is recorded in complaint from member 1310. The ITP/member may be provided an opportunity to electronically respond to the complaint. The information relating to the complaint is provided to Intellexchange which evaluates this information and notifies appropriately the complaining member and the ITP about whom the complaint was filed. In some instances, the Intellexchange may suspend the ITP/member as a result of the complaint. In this case, the ITP/member is notified appropriately. It should also be noted that all the complaints are stored in the ITP/member folder and the service has a threshold determination which suspends the ITP/member that accumulated a significant number of complaints.

Fig. 13-A addresses a recommendation provided by a member. The recommendation receives a routing number and is stored in the member folder. It is also provided for evaluation to Intellexchange which in turn notifies the member regarding the outcome.

Figs. 14 and 14-A illustrate a procedure for complaints and recommendations issued by ITP/members. The ITP/member enters the complaint about a member from his/her homepage. This complaint receives a routing number and is forwarded to the appropriate records of the member and ITP/member folders (i.e., complaint about member 1312, and complaint from ITP 1301 ). The complaint is also provided to Intellexchange for evaluation and at the conclusion of the evaluation, both the member and the complaining ITP/member are notified appropriately. Based on the complaint and the accumulated stored complaints, the member may be suspended from the use of the system. As illustrated in Fig. 14-A, a recommendation issued by an ITP/member is entered through the ITP/member's homepage assigned a routing number and stored in the ITP/members folder. It is also provided to Intellexchange for evaluation. If the recommendation concerns a member, the result is reported to the appropriate member and stored in his/her folder.

Each member and ITP/member is encouraged to respond to monthly surveys which include request for data regarding changes in the membership information, queries about the function of the service and complaints and recommendations. As illustrated in Figs. 15 and 16, such surveys are provided to members monthly in the form of an electronic form requesting data as illustrated by

1501 and 1601. Responses are entered by the users through their respective homepages and are subsequently electronically provided to the Intellexchange for evaluation.

A person skilled in the art will understand that based on this disclosure the sen/ice of the preferred embodiment can be extended to other services. In fact, it can be used to facilitate a comprehensive set of services for an entire businesses. For example, such a service is illustrated in Fig. 19 with respect to the film industry. Block 1900 illustrates the marketplace that combines various services including the service discussed herein. Block 1901 illustrates the IT and telecommunications service as discussed here. Block 1902 illustrates a financial service based on the principles discussed here. It can be used for contracting with financial service providers. Block 1903 illustrates film and entertainment industry service based on principles discussed herein. Within a film company 1910, MIS/administration department 1904 is expected to use the telecommunications service 1901 , accounting 1905 is expected to use the financial service 1902 and the production 1906 is expected to use the film and entertainment service 1903. Thus, the disclosed service is readily extendable to a family of services as illustrated in Fig. 19. For example, a given category may be (1 ) New York Metropolitan Area; (2) computer networking, or network architecture.

Figs. 34A-34W illustrate examples of screens provided to the users that may be employed by the preferred embodiment.

The service may allow only a limited number of providers in each classification. The providers may be classified based on metropolitan or geographical area, size of members served, type of provider's business, and/or other characteristics and combinations thereof. The classifications can be hierarchical and represented as a tree that includes a fixed number of providers at the lowest level. Each such fixed number of providers at the lowest level can be considered a separate classification (also referred to as a category). As noted, the providers presented in response to a project brief are selected by the service based on the content of the project brief. In some embodiments, the project brief may identify the categories of providers, and the system in response would list all the providers in the relevant categories. The order in which the eligible providers appear in the list displayed to a member is preferably random. Such a random selection can be made each time the providers are selected for a given project brief. Alternatively, the order within each category may change periodically, for example, daily.

Preferably, the providers agree to specific rules of conduct with respect to communications with the members when their initial contacts have been initiated through the preferred service. For example, a member may indicate to a provider (in the project brief or otherwise) whether the provider may contact the member by telephone, e-mail, etc. According to the rules of conduct, providers must obey and respect the members' preferences. In the event that a provider does not follow the rules of conduct, for example, it solicits member's business in a way not authorized by the member, such a provider may be warned or suspended by the preferred service.

As noted, the preferred service may allow only a limited number of providers in each classification. The providers are not automatically approved to participate in the service in more classifications than they actually qualify for. In addition to the qualification procedures described above, the system may independently qualify the providers for each classification of service they are applying for using the resources of the preferred service as well as publicly available information. Preferably, to be qualified in a given category, a provider should demonstrate that it has prior experience in performing the projects in this category. .

In addition to the qualification procedure discussed above, the members may also be selected based on an independent qualification check performed by the system. The universe of the members participating in the service may also be limited and restricted to the qualified professionals who source goods/services for themselves and their organizations. Since the number of members may be limited, after the system signs up a given number of members, it would not accept other members. This limitation may be arbitrary, for example, not more than ten thousand members can ever be using the service, or it may be based on other factors, e.g., the number of providers available in the areas of interest of the members. Also, a formula can be provided for determining the number of participants based on order traffic and other considerations of high quality service as understood by a person skilled in the art. For example, if providers indicate that they receive too many project briefs, the number of members may be limited. On the other hand, if providers indicate that they do not receive a sufficient number of project briefs, the number of members may be increased. The limitation on the membership may be different for different categories. For example, the members interested in some technologies or located in some geographical areas may be restricted from joining the service whereas in other geographical areas and/or other areas of technology the membership may be sparse and thus open. A formula controlling the membership can be provided by a person skilled in the art so as to facilitate efficient use of the service. Similarly, the system can limit the number of providers to an arbitrary number or based on a formula as discussed above in connection with the members.

Preferably, a project brief includes information entered by a member using a format provided by the system and also may include additional documents and information attached by the member to the project brief. Preferably, the system allows the member to review the project brief information in a simple form by converting the project brief form into an easy to read document resembling an ordinary letter.

Preferably, business relationships of the entity owning the preferred service are disclosed to the members and the providers. Thus, preferably all users of the service can review such relationships of the entity owning the service using the website of the service or otherwise. The listed business relationships, for example, may be limited to any vendor of the preferred service whose total billings per year exceeds ten thousand dollars. Except for the listed relationships, the entity would not conduct any business that could potentially conflict with its members or providers. Similarly, the owner of the preferred service may restrict business relationships of its shareholders such that, for example, no shareholder would be allowed to own more than a small percentage of any company participating in the service and would not be allowed to be an officer or director of one of the users. Furthermore, preferably the entity that owns the preferred service would not provide any consulting services or be engaged in any other business that would enable it to exploit its relationship with its users and information about them. Thus, the entity of the preferred service acts as a completely unbiased intermediary that has no vested interest in the transactions of or information about its users.

As noted, the providers pay a fixed fee based on the size of the jobs that they perform. They may also be charged a fixed fee based on other characteristics such as the field of technology in which they specialize, geographical area, etc. In other words, the providers may pay a fixed fee depending on the category of service that they have been qualified for. The payment structure may be adjusted to allow certain providers to pay lower fees. For example, a provider may pay a fraction of the appropriated fixed fee and consequently be selected in response to a project brief with a proportionally reduced probability. Thus, for example, if the provider pays one half of the required fee, the probability that it would be selected as one of the providers who may potentially receive a project brief would also be reduced by one half. Similarly, under another alternative payment structure, a provider who pays a fraction of the required fee would be selected to be presented to a member in response to an appropriate project brief proportionally fewer times. For example, if the provider pays one half of the fee, it would only be selected every other time that it qualifies to respond to a project brief.

The preferred system collects valuable data about its members and providers. The system uses this data to facilitate and improve its service to its users. However, the system does not own this data and cannot at will sell it to others as is customarily done by Internet services. First, if a user (member or provider) decides to terminate its participation in the service, the identifying data and stored files relating to this user would be permanently removed from the system so that this user's data becomes unaccessible to the system and anyone else. Second, as noted, the users are true owners of the data that includes histories of their transactions and information about their interests and preferences ("footprint data"). Accordingly, the preferred service does not engage in reselling or otherwise marketing such data without the users' consent. Each user may elect to preclude the business entity of the service from doing anything with its footprint data. Alternatively, a user may authorize the preferred service to resell its footprint data. Even in this case, however, the user remains a beneficiary of any sale of data reflecting the user's transactions and other valuable information. If the preferred service sells or trades such data, financial benefit flows to the user. The service, on the other hand, may collect a fee as an agent to compensate it for the effort of collecting and selling data . Such a compensation may be a percentage of the total sale amount or a fixed fee per participant whose footprint data has been sold. The fee can also be measured by the usage of the system database by a given user or a group of users. The fee may also be calculated based on the time the relevant data has been stored in the database or based on the amount of time the system has been used by the user. A combination of the above or other payment arrangements can also be devised by a person skilled in the art and other factors may be used for computing such a fee. Whether the fee collected by the service is based on the percentage, fixed fee or some measure of the usage of the system, the users' historical and other footprint data remains the property of the users who are the beneficiaries of any resale, whereas the reseller (e.g., the service) receives only a commission for its efforts.

As discussed in detail above, a member of the service submits a project brief which is then routed to the selected providers. In addition, the preferred system forwards to these providers a list of suggested goods and services that the provider may be able to use for the job specified in the project brief. This information is preferably displayed to each provider as a sourcing tool bar which may be attached to the project brief or provided separately thereafter. A provider, who receives the project brief with an associated tool bar, may use the information in the tool bar for responding to the project brief and, subsequently, for the selection of products for the requested tasks. If the project brief is forwarded to several providers, as it is typically the case, each one may receive a different sourcing tool bar because providers' preferences for different products are likely to vary. Tool bars can be organized in various ways, for example, instead of listing specific products, a tool bar may list vendors of products. By selecting the vendor, the family of related products would then be displayed.

In Fig. 21 the project brief is illustrated as 2100. Before supplying it to the provider mailboxes 501 , the project brief is processed by the system so as to generate the sourcing tool bars 2110 identifying several products or services suggested by the system to each selected provider. The sourcing tool bar for a given provider may also be generated or modified after the provider has initially replied to the project brief so as to take advantage of the information provided in the response or any other information that becomes updated after the brief was first sent.

Various sources of information may be employed in identifying the suggested products, services and their vendors. For example, in the preferred embodiment, the products, services, and vendors are identified based on the information contained in the project brief itself and using specific and historical information about members, providers, vendors and products. These items of information, discussed in more detail below, are identified by processing the data stored in the system database. Some of the stored information has been provided by the vendors, providers and members, e.g., in the form of survey answers, membership applications, product descriptions, etc., and other stored information has been collected by the system, e.g., from previous project briefs and responses.

More specifically, preferably the information is stored in a normalized, relational database where the larger tables may include the following: Table(s) of companies, including member companies, provider companies and vendor companies; Table(s) of individuals within companies;

Table(s) of products and services linked to the companies that provide them. Such table can be configured as an index into smaller tables that may be better suited to storing different types of products and systems, for example, a computer table, a printer table, a modem table; Table(s) of characteristics, linked to the products and services. These describe the specifications and prices of the products and services; • Table(s) of relationships, linked to the products and services and companies to which the information applies. For example, for a member disliking a particular product, this table would show a link to both the member and the product and an adverse relationship; one product requiring another product would show a link to both products and a strong, favorable relationship between; and

Table of information, holding all the data classified as B 1 to D₂-2 information (as discussed below) with appropriate links to the relationships and characteristics tables which describe the information.

Information is populated in the database in several ways, all of which may be done periodically throughout operation of the system. The first technique is batch load. This technique involves information that comes from existing databases or lists, which include details about companies, products and specifications. This data is cleaned to remove extraneous information, and the information is processed to create the appropriate table relationships described above, for example showing which companies manufacture which products, which companies perform which services, and which products may interoperate with which others. This characterization may be a semiautomatic process, requiring a combination of computer processing and human intervention.

The second one is referred to as explicit information updates. Information that comes from applications, surveys, questionnaires and information that comes directly from marketplace transactions is considered explicit information and will be directly entered into the system. This information is received in a known format, for example based on the specific questions asked in a survey or from observing actual purchases. Knowing the format allows the data to easily be placed directly into the relevant tables. For example, a survey question asking whether a member's company uses Cisco routers can place the survey answer directly in the relationships table showing the connection if the member does use this product. Likewise, observing a transaction where a member purchases Cisco routers can create the same database records.

The third one is implicit information updates. The general collection of information created from participants' usage of the sourcing bar can be analyzed offline or online. People skilled in the art of data mining techniques can analyze this collection to extract significant trends in purchasing and usage habits of the participants. For example, observations about manufacturing companies expanding their networks beyond four local area networks may be an indicator that these companies may soon have needs for supply chain management software. Information learned through these techniques will be incorporated into the database tables as appropriate and as learned.

Information is retrieved from the database tables using standard relational queries as known in the art. The results of frequently executed queries, for example, queries about the preferences of "all members"; which involves data that does not change frequently, can be cached to minimize database accesses and periodically recalculated. Result tables for queries that involve relatively stable data, such as product specifications that tend not to change once the product is mass-produced, can also be created to minimize the amount of dynamic calculations and database accesses.

It should be noted that, although the sourcing bar concept and generally the process of selecting suggested products, services, and/or vendors for a project brief are discussed in connection with the preferred embodiment, this technology can be used in a variety of applications as understood by a person skilled in the art. Accordingly, this technology can be employed in practically any industry. For example and without limitation, such industries may include: accounting, advertising, aerospace, agriculture, automotive, banking/finance, communications, construction, education, food/beverage, government (fed., state, local), healthcare/medical/dental, human resources, hospitality/recreation, insurance, legal, logistics, manufacturing, marketing, nonprofit, printing/publishing, real estate, retail, computers & technology, telecommunications, transportation travel, utilities/energy, and wholesale/distribution.

A person skilled in the art will know how to extend this description to other industries. In general, the present system and method are applicable to any embodiment where one party requests electronically goods and/or services from another where it is useful to identify such goods and/or services and/or their vendors. As understood by a person skilled in the art, other information and data as discussed herein can be used for identifying potential products, services and vendors for the sourcing bar. It should be noted that the terminology used herein is not limiting and thus the terms such as member, vendor, provider, product, service, project brief, etc. should be construed broadly. The term project brief, for example and without limitation, may include: request for proposal, request for query, request for services, request for rental, request for lease, request for transport, request for bid, request for information, request for data, request for consultancy, request for advice, work order, work letter, project order, project request and project brief.

The sourcing bar technology can also be used with architectural design, CAD (Computer Aided Design), drawings represented as computer files. The elements of these designs can be analyzed as discussed below so as to identify specific components that can be recommended for implementing the design. It should be noted that different components can be selected based on the preferences of the specific designer (or the entities originating and implementing the design). Such architectural or CAD files are processed essentially as a project brief, as understood by a person skilled in the art.

In the preferred embodiment, the sourcing bar products are selected as a result of two types of database processing. (The reference to products also includes vendors and services in some embodiments). The first type is referred to as a pointed search which eliminates from further consideration the products that are irrelevant to the submitted project brief and generates a subset of products that are at least viable candidates for the inclusion to the sourcing bar. In selecting the relevant subset, the system filters the database of products based on the data in the project brief. For example, if the project brief is for a networking project, the pointed search may exclude graphics software products as irrelevant. Also, the products (and categories of products) explicitly excluded by the member in the project brief in some embodiments may be eliminated at the pointed search stage. In addition, this search eliminates the products that may be relevant to the subject matter of the project brief but clearly cannot handle the requirements of the job defined in the project brief or clearly too expensive and/or complex for the specified project. To facilitate database filtering at the pointed searches stage, product descriptions stored in the database specify the types and magnitudes of applicable projects as well as other information that may assist in removing irrelevant products from consideration.

The next procedure includes so called computed searches. These searches identify, in the remaining subset of products, the most relevant ones to the given project brief and the parties. At this stage, the system rates the products based on their relevance and assigns a relevancy score to each product. Using this score, the system identifies the most relevant products to the specific project brief, the member and the provider. Thus, at the completion of the computed searches, the products can be arranged by their relevance as illustrated below.

R > = R₂ > = R₃ > = . . . (R_| is the relevance of item i). For example, if a company has 25,000 people and uses mostly Ethernet networks and a few token-ring LAN's, and is looking to expand its network, the network routers that route traffic amongst Ethernet networks will be very relevant. Because a large company generally needs faster routers the higher speed routers ⁵ would be more relevant than the slower routers. Since this company does not have many token-ring networks, a less relevant, but applicable product would be a bridge from Ethernet to token-ring networks. Another example is a company that uses a Windows platform. For such a company, Macintosh products would have extremely low relevance.

10

The sourcing bar is generated preferably for the first several most relevant products, for instance, first ten most relevant products. There may be other ways of selecting the sourcing bar products. For example, if several types of products have been rated, the most relevant ones from each type may be presented. Fig. ¹⁵ 22 illustrates the tool bar construction process.

The computed searches are described in more detail below in connection with Figs. 23-31. As indicated, the system stores detailed specific and general information regarding the members, providers, vendors, and products. This information is periodically updated based on the activity on the system. The stored information can be logically divided into three categories designating the relevance of a given type of information to the selection of the sourcing bar products.

The first category includes the most relevant information that pertains to the

25 currently submitted project brief. This stored information is illustrated in Figs. 23- 25. Fig. 23 illustrates the member-related first category data. For the member, this information includes the specification in the project brief at issue. (See 2310, also referred to as B 1 ). It also includes data stored in connection with the individual member's application to use the preferred service and, in particular, the data

30 regarding the products and services that the member requires or prefers. See 2320, also referred to as B 2. In addition, stored data identifying the products and services that have been historically preferred and historically excluded by the member belongs to this highly relevant category. See 2330 and 2340 also referred to as D 1 and D 2, respectively. The first category vendor data includes stored product specifications as shown in Fig. 24 as 2410 (also referred to as B₂-1 ). For the providers, the database information at the highest level of relevance is illustrated in Fig. 25. It includes the products and characteristics of products preferred by the provider (see 2510, also referred to as D₂-1 ) and the products (and characteristics of products) excluded by the provider (see 2520, also referred to as D₂-2). These preferred and excluded products have been initially identified in the provider's application and are stored as part of its profile.

The next level of importance (level 1 A) includes historical information about the specific member, provider, and products. This information is generally less relevant than the information in the first category, but it is likely to play a substantial role in selecting the sourcing bar products. The vendor's stored information in the 1A category is illustrated in Fig. 27. This information includes data specifying the history of the vendor's transactions with the specific provider (see 2710, also referred to as C₄-2) and the history of the vendor's transaction with the specific provider when ordering for the specific member issuing the project brief (see 2720, also referred to as C₄-3). It also includes the history of the vendor's transactions with the specific provider when ordering for similar project briefs (see 2730, also referred to as C₄-6), as well as the information regarding the history of the member's preferences for specific vendor's products and the products of the vendors that are in direct competition with the vendor (see 2740, also referred to as C₄-7). In addition, the history of the provider's preferences for the vendor's product(s) and those products in direct competition with the vendor's product(s) are included in this category (see 2750, also referred to as C₄-8). It further includes pertinent sales and demographic information provided by the vendor concerning its transaction outside of the preferred service. See 2760, also referred to as C₄-10.

The level 1A stored information for the member is illustrated in Fig. 26 and includes historical information about this member's preferences derived from the previous project briefs issued by the member as illustrated at 2610, also referred to as C 1. It further includes information provided by the member and stored in the database about its present usage of products and services. See 2620 (C 2).

The 1A stored information for the provider is illustrated in Fig. 28 and ⁵ includes historical information about the previous sourcing bars presented to the provider when presented with similar project briefs (see 2810, C₂-1 ); historical information concerning search patterns of the provider when presented with similar project briefs (see 2820, C₂-2); historical information concerning the provider's purchasing habits when presented with similar project briefs (see 2830, C₂-3); the

¹⁰ history of the effectiveness of various types of presentations (film, stills highly technical) provided to the provider (see 2840, C₂-4); information entered by the specific provider concerning project briefs including its responses to similar project briefs (see 2850, C₂-5); the history of the affinity of buying one product when another relevant or competitive product is presented on the sourcing bar (see

¹⁵ 2860, C₂-6); historical information derived from the specific provider's administrative page concerning its use of the sourcing bar when sourcing products for the customers not affiliated with the preferred service (see 2870, C₂-7).

The last category of stored information processed as part of the computed searches includes general information regarding the relevant technology. This information is less important than the previous two categories in selecting the products, but it should be considered because it may identify important industry trends and may refine the selection of products. This category is referred to as category (or level) 2.

25

Fig. 29 illustrates the category 2 stored information relating to the member. It includes information from all members' membership applications concerning products and services required or desired (see 2910, B_r3); historical information about all the member preferences in connection with previous similar project briefs

30

(see 2920, C 3); historical information about all the member preferences derived from the previous project briefs (see 2930, C 4); and information entered by all members in surveys about present usage of relevant goods and/or services (see 2940, C 5).

The level 2 vendor information is illustrated in Fig. 30. It includes the history of the vendor's transactions with all providers in the marketplace of the preferred service (see 3000, C₄-1 ); history of the vendor's transactions with all providers when ordering for this specific member (see 3010, C₄-4); history of the vendor's transactions with all the providers when ordering for similar project briefs (see 3020, C₄-5); and history of the vendor's transactions performed outside of the preferred service (see 3030, C₄-9).

The level 2 information included for the providers is illustrated in Fig. 31. It includes historical information about previous sourcing bars presented to all the providers when presented with similar project briefs (see 3100, C₃-1 ); historical information concerning search patterns of all the providers when presented with similar project briefs (see 3110, C₃-2); historical information concerning purchasing habits of all the providers when presented with similar project briefs (see 3120, C₃- 3); history of the effectiveness of various types of presentations (film, still, highly technical, etc.) to all the providers (see 3130, C₃-4); information inputted by all the providers relating to similar project briefs, e.g., their answers to similar project briefs (see 3140, C₃-5); history of the affinity of buying a given product when the product at issue is presented on the sourcing bar for all the providers (see 3150, C₃-6); and history derived from the providers' administrative page concerning the use of the sourcing bar when sourcing products outside of the environment of the preferred service (see 3160, C₃-7).

The information shown in Figs. 23-31 is stored in the database of the system as known in the art. To identify relevant information for the particular project brief and the parties, the system performs appropriate database searches as known in the art of database technology. As noted, the stored information has been partitioned into three levels of importance. Within each level, it relates to three entities (vendors, members, and providers). For each of these entities, the corresponding information is referred to as a "stream" so that for each level of importance there are three information streams (vendor's, member's and providers's). Thus, in the preferred embodiment there are nine information streams: three streams (a member stream, a vendor stream and a provider stream) within each of three levels (1 , 1A, and 2).

The relative relevance of information in each stream is stored in the system and is illustrated in Table 1 , Fig. 32. These relevance values are stored in the system. These values define how various items of information in the database can affect the selection of a given product for the sourcing bar. The stored values corresponding to Table 1 may be adjusted as new information and statistics being collected by the system so as to improve the quality of the sourcing bar offerings. It should be noted that in Table (Fig. 32) 1 the member-related data is considered more important than the provider's or vendor's data. Alternatively, the relevance values may be adjusted so as to favor the provider-related data.

Figs. 23-31 illustrate the types of information that can be derived from the database as individual blocks. Each of these types in the illustrated blocks are referred to as "sources" of information supplied to every stream. That is, each block in Figs. 23-31 is considered a separate source providing information to its stream. Each source may have a constructive, destructive or neutral contribution to the probability of whether a given products would be included in the sourcing bar. The constructive contribution indicates that the product is relevant to the purpose of a given sourcing bar; the destructive contribution indicates that the product is not relevant; and the neutral contribution means that the source has inadequate information about the product at issue. In the preferred embodiment, a source providing constructive contribution is assigned weight 1 , a source providing destructive contribution is assigned weight 0 and a source providing neutral contribution is ignored. Table 2 illustrates potential contribution of the sources illustrated in Figs. 23-31. As evident from Table 2, Fig. 33, each source may have constructive or neutral contribution, but only several sources may also have destructive contribution.

Each stream of information contributes to determining the product's overall relevance. Thus, for each product, the relevance is determined by first identifying the relevance contributed by each of nine streams comprised of individual sources. To compute the relevance of a stream, first, its fractional strength is ascertained by adding constructive and destructive contributions of the individual sources and dividing the result by the number of contributing sources. The fractional strength is then multiplied by the stream's relevance from Table 1 to determine the relevance contributed by a given stream.

An example of this computation is illustrated in connection with level 1 member stream. The four information sources that can contribute to this stream are B 1 , B_r2, D 1 and D_r2, as illustrated in Fig. 23. In this example, assume that these sources of information provide the following contribution to the relevance of the product at issue:

B 1 is constructive (contribution potential: add 1 )

B 2 is neutral (contribution potential: ignore)

D 1 is constructive (contribution potential: add 1 )

D 2 is destructive (contribution potential: add 0)

This means that sources B_r1 and D.,-1 indicate that the product is relevant to the current sourcing situation, D 2 indicates the product is irrelevant, and B 2 provides no information. As noted, the fractional strength of a stream is calculated by adding the contribution potentials and dividing this value by the.total number of contributing information sources. Thus, the fractional strength of this level 1 user information is computed as follows:

Sub-score = 1 + 1 + 0 = 2.

The number of contributing sources = 3. Fractional strength = 2/3

The fractional strength of this stream times the individual stream's relevance from Table 1 is defined as the relevance of a product provided by a given stream. Thus, for the level 1 member stream of this example, the relevance is computed as follows:

Product relevance = fractional strength of stream^*stream relevance =

2/3*0.6=0.4

The relevance of a product is computed in the same manner for all 9 streams. Then, all the scores for all the streams are added together and the sum provides the relevance of the product. In other words, each product's relevance is calculated as follow:

Equation 1. ∑ (fractional strength of strearri_j x stream relevance) = product relevance

The products with the highest scores are deemed to be more relevant to the current sourcing situation. It should be noted that if a given stream has no contributing sources, the stream is removed from the equation and does not contribute to the product relevance.

Other mathematical formulations can be adapted for the process of combining contribution potentials and expressing a constructive/ destructive relationship, e.g., multiplication/division or exponents/logarithms may be used in other embodiments.

The sourcing bar preferably displays a number of products in a certain category of products. For example, it may show 10 desktop computers when the job pertains to desktop computers. The sourcing bar shows the 10 most relevant desktop computers based on the 10 highest scores determined in accordance with the above computation and after the flagged searches as described above. If there are too many products with equivalent scores or too few relevant products, information streams are gradually removed from Equation 1 until there is a clear delineation of products to construct a meaningful sourcing bar display. In this case, the streams are removed in the order they appear in Table 2, beginning at the bottom of the table and moving up.

If no products are deemed relevant or all the products have low relevance, which may happen due to a participant's negative opinion of some products or vendors, a few products will still be shown in the sourcing bar if the technical demands of the project require such a component. This will happen regardless of the outcome of the relevancy calculation so that the bar may include the products that have low relevance.

Preferably, the vendors who or whose products have been identified on the sourcing bar pay a fee to the preferred service. The amount of the fee may vary depending on the magnitude of the job specified in the associated project brief. For jobs requiring a higher number of units, a product or higher priced products, the fee can be greater than for smaller jobs. For example, a computer company identified on the sourcing bar (or whose products have been identified on the sourcing bar) may pay a lower fee in connection with a job that requires one computer then in connection with a job that requires one hundred computers. Similarly, the fee is lower for a cheaper device identified on the sourcing bar than for an expensive one. Thus, the preferred system provides a technique for pricing an online advertisement based on the requirement of the target potential customer. The system ascertains the need of the particular customer and prices the advertisement accordingly.

The present invention is not to be limited in scope by the specific embodiments described herein. Indeed, modifications of the invention in addition to those described herein will become apparent to those skilled in the art from the foregoing description and accompanying figures. Doubtless, numerous other embodiments can be conceived that would not depart from the teaching of the present invention, whose scope is defined by the following claims.

Claims

Claims:

1. A computer internet-based system for enabling users to select appropriate suppliers of services and goods comprising: (a) electronic means for storing information about suppliers in a database,

(b) electronic means for receiving a request, identifying a desired good or service, from a user,

(c) electronic means for searching the database to identify suppliers with qualifications corresponding to the user's request,

(d) electronic means for enabling the user to select the desired suppliers from the identified suppliers, and

(e) electronic means for providing the request to the desired suppliers.

2. The system of claim 1 further comprising means for enabling a supplier to reply to the request.

3. The system of claim 1 further comprising means for quality control of the services provided by the suppliers.

4. The system of claim 1 further comprising means for providing a request to the desired suppliers without identifying the user issuing the request.

5. The system of claim 1 wherein the suppliers are charged a flat rate.

6. The system of claim 1 comprising electronic means for searching a professional association listing to determine whether a user should be permitted to use the system.

7. A method of providing a computer-implemented service for matching customers and suppliers of goods and services comprising: (a) storing a request, identifying a desired good or service, issued by a customer,

(b) electronically searching at least one database to identify suppliers capable of providing the services based on the request, (c) displaying to the customer a list of suppliers capable to provide the service requested in the request,

(d) selecting desired suppliers from the list of suppliers, and

(e) forwarding the request to the desired suppliers.

8. The method of claim 7 further comprising electronically searching professional association databases to determine if a customer can be permitted to use the service.

9. The method of claim 7 further comprising encoding the identity of a customer in the request provided to the suppliers so that the suppliers are unable to identify the customer.

10. The method of claim 7 further comprising storing an interface at a customer's computer which replaces interfaces of a native operating system and provides interfaces to locally stored tools and remotely accessible functions of the service.

11. The method of claim 7 further comprises receiving the request over the Internet.

12. A method of administering a computer-implemented service for matching customers to suppliers of goods and services, wherein the customers and the suppliers are approved (not merely registered) members of the service, comprising: electronically receiving a first application from a potential customer to become a member of the service; electronically determining whether the potential customer is a member of an approved professional association, and if so, transmitting an electronic message to the potential customer indicating that the potential customer has been approved to become a member of the service; electronically receiving a second application from a potential supplier of goods and services to become a member of the service; and electronically soliciting recommendations from other members participating in the service as to whether to approve the potential supplier to become a member of the service.

13. The method of claim 12 further comprising providing an option to a potential customer who is not a member of a professional association to pay a qualification fee in order to enable the service to approve the potential customer as a member.

14. The method of claim 12 further comprising electronically transmitting to a supplier a requirement to pay a flat periodic fee for participation in the service, wherein the amount of the fee relates to the supplier's business capacity.

15. The method of claim 12 wherein the step of determining professional association membership comprises searching a professional association database stored in connection with a computer operated by the service.

16. The method of claim 12 wherein the step of determining professional association membership comprises remotely accessing an association member database stored at a computer operated by a professional association.

17. The method of claim 12 wherein the steps of electronically receiving further comprises receiving the first and the second applications over the Internet.

18. A computer-implemented method implementing a service of assisting customers in selecting suppliers of goods or services, comprising: electronically enabling a customer to issue a request identifying a desired good or service; electronically selecting a list of suppliers of goods or services based on a task or product electronically specified in the request and based on electronic profiles of suppliers stored in a computer database; and transmitting the request to at least some of the suppliers identified in the list of suppliers without revealing identity of the customer issuing the request.

19. The method of claim 18 further comprising enabling the customer to select a subset of suppliers from the list of suppliers and electronically transmitting the request to the subset of suppliers.

20. The method of claim 18 wherein the step of selecting further comprises matching a magnitude of the task specified in the request to capacities of suppliers' businesses stored in a computer database.

21. The method of claim 18 wherein the step of transmitting the request further comprises processing a user ID of the customer using an identification filter so that only a partial ID information is transmitted with the request thereby not revealing customer's identity.

22. The method of claim 18 further comprising enabling a supplier who received the request to reply to the customer who issued the request.

23. The method of claim 18 further comprises receiving the request over the Internet.

24. A computer-implemented method of providing a service to users

(including customers and suppliers of goods and services), comprising: loading over a network to a computer of a user a new interface replacing an interface of a local Operating System, the new interface includes Internet access means to a computer of the service and locally stored programs selected based on user's preferences; electronically enabling a customer to submit a request; and electronically enabling a supplier to respond to the request.

25. The method of claim 24 further comprising the step of storing a history of transactions between customers and suppliers in a database.

26. The method of claim 24 further comprising the step of storing complaints about a supplier in a database.

27. The method of claim 24 further comprising the step of storing complaints about a customer in a database.

28. The method of claim 24 further comprising the step of forwarding monthly surveys to customers.

29. The method of claim 24 further comprising the step of electronically forwarding monthly surveys to suppliers.

30. A computer-implemented system for matching customers to suppliers of goods and services, wherein the customers and the suppliers are approved members of the service, comprising: means for electronically receiving a first application from a customer to become a member of the service; means for electronically determining whether the customer is a member of an approved professional association; means for electronically receiving a second application from a supplier of goods and services to become a member of the service; and means for electronically soliciting recommendations from other members participating in the service as to whether to approve the supplier to become a member of the service.

31. The system of claim 30 further comprising means for providing an option to a customer who is not a member of a professional association to pay a qualification fee in order to become a member of the service.

32. The system of claim 30 further comprising means for electronically transmitting to a supplier a requirement to pay a flat periodic fee for participation in the service, wherein the amount of the fee relates to the characteristics of supplier's business.

33. The system of claim 30 wherein the means for determining professional association membership comprises means for searching a professional association database stored in connection with a computer operated by the service.

34. The system of claim 30 wherein the mean for determining professional association membership comprises means for remotely accessing a member database stored at a computer operated by a professional association.

35. The system of claim 30 wherein the means for electronically receiving further comprises electronically receiving the first an the second applications over the Internet.

36. A computer system implementing a service assisting customers in selecting suppliers of goods or services, comprising: means for electronically enabling a customer to issue a request identifying a desired good or service; means for electronically selecting a list of potential suppliers of goods or services based on a task or product electronically specified in the request and based on electronic profiles of suppliers stored in a computer database; and means for transmitting the request to at least some of the suppliers identified in the list of potential suppliers without revealing identity of the customer issuing the request.

37. The system of claim 36 further comprising means for enabling the customer to select a subset of suppliers from the list of suppliers and electronically transmitting the request to the subset of suppliers.

38. The system of claim 36 wherein the means for selecting further comprises matching a magnitude of the task specified in the request to sizes of suppliers' businesses stored in a profile database.

39. The system of claim 36 wherein the means for transmitting the request further comprises processing a user ID of the customer using an identification filter so that only a partial ID information is transmitted with the request thereby not revealing customer's identity.

40. The system of claim 36 further comprising means for enabling a supplier who received the request to reply to the customer who issued the request.

41. The system of claim 36 further comprising receiving the request over the Internet.

42. A computer-implemented system for providing a service to users, including customers and suppliers of goods and services comprising: means for loading over a network to a computer of a user a new interface replacing an interface of a local Operating System, the new interfaces includes Internet access means to a computer of the service and locally stored programs selected based on user's preferences; electronic means for enabling a customer to submit a request; and electronic means for enabling a supplier to respond to the request.

43. The system of claim 42 further comprising means for storing a history of suppliers' transactions in a database.

44. The system of claim 42 further comprising means for storing complaints about a supplier in a database.

45. The system of claim 42 further comprising means for storing complaints about a customer in a database.

46. The system of claim 42 further comprising means for forwarding monthly surveys to customers.

47. The system of claim 42 further comprising means for electronically forwarding monthly surveys to suppliers.

48. A method for providing a service of matching providers of goods or services with members desiring to obtain goods or services offered by at least some of the providers and wherein the number of the providers participating in the service is limited to a predetermined number unrelated to the capacity of the system comprising: receiving a request identifying a desired good or service; determining a set of providers capable of providing the desired good or service; and displaying a list of the selected providers identified in the step of determining in a substantial random fashion.

49. The method of claim 48 wherein each of the providers is qualified by an independent qualification process so as to assure that it is capable of providing offered goods or services.

50. The method of claim 48 wherein each of the members that request goods or services are qualified by an independent qualification process before requesting such goods or services.

51. The method of claim 48 wherein the number of the providers participating in the sen/ice is determined in accordance with a formula.

52. The method of claim 48 wherein the number of the members participating in the service is determined in accordance with a formula.

53. The method of claim 48 wherein the number of the members participating in the service does not exceed a predetermined number.

54. The method of claim 48 wherein a document in electronic form is attached to the request.

55. The method of claim 48 wherein the entity providing the service to the members and providers disclose substantially all of its commercial relationships with the members and providers of the service.

56. The method of claim 55 wherein the entity providing the service does not allow the members and providers participating in the service to be shareholders of the entity.

57. The method of claim 48 wherein each provider pays a fixed fee for participation in the service.

58. The method of claim 48 wherein the step of receiving further comprises receiving the request over the Internet.

59. An electronic transaction method comprising: enabling customers to execute electronic transactions; collecting information representing customer's pattern of behavior in executing electronic transactions, wherein said information is the property of the customer; selling the information representing customer's pattern of behavior; and paying to the customer at least a portion of the proceeds received as a result of selling the information.

60. The method of claim 59 further comprising paying a fee for selling the information to an entity administering electronic transactions.

61. The method of claim 59 wherein the customers execute electronic transactions over the Internet.

62. An electronic transaction method comprising: enabling a customer to execute electronic transactions over a computer network; storing customer information characterizing the customer in a computer system ; receiving an electronic instruction from the customer to remove the customer information; and removing the customer information from the system.

63. The method of claim 62 wherein the customer information is the property of the customer.

64. The method of claim 62 wherein the customer information comprises information representing customer's pattern of behavior in executing electronic transactions.

65. The method of claim 62 wherein the network is the Internet

66. A computer-implemented method of identifying goods that can be useful to a service provider, comprising: receiving a request for a service forwarded to the provider of the service by a user; analyzing the request so as to determine one or more goods that the provider can use in performing the service; and supplying an identification of the determined goods to the provider of the service.

67. The method of claim 66 wherein the step of analyzing comprises searching at least one database so as to identify provider's preferences.

68. The method of claim 66 wherein the step of analyzing comprises analyzing historical information relating to preferences of a plurality of service providers.

69. The method of claim 66 wherein the step of analyzing comprises analyzing historical information of user's transactions with the provider.

70. The method of claim 66 wherein the step of supplying comprises displaying the identification of the determined goods as a display associated with the request.

71. The method of claim 70 wherein the display comprises a set of icons identifying the determined goods.

72. The method of claim 66 wherein the step of analyzing includes rating the relevance of the determined goods.

73. The method of claim 66 wherein the step of analyzing includes eliminating from consideration any goods identified as unacceptable in the request.

74. The method of claim 66 comprising the step of analyzing provider's response to the request.

75. The method of claim 66 wherein the step of analyzing further comprising analyzing vendor information.

76. The method of claim 66 wherein the step of receiving comprises receiving the request over the Internet

77. The method of claim 66 wherein the step of analyzing further comprises analyzing historical information of transactions of a plurality of users with the provider.

78. The method of claim 66 wherein the step of analyzing further comprises analyzing historical information transactions of a plurality of users with a plurality of providers.

79. The method of claim 66 wherein the step of analyzing further comprises analyzing historical information of transactions of the user with a plurality of vendors.

80. The method of claim 66 wherein the step of analyzing further compr iisseess aannaallyyzziinngg historical information of transactions of the provider with a plurality of vendors.

81. A computer system for identifying goods that can be useful to a service provider, comprising: software for receiving a request for a service forwarded to the provider of the service by a user; software for analyzing the request so as to determine one or more goods that the provider can use in performing the service; and software for supplying an identification of the determined goods to the provider of the service.

82. The system of claim 81 wherein the software for analyzing comprises software for searching at least one database so as to identify provider's preferences.

83. The system of claim 81 wherein the software for analyzing further comprises software for analyzing historical information relating to preferences of a plurality of service providers.

84. The system of claim 81 wherein the software for analyzing comprises software for analyzing historical information of transactions of the user with the provider.

85. The system of claim 81 wherein the software for supplying comprises means for displaying the identification of the determined goods as a display associated with the request.

86. The system of claim 85 wherein the display comprises a set of icons identifying the determined goods.

87. The system of claim 81 wherein the software for analyzing includes rating the relevance of the determined goods.

88. The system of claim 81 wherein the software for analyzing includes means for eliminating from consideration any goods identified as unacceptable in the request.

89. The system of claim 81 wherein the software for analyzing comprises software for analyzing provider's response to the request.

90. The system of claim 81 wherein the software for analyzing comprises software for analyzing vendor information.

91. The method of claim 81 wherein the software for receiving comprises software for receiving the request over the Internet.

92. The system of claim 81 wherein the software for analyzing further comprises software for analyzing historical information relating to transactions of a plurality of users with a plurality of providers.

93. The system of claim 81 wherein the software for analyzing further comprises software for analyzing historical information relating to transactions of a plurality of users with the provider.

94. The system of claim 81 wherein the software for analyzing further comprises software for analyzing historical information relating to transactions of the user with a plurality of vendors.

95. The system of claim 81 wherein the software for analyzing further comprises software for analyzing historical information relating to transaction of the provider with a plurality of the vendors.

96. The system of claim 81 wherein the software for analyzing further comprises software for eliminating from consideration any goods identified as unacceptable by the provider.

97. A computer method for online advertising to a customer comprising: identifying customer's need for one or more units of a product; determining a suggested product that is likely to meet the customer's need; providing to the customer an advertisement identifying the suggested product; and charging a vendor of the suggest product for the advertisement provided to the customer based on a magnitude of the customer's need for one or more units of the product.

98. The method of claim 97 wherein the magnitude of the need is determined by the number of units of the product required by the customer and the charge for the advertisement is higher for a larger number of required products.

99. The method of claim 97 wherein the magnitude of the need is determined based on a value of the desired product and the charge for the advertisement is higher for a more valuable product.

100. The method of claim 97 wherein the customer's need is identified by analyzing an electronic request provided by the customer to a supplier.

101. The method of claim 97 wherein the suggested product is determined by searching at least one database and analyzing one or more of the following factors: the customer's preferences for products, history of the customer's transactions and history of transactions of similar customers.

102. The method of claim 97 wherein the step of providing includes providing the advertisement over the Internet.

103. A computer system for online advertising to a customer comprising: means for identifying customer's need for one or more units of a product; means for determining a suggested product that is likely to meet the customer's need; means for providing to the customer an advertisement identifying the suggested product; and means for charging a vendor of the suggest product for the advertisement provided to the customer based on a magnitude of the customer's need for one or more units of the product.

104. The system of claim 103 wherein the magnitude of the need is determined by the number of units of the product required by the customer and the charge for the advertisement is higher for a larger number of required products.

105. The system of claim 103 wherein the magnitude of the need is determined based on value of the desired product and the charge for advertisement is higher for a more valuable product.

106. The system of claim 103 wherein the customer's need is identified by analyzing an electronic request provided by the customer to a supplier.

107. The system of claim 103 wherein the suggested product is determined by searching at least one database and analyzing one or more of the following factors: the customer's preferences for products, history of the customer's transactions and history of transactions of similar customers.

108. The system of claim 103 wherein the means for providing includes means for providing the advertisement over the Internet.