WO2000041087A1 - Mise en correspondance de fournisseurs de services avec des clients et production de donnees de recherche produit/service - Google Patents

Mise en correspondance de fournisseurs de services avec des clients et production de donnees de recherche produit/service Download PDF

Info

Publication number
WO2000041087A1
WO2000041087A1 PCT/US1999/030854 US9930854W WO0041087A1 WO 2000041087 A1 WO2000041087 A1 WO 2000041087A1 US 9930854 W US9930854 W US 9930854W WO 0041087 A1 WO0041087 A1 WO 0041087A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
customer
request
suppliers
analyzing
Prior art date
Application number
PCT/US1999/030854
Other languages
English (en)
Inventor
Robert L. Cadoux
Terence P. O'connor
Joseph Andreshak
Original Assignee
Cadoux Robert L
Connor Terence P O
Joseph Andreshak
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cadoux Robert L, Connor Terence P O, Joseph Andreshak filed Critical Cadoux Robert L
Priority to AU23861/00A priority Critical patent/AU2386100A/en
Publication of WO2000041087A1 publication Critical patent/WO2000041087A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising

Definitions

  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • IT Information Technology
  • the service can be employed for any providers of goods or services to interact with customers.
  • 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.
  • RFP Request for Proposal
  • 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.
  • 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.
  • a project brief e.g., request for proposal
  • the project brief 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.
  • 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.
  • the network is the internet and the communication is as known in the art for internet-based services.
  • 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.
  • 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.
  • 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.
  • 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.
  • Intellexchange 107 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.
  • 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.
  • the membership request and related information is entered into an electronic form at 108.
  • the data is entered into the system in a conventional fashion as customarily done in on-line (e.g., Internet) services.
  • 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.
  • 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.
  • 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.
  • association membership 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.
  • 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.
  • 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.
  • Fig. 2 illustrates software steps supporting members' interaction with the service.
  • the user member or ITP/member
  • the user has already been approved to use the service and has been issued a folder and an interface.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • the ITP/member folder holds ITP characteristics 505 which includes data describing this ITP.
  • the ITP characteristics are further detailed in Fig. 17.
  • the ITP/member folder can hold other information such as a configuration of the ITP/member's homepage.
  • 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.
  • the ITP size determines the flat fee that an ITP pays for using the service.
  • 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.
  • 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.
  • the system of the preferred embodiment provides various mechanisms of ascertaining whether an applicant is a member of a specified association.
  • 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.
  • 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.
  • 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.
  • Fig. 6-B certain professional association databases do not permit updating on demand but instead permit searching of their databases.
  • 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.
  • Fig. 6-C A variation of this technique is illustrated in Fig. 6-C, which addresses a case when a particular association database permits only specific queries.
  • 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.
  • 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.
  • 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.
  • 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.
  • the applicant is provided with links to the websites of the associations approved by the service as illustrated by 670.
  • the new applicant receives a provisional membership and a member folder as discussed above.
  • the local association database stores an appropriate time limit to convert the membership from the provisional to the ordinary one.
  • 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.
  • 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.
  • an appropriate notification is made to the certificate server that the member has been approved.
  • a membership folder is issued for the new member.
  • the payment can be made by non-electronic means.
  • the applicant becomes a member and is issued a membership folder and interface. As illustrated in connection with Figs.
  • a member 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.
  • 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 stores the relationship between the encoded user ID and the particular user so as to properly forward the responses.
  • 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.
  • Fig. 8-A illustrates in further detail the blind RFP mechanism.
  • 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.
  • 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.
  • 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.
  • the Intellexchange 107 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.
  • 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.
  • the accounting evaluates the obtained data either electronically or electronically with human interaction so as to ascertain whether the applicant meets the ITP/member criteria.
  • the accounting responds to Intellexchange with an indication whether the applicant has been cleared.
  • Fig. 10-B The non-financial approval procedure is illustrated in Fig. 10-B and 10-C.
  • 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.
  • 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.
  • 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.
  • a person becomes a member of the service, he/she is entitled to receive a customized "desktop" interface for his/her personal computer.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the customized features of the ITP/member desktop may be stored in the ITP/member folder.
  • 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.
  • a member 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.
  • 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.
  • 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.
  • 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
  • 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.
  • MIS/administration department 1904 is expected to use the telecommunications service 1901
  • accounting 1905 is expected to use the financial service 1902
  • production 1906 is expected to use the film and entertainment service 1903.
  • 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).
  • the providers presented in response to a project brief are selected by the service based on the content of the project brief.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a provider should demonstrate that it has prior experience in performing the projects in this category. .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • business relationships of the entity owning the preferred service are disclosed to the members and the providers.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the system does not own this data and cannot at will sell it to others as is customarily done by Internet services.
  • 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.
  • 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 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.
  • 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.
  • a member of the service submits a project brief which is then routed to the selected providers.
  • 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.
  • Fig. 21 the project brief is illustrated as 2100.
  • 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.
  • 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.
  • 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 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
  • 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.
  • 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.
  • 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.
  • project brief 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.
  • CAD Computer Aided Design
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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. 15 22 illustrates the tool bar construction process.
  • 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
  • Figs. 23- 25 currently submitted project brief. This stored information is illustrated in Figs. 23- 25.
  • Fig. 23 illustrates the member-related first category data.
  • 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
  • the first category vendor data includes stored product specifications as shown in Fig. 24 as 2410 (also referred to as B 2 -1 ).
  • 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 2 -1 ) and the products (and characteristics of products) excluded by the provider (see 2520, also referred to as D 2 -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 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 4 -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 4 -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 4 -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 4 -7).
  • 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 4 -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 4 -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 5 includes historical information about the previous sourcing bars presented to the provider when presented with similar project briefs (see 2810, C 2 -1 ); historical information concerning search patterns of the provider when presented with similar project briefs (see 2820, C 2 -2); historical information concerning the provider's purchasing habits when presented with similar project briefs (see 2830, C 2 -3); the
  • 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.
  • 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 r 3); historical information about all the member preferences in connection with previous similar project briefs
  • 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 4 -1 ); history of the vendor's transactions with all providers when ordering for this specific member (see 3010, C 4 -4); history of the vendor's transactions with all the providers when ordering for similar project briefs (see 3020, C 4 -5); and history of the vendor's transactions performed outside of the preferred service (see 3030, C 4 -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 3 -1 ); historical information concerning search patterns of all the providers when presented with similar project briefs (see 3110, C 3 -2); historical information concerning purchasing habits of all the providers when presented with similar project briefs (see 3120, C 3 - 3); history of the effectiveness of various types of presentations (film, still, highly technical, etc.) to all the providers (see 3130, C 3 -4); information inputted by all the providers relating to similar project briefs, e.g., their answers to similar project briefs (see 3140, C 3 -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 3 -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 3 -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.
  • 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.
  • B 1 is constructive (contribution potential: add 1 )
  • D 1 is constructive (contribution potential: add 1 )
  • sources B r 1 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.
  • 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.
  • the fractional strength of this level 1 user information is computed as follows:
  • 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.
  • the relevance is computed as follows:
  • each product's relevance is calculated as follow:
  • 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.
  • 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.
  • 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.
  • the fee is lower for a cheaper device identified on the sourcing bar than for an expensive one.
  • 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.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Game Theory and Decision Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention concerne des systèmes et des techniques d'ordinateur permettant d'offrir un service (101) à des membres agréés (112) de commande de marchandises/services auprès de fournisseurs agréés (120) pour ces marchandises/services. Le service conserve une demande provenant d'un membre, cherche électroniquement dans au moins une base de données (109) afin d'identifier les fournisseurs capables de répondre à la demande, affiche chez le membre une liste de ces fournisseurs, et envoie la demande aux fournisseurs désirés. Le service limite (111) le nombre de fournisseurs (120) du service aussi bien que le nombre de membres (112) qui peuvent utiliser le service. Les fournisseurs du service et les membres sont de préférence soumis à l'approbation (114) du service avant qu'ils soient admis à l'utiliser. L'identification de produit/service suggérés est basée, de préférence, sur l'analyse de la demande, de l'information conservée relative aux habitudes d'achats des fournisseurs du service et du membre formulant la requête, ainsi que sur les spécifications de produit du vendeur.
PCT/US1999/030854 1998-12-31 1999-12-28 Mise en correspondance de fournisseurs de services avec des clients et production de donnees de recherche produit/service WO2000041087A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU23861/00A AU2386100A (en) 1998-12-31 1999-12-28 Matching service providers with customers and generating product/service sourcing data

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US11458998P 1998-12-31 1998-12-31
US60/114,589 1998-12-31
US15029699P 1999-08-23 1999-08-23
US60/150,296 1999-08-23
US46922499A 1999-12-22 1999-12-22
US09/469,224 1999-12-22

Publications (1)

Publication Number Publication Date
WO2000041087A1 true WO2000041087A1 (fr) 2000-07-13

Family

ID=27381529

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/030854 WO2000041087A1 (fr) 1998-12-31 1999-12-28 Mise en correspondance de fournisseurs de services avec des clients et production de donnees de recherche produit/service

Country Status (2)

Country Link
AU (1) AU2386100A (fr)
WO (1) WO2000041087A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1220124A3 (fr) * 2000-12-28 2003-03-05 Hitachi, Ltd. Méthode pour soutenir l' introduction d'un participant et méthode et système pour l' introduction d'un participant
EP1647902A1 (fr) * 2000-10-10 2006-04-19 Ricoh Company, Ltd. Système, produit de programme informatique et procédé de choix et déduction des applications service provider de documents éléctroniques
AU785195B2 (en) * 2000-10-18 2006-11-02 Mark Richard Cooper Service management system
US20100017337A1 (en) * 2008-07-17 2010-01-21 Butler Rhett A Establishing a buyer/service provider relationship electronically
RU2777274C1 (ru) * 2021-04-20 2022-08-01 Общество с ограниченной ответственностью «Обоз» Способ организации компьютерной логистической сети с использованием доменной древовидной иерархической структуры и система для её осуществления

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5742931A (en) * 1993-01-15 1998-04-21 Ss&D Corporation System and method for allocating resources of a retailer among multiple wholesalers
US5842178A (en) * 1996-02-22 1998-11-24 Giovannoli; Joseph Computerized quotation system and method
US5924080A (en) * 1996-05-28 1999-07-13 Incredicard Llc Computerized discount redemption system
US5974395A (en) * 1996-08-21 1999-10-26 I2 Technologies, Inc. System and method for extended enterprise planning across a supply chain
US6023683A (en) * 1994-08-10 2000-02-08 Fisher Scientific Company Electronic sourcing system and method
US6038668A (en) * 1997-09-08 2000-03-14 Science Applications International Corporation System, method, and medium for retrieving, organizing, and utilizing networked data

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5742931A (en) * 1993-01-15 1998-04-21 Ss&D Corporation System and method for allocating resources of a retailer among multiple wholesalers
US6023683A (en) * 1994-08-10 2000-02-08 Fisher Scientific Company Electronic sourcing system and method
US5842178A (en) * 1996-02-22 1998-11-24 Giovannoli; Joseph Computerized quotation system and method
US5924080A (en) * 1996-05-28 1999-07-13 Incredicard Llc Computerized discount redemption system
US5974395A (en) * 1996-08-21 1999-10-26 I2 Technologies, Inc. System and method for extended enterprise planning across a supply chain
US6038668A (en) * 1997-09-08 2000-03-14 Science Applications International Corporation System, method, and medium for retrieving, organizing, and utilizing networked data

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1647902A1 (fr) * 2000-10-10 2006-04-19 Ricoh Company, Ltd. Système, produit de programme informatique et procédé de choix et déduction des applications service provider de documents éléctroniques
US7401125B1 (en) 2000-10-10 2008-07-15 Ricoh Corporation System, computer program product and method for managing documents
US8275852B2 (en) 2000-10-10 2012-09-25 Ricoh Americas Corporation System, computer program product and method for managing documents
AU785195B2 (en) * 2000-10-18 2006-11-02 Mark Richard Cooper Service management system
EP1220124A3 (fr) * 2000-12-28 2003-03-05 Hitachi, Ltd. Méthode pour soutenir l' introduction d'un participant et méthode et système pour l' introduction d'un participant
US7917406B2 (en) 2000-12-28 2011-03-29 Hitachi, Ltd. Introduction support method and system, and introduction method and system
US20100017337A1 (en) * 2008-07-17 2010-01-21 Butler Rhett A Establishing a buyer/service provider relationship electronically
RU2777274C1 (ru) * 2021-04-20 2022-08-01 Общество с ограниченной ответственностью «Обоз» Способ организации компьютерной логистической сети с использованием доменной древовидной иерархической структуры и система для её осуществления

Also Published As

Publication number Publication date
AU2386100A (en) 2000-07-24

Similar Documents

Publication Publication Date Title
US7016866B1 (en) System and method for assisting the buying and selling of property
US8775322B2 (en) System for matching buyers and sellers based on buyer seller preferences
US7617128B2 (en) Online transaction hosting apparatus and system
US8452659B2 (en) Method and apparatus for connecting consumers with one or more product or service providers
US8027885B2 (en) Complex prices in bidding
US20100125803A1 (en) Online System for Communications Between Service Providers and Consumers
US20020133365A1 (en) System and method for aggregating reputational information
US20040019494A1 (en) System and method for sharing information relating to supply chain transactions in multiple environments
US20050171858A1 (en) Multi-vendor online marketplace
Madnick et al. Seizing the opportunity: Exploiting web aggregation
US20060064409A1 (en) Method and system for electronic barter
US20030069744A1 (en) Networked referral commission system
US20080195605A1 (en) Service directory and management system
WO2003054667A2 (fr) Ventes a l'echelle mondiale par reseau de recommandation
WO2000039729A1 (fr) Procede et systeme de traitement et de transmission de donnees electroniques de mise aux encheres inversees
US20120296780A1 (en) Systems and methods for exchanging product information
US9836773B2 (en) Evaluation and selection of quotes of a commerce network
US20120271735A1 (en) Method and apparatus for providing an electronic commerce platform
US20030083895A1 (en) Networked referral commission system with customer service functions
US20140337144A1 (en) System And Method For Facilitation Of The Marketing And Sale of High Value Items Over A Network
JP2005149499A (ja) 電子商取引における収集されたプライバシ・ポリシを集合プライバシ・ポリシとして識別および実装するための方法、システム、およびコンピュータ・プログラム
US20060265308A1 (en) System and method for paperless bid management
Büyüközkan A success index to evaluate e-marketplaces
US20200242174A1 (en) Methods and systems for facilitating procurement of construction goods and services
WO2000041087A1 (fr) Mise en correspondance de fournisseurs de services avec des clients et production de donnees de recherche produit/service

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase