WO2000072213A1

WO2000072213A1 - Systems and methods for electronic commerce

Info

Publication number: WO2000072213A1
Application number: PCT/US2000/014365
Authority: WO
Inventors: Daniel Nissanoff; Mark Allan Schenecker
Original assignee: Partminer, Inc.
Priority date: 1999-05-24
Filing date: 2000-05-24
Publication date: 2000-11-30
Also published as: AU5288100A

Abstract

A system and method for satisfying a customer's request (100) to purchase a particular product, part or service when none of the customer's existing vendors can do so. The invention operates by way of the Internet (108), providing customers (102) with a single interface (106) for relaying all of their requests to each of their vendors (104) regardless of the communication medium through which a particular vendor prefers to have any requests provided. The host (110) formats the customer's request in accordance with its vendor's preferred transmission modes and conveys responses back to the customer through the Internet, e.g., by e-mail or through a Web browser. The invention introduces a host-approved vendor to the customer only when the customer's existing vendors do not have the requested product. The existing business relationships between the customer and its existing vendors are not disrupted nor are they displaced because those vendors were not able to satisfy the request. A subsequent request by the same customer for the same product will be conveyed only to the customer's existing vendors to again give those business contacts a first chance to satisfy the request.

Description

SYSTEMS AND METHODS FOR ELECTRONIC COMMERCE

CLAIM OF PRIORITY

This patent application claims priority under 35 U.S.C. §119 from U.S. Provisional Patent Application Serial No. 60/135,538, filed May 24, 1999, entitled "Systems and Methods for Electronic Commerce," which application is hereby incorporated by reference as if set forth in its entirety herein.

FIELD OF THE INVENTION

This invention relates to systems and methods for conducting business on public networks such as the Internet and more particularly to an improved business model for electronic commerce.

BACKGROUND OF THE INVENTION

Over the centuries, commerce has taken on many forms but none has attracted as much attention as electronic commerce on the Internet. Fundamentally, electronic commerce includes the exchange of goods and services for payment; however, business models continue to evolve, which provide innovative approaches to generating revenue, automating business processes, increasing demand for products, and providing sales, support, and tracking services.

Most electronic commerce initiatives have been extensions to current business models, a typical example being the proliferation of catalog-oriented websites. Such websites provide an additional channel to extend the existing catalog or telemarketing sales of the organization. The success of such sites has been decidedly mixed. However, with continuing improvements in communication capabilities of Internet Service Providers (ISPs) and reductions in access costs to customers, web based commerce is emerging as the potentially dominant marketplace for many goods and services.

Perhaps the most common form of business model on the Internet is the electronic commerce marketplace. The marketplace solution brings together many buyers and sellers at a single website. The cost of the marketplace is spread amongst the participants and therefore provides tremendous economies of scale. At present, electronic commerce can be generally classified into three distinct markets for business. Sell-side electronic commerce follows a classic electronic commerce model: enabling an organization to sell products or services to multiple buyers. Sell- side solutions are characterized by robust electronic commerce catalogs that contain detailed product information. The client interface, which is typically made available through a conventional web browser, is designed to attract and retain potential buyers. To that end, the sell-side solution provides intuitive yet powerful methods for locating products in the catalog. The most common method is through an interface which permits the buyer to search the wares of the seller at the seller's website. The attraction of the electronic commerce experience is that buyers go on line because they expect the experience to be easier and faster than traditional shopping. In order for a sell-side application to be successful, a buyer must be able to obtain fast and accurate product information and pricing, in addition to trouble-free order processing and fulfillment. Typical examples of sell-side applications include Amazon.com, eToys and Dell Computer which let buyers place orders over the web.

The buy-side commerce model places the electronic catalog at the purchaser's site. In that business model, the buyer's computer system is the central point of control for the selected procurement activities, with the purchasing activities of the organization being consolidated among a limited set of vendors so that the organization can negotiate more competitive prices. The most common form of a buy-side application is an intranet site which enables authorized personnel to make purchases such as office supplies with selected vendors. The buy-side application provides the buyer with electronic catalogs of products from such vendors, for example, as Staples and/or Office Depot. This business model forces the purchaser to acquire from each of its suppliers and aggregate into its own system all of the product data that it is interested in accessing, including prices, quantity, specifications and the like.

Finally, the marketplace model brings multiple buyers and sellers together. Such a business model exploits the ubiquitous nature of the Internet with the marketplace provider (a.k.a., the aggregator) supplying the necessary infrastructure to let the multiple parties transact business. Electronic marketplaces, so far, have enjoyed the most success in vertical applications in which buyers and sellers have specific domain knowledge of a product type, such as knowledge of commodity products including steel, plastics and chemicals. In vertical applications, the marketplace provides an additional sales channel for the selling organization and provides a new way to sell products and to move excess inventory or production overruns.

An auction site is an example of one specific marketplace model. At an auction site, sellers submit products at a reserved price and can even restrict the number of potential participants. The marketplace site manages the bidding, award and sales process. The seller can choose to award the bid on-line or off-line, depending on the complexity of the transaction (e.g., depending on payment and shipping alternatives).

A marketplace on the Internet has compelling interest for a consumer both in terms of efficiency and price. A single marketplace can potentially aggregate products from hundreds or even thousands of suppliers into a single website. The consumer can easily locate products without having to search numerous individual websites, and the consolidation of many suppliers tends to create a more competitive pricing environment for the buyer. On the other hand, the competitive pricing environment has deterred some sellers from making their goods and services available in such a forum out of a fear that the pricing for their wares could be commoditized, that is, brought down to such a low level that the profit margins, if any, are slim. This, in turn, has negatively impacted some buyers.

What is needed in the art of electronic commerce and has heretofore not been known is an electronic commerce model which provides an efficient marketplace and which better preserves the integrity of existing relationships between the buyers and sellers. The present invention satisfies these and other needs as described below. SUMMARY OF THE INVENTION

In one aspect, the invention assists a customer in satisfying a request to purchase a particular product in response to a prescribed condition, such as in the event that none of its existing vendors can satisfy the request or the request is only partially satisfied by one or more vendors. In this aspect of the invention, a method is provided through the Internet for introducing one or more host-approved vendors to the customer. When the customer's existing vendors do not have the requested product, the server operating the hosting Web site either introduces another supplier of product to the customer to satisfy the request, or offers to satisfy the request itself. Thus, the relationships between the customer and its existing vendors are not disrupted nor are they displaced because those vendors were not able to satisfy the request.

A method in accordance with this aspect of the invention obtains at a host Web site a request received from the customer through an Internet connection. The host Web site relates the request to one or more vendors selected by the customer for filling (i.e., satisfying) such a request. The relationship between the customer's request and the particular vendors to contact are preferably maintained in a data store connected to the server that implements the host Web site. That data store can include other information including a central catalog of items specific to the domain provided by the Web site. The customer's request is conveyed by the host Web site to each of the customer-selected vendors and, only in the event that none of the customer-selected vendors can satisfy the request or only one or more of such vendors can only partially satisfy the request, the request is conveyed to the host-approved vendor.

In accordance with this aspect of the invention, the customer need not be advised of the identity of the host-approved vendor in the event that such a vendor is used to fill (i.e., satisfy) a customer's request. The host-approved vendor can be the host itself or a vendor selected by the host. Further, the re-direction of the customer's present order to a host- approved vendor does not affect the list of customer-selected vendors, in other words, the order re-direction is a one-shot occurrence. Preferably, upon receiving the customer's approval to fulfill a request in that situation, the items are packaged with the host's name and without reference to the host-approved vendor so that the customer's only knowledge as to the source of the requested ware is the host. Packaging can be at the host's facilities or at the host-approved vendor.

In another aspect, the invention coordinates all customer requests and responses through the Internet such as through the host Web site or by e-mail. In accordance with this aspect of the invention, e-commerce between a customer and a set of pre-selected vendors with whom the customer has an existing relationship is facilitated by unifying the interface through which the customer places requests despite the potentially disparate communication requirements of each customer's selected vendors.

In practice, each of a customer's pre-selected vendors has an established communication format which it uses to communicate with its customers. A method in accordance with this aspect of the invention accepts over an Internet connection a request from a customer and, for each of the customer's pre-selected vendors, formats the request for delivery in a communication format established by that vendor. The request is then delivered to each of the pre-selected vendors in the format established by such vendors, and, importantly, the customer is provided with a response to the request over the Internet.

In another aspect, the invention provides a method operative across a distributed computer network for providing a customer with responses that satisfy a request. That method comprising the steps of providing from a customer station a request to purchase a product or service and also providing from the customer station information which relates one or more customer-selected vendors, with whom the customer has an existing relationship, with the product or service in the request. The customer station receives from the host any responses to the request from the customer-selected vendors and selectively receives from the host responses to the request from one or more host-approved vendors only upon a prescribed condition, such as when a market failure condition has been detected.

The invention includes one or more systems and methods as described hereinabove and with reference to the accompanying Drawings and Detailed Description.

DESCRIPTION OF THE DRAWINGS

Fig. 1 is an illustration of a hardware arrangement that is used with the present invention; Fig. 2 is a logical diagram of the information flow in accordance with the present invention;

Fig. 3 is a flow diagram of the process for conveying orders from a customer to its pre-selected vendors;

Fig.4 is a process flow for outsourcing a customer's request when the customer's pre-selected vendors are unable to satisfy the request; and

Fig. 5 is a detailed flow diagram illustrating process flow of a preferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS By way of overview and introduction, the present invention provides an improved business model for electronic commerce on the Internet. As a departure from prior electronic commerce models, the invention provides a marketplace in which customers can communicate with a group of their pre-selected vendors in order to make inquiries and have their requests filled (i.e., satisfied) for a variety of wares (e-g-, goods and services). Importantly, the marketplace of the present invention permits vendors to freely make their wares available to all of their customers while simultaneously restricting access by members of the general public. As a result, the competition experienced by each of the participating vendors is limited to those vendors that have been pre-selected by the customer for a particular part, good, or service. The present invention also provides a hospitable forum for satisfying customer inquiries without disrupting existing relationships between the customer and its pre-selected vendors: in the event that a customer' s request cannot be satisfied by any of its group of pre-selected vendors, the host site fields the request and offers to satisfy it. In this way, customer satisfaction is increased without sacrificing the existing relationships between the customer and its selected vendors.

With reference now to Figure 1, an overview of a hardware arrangement that can be used to implement the system and method of the invention is illustrated. The hardware arrangement 100 interconnects a plurality of customer stations 102 (hereinafter, more generally "customers 102") with the plurality of vendors 104a, 104b, 104c, etc. (more generally, vendors 104) through an electronic marketplace maintained by a host server 106. Customers access the host 106 through a conventional connection to the Internet 108 and convey all their inquiries and requests through the Internet and also obtain replies to such inquiries and requests over the Internet. Vendors 104 make their catalog data available through separate connections over the Internet 108, but can communicate with the host 106 using other hardware devices.

The host includes a server 110 which is configured to implement the marketplace of the present invention. The server 110 includes a data store 112 which preferably is configured to store vendor and customer data. The server communicates with each vendor through a variety of devices, including a communications interface for electronic data interchange 116, e-mail, fax/ scanner 118, speech synthesis using a voice conversion/recognition system as is known in the art, and the Internet. Each of these devices is connected to a plain old telephone system (POTS) or T-l communication link 120. The vendors 104 each have a Web interface and, depending on the vendor, can also have an electronic data interchange interface, fax machine, and/or a telephone through which they agree to receive requests and convey responses. Regardless of the transmission mode between the host 106 and the vendors 104, all communications with the customers 102 are through the Internet (e.g. via e-mail or through a Web browser). The host 106 may further include a Web enabled purchasing system

(WEPS) database 130 which is used in the preferred embodiment to satisfy customer requests without disrupting existing customer relationships. In that case, the host 106 preferably but optionally includes a catalog 140, maintained in electronic form, which can be accessed by customers through the Internet 108. Through the hardware arrangement 100, customers access the host 106 and enter their queries or requests for handling. The host 106 accesses the vendor- customer database 112 to identify the vendors 104 associated with the customer's request and thereafter relays the request through a predetermined transmission mode. As will be appreciated from the discussion below, the particular transmission mode that is used to convey a customer' s request to a particular vendor will vary with each vendor. In this way, each vendor 104 receives requests in a preferred format.

With reference now to figure 2, the system and method of the present invention is described with respect to a logical representation of the communications between a customer and one or more of its pre-selected vendors. The hosted marketplace provides a marketplace 200 in which the customers 102 and vendors 104 come together. For each good or service that a customer wishes to purchase through the system, he or she will have a pre-selected vendor or group of vendors with whom it ordinarily transacts, which is preferably maintained in data store 112 at the host 106. In a conventional manner, the vendors 104 maintain a database of their customers and account numbers for each such customer. In coordinating the request of the customers 102, the host 106 preferably accesses the data store 112 for a list of the vendors from which the customer ordinarily sources the requested parts, goods or services, or, more generally, a category of such parts, goods or services (e.g., office supplies). For example, a particular customer 102 may purchase staples from vendors 104a and 104b but only purchases paperclips from vendor 104b. The customer requesting to purchase paperclips is directed through the Internet to the host 106, as shown by the arrow labeled 1 in Fig. 2. Upon receiving the request for paperclips, the host 106 accesses the vendor-customer database 112 for vendor contact information. The host conveys the request in a manner specified by the vendor 104b (see arrow 2) and obtains a quote from the vendor 104b in response (see arrow 3). Vendor 104b will either be able to satisfy the request for paperclips or will not be able to do so. In either case, the host will report such information back to the customer 102; however, in the event that none of the vendors can satisfy the request or in the event that only a portion of the request can be satisfied, the host 106 outsources the customer's request for processing and satisfaction. Preferably, the request is conveyed to WEPS 210 (see arrow 4), but could be conveyed directly to any host-approved vendor. When the request is conveyed to the WEPS 210, it is preferably conveyed by a LAN connection between the host and WEPS, a WAN connection, or could be a signal transmission within the same machine. That is, WEPS 210 can be a program running on the server 110 of the host 106.

As will be explained in detail below, WEPS 210 accesses the WEPS database 130 to determine whether other vendors of the requested component (e.g., paperclips) are known to the system so that requests for quotes can be sent to known vendors. Back office personnel can assist in locating vendors and obtaining quotes, if necessary.

The WEPS 210 may determine that vendor 104c sells paperclips and thereafter it sends the request for quote ("RFQ") to at least that vendor through a predetermined communication medium (such as the Internet, an electronic data interchange connection, fax, etc.)(see arrow 5). Vendor 104c provides a quote in response (as shown by arrow 6) which is received by the WEPS 210. The quote can be marked-up in price based on pricing and availability information available to the WEPS 210, and is conveyed back to the host 106 (see arrow 7). Finally, the host provides the responses to the customer' s request through the Internet connection 108 (see arrow 8). The responses include the fact that the customer's pre-selected vendor 104b was unable to satisfy the request and that the host has a vendor able to fulfill this request if the customer accepts the quote. Importantly, the pricing and availability of good and services from vendor 104b (pre-selected by the customer) and vendor 104c (brought to the customer's attention by the host) are not directly competitive with one another; rather, the customer has conveyed his request only to his designated and pre-selected vendors, with the host responding to this particular request with an offer from a blind source of goods (i.e., an anonymous vendor) only in the event that the customer's designated vendors are unable to fully satisfy the request. With reference now to the flow diagram of Fig. 3, the process steps that are used to convey a customer's request over the Internet to its pre-selected vendors is described.

The method set forth in Fig. 3 facilitates electronic commerce ("e- commerce") between a customer and a set of pre-selected vendors with whom the customer has an existing relationship. The existing relationship ordinarily arises out of prior business transactions between the customer and the vendor for particular goods, services or parts that the customer may require from time-to-time. The vendor ordinarily assigns each of its customers a unique customer number using its own assignment scheme. Further, each of the vendors that has been selected by a customer has an established format by which it prefers to receive communications. For example, some vendors prefer to receive RFQs using an electronic form sent over an EDI communication link, while other vendors prefer to receive RFQs by fax or other means. The host 106 maintains in its vendor-customer database 112 data records which relate the particular requests of a customer to specific vendors. The vendors to whom the request is to be presented can be related through a bill of materials ("BOM") previously provided to the host 106 or provided along with the request.

At step 300, the marketplace 200 made available by the host 106 allows a customer 102 to convey an RFQ (or other requests) to one or more vendors 104. A customer 102 accesses the Internet 108 through conventional means and navigates to the marketplace 200. At step 302, the host 106 obtains the request from the customer, preferably a request that was received over the Internet 108. The request may be in the form of a BOM which identifies one or more parts that the customer is interested in purchasing. The customer's vendor selections for that request can be obtained from the database 112. Alternatively, the request itself may include a list of the vendors with whom the customer ordinarily deals, as obtained from a form presented on the customer's browser which permits the customer to submit vendor identifying data in addition to goods, services or parts identifiers.

The vendor-customer database 112 includes transmission mode data which identifies an established communication format that a vendor uses to receive requests. For each of the pre-selected vendors to whom the particular request is to be transmitted, the established communication format for that vendor is obtained from the database at step 304 and the request is formatted in accordance with that data at step 320. The formatted request is then delivered to the vendor at step 322 and this procedure is repeated for each of the pre-selected vendors. Fig. 3 shows this process in detail. The formatting and delivery of customer requests is illustrated as a double-nested loop; however, other methodologies can be used with equal advantage as understood by those of skill in the art. Formatting entails placing the information in the request in a specified order or in specified fields and adding any headers or handshake-required information to make the request ready for transmission in accordance with the established format of the vendor.

With further reference to Fig. 3, at step 306 an index I is set to an initial value and is used to sequentially address each of the pre-selected vendors. Using the index I, successive vendors are addressed at step 308 and for each vendor, a second index J is used (step 310) to access established transmission modes for the presently addressed vendor (step 312). For example, the transmission modes may include electronic data interchange, fax, telephone, etc. Preferably, the transmission modes are arranged in the vendor-customer database 112 so that the transmission mode with the highest order value is indexed first and transmission modes with successively lower order values are indexed thereafter. In this way, the first indexed transmission mode is the preferred transmission mode and is the first mode selected for formatting and transmitting the request to the vendor, at steps 320 and 322. At step 324, a test is made whether the transfer was successful. If the transfer was not successful, then the transfer mode pointer J is advanced at step 328, and, if the transfer modes for that vendor have not been exhausted, as tested at step 326, then a next transfer mode is accessed. Using the new transfer mode pointer, a next transfer mode for the vendor is picked-off at step 312, the customer's request is reformatted in accordance with the newly-selected transfer mode, and then conveyed to the same vendor using the newly-picked transfer mode. Again, the system tests whether the transfer was successful at step 324 and, if unsuccessful, repeats the loop through steps 312-324. On the other hand, a successful transfer will provoke a response from the vendor(I) as to whether that vendor is able to satisfy the request, which response is tested at step 330.

The foregoing process is repeated for each of the pre-selected vendors for the particular request and is achieved in the flow diagram of Fig. 3 by advancing the vendor index I at step 332 and looping back to step 308. At this stage, a next vendor in the customer's list of pre-selected vendors is indexed, and the inner loop (guided by the index J) repeats until a transfer mode for the newly-addressed vendor is obtained, the customer's request is formatted, and successfully conveyed as tested at step 324.

Thus, for each vendor(I), a determination is made whether a vendor is able to satisfy the order at step 330. The loops 312-328 and 308-342 repeat until the total number of pre-selected vendors(M) has been queried, as tested at step 340. For each vendor that is able to satisfy the request by filling all or part of the customer's order, individual or combined reports are provided to the customer over the Internet at step 342. However, in the event that none of the pre-selected vendors is able to satisfy the request (i.e., if an unable-to-satisfy array, for example, contains "false" entries for each of the pre-selected vendors), as tested at step 344, then at step 350 that particular request is outsourced by the host 106, in accordance with a further aspect of the invention as described below in connection with Fig. 4. Otherwise, the customer will be provided with responses from its pre-selected vendors and no other vendor, with the process terminating at step 360.

Alternatively, the results (i.e., the number of parts, goods, etc. identified in a particular vendor response) can be tabulated for all of the pre-selected vendors. For those vendors that respond within the customer's designated time- period, the system collates the results in step 342. After all vendors have been tested at step 340, the system performs a final decision in step 344 to determine whether the pre-selected vendors have fully satisfied the request from the customer. If the request has not been fully satisfied, then at step 350 the request is outsourced by the host. The system uses attributes of the customer and vendor as well as the transaction to determine if the request has been fully satisfied. Attributes may include, but are not limited to, the following: quantity, part substitution, delivery date, lead time, price variance, credit terms, past delivery history, and split or consolidated shipments From the foregoing, it should be understood that the marketplace 200 is intended to satisfy a customer's requests by facilitating a customer's ability to request a quote (for delivery of a specific quantity of an item by a certain date, and with other terms as may be specified by the customer, as is conventional) and to receive quotes from the vendors with which it does business. A market failure condition can occur, however, when no vendor responds to the customer's request, or if no individual vendor responding to the request can satisfy the request, or if the customer's vendors, in the aggregate, cannot satisfy the request. In any of these events, a customer's request can be satisfied without disrupting existing customer relationships by automatically outsourcing the customer' s request from the host to the WEPS 210 or directly to any host-approved vendor.

A market failure is detected by way of a software program which compares the quotes against the request to determine what system response, if any, is required. If the quotes do not fully satisfy or only partially satisfy the request, then the system response can be the automatic outsourcing of the request to one or more host-approved vendors. Alternatively, if the responding quotes do not fully satisfy or only partially satisfy the request, then the system response can be to activate a window or display a page (e.g., within a Web browser) at the customer's station 102 which includes a shortage button which permits the customer to have the request conveyed to host-approved vendors. Other system responses are possible, and the particular response is preferably governed by a rule base which defines the action that the host 106 takes. The rule base can include plural rules that are hierarchically ranked and selected depending on the particular situation. Thus, there may be no automatic system response if the customer selected vendors, in the aggregate can satisfy the order. Also, there may be no automatic system response if the request is for an amount which is below a threshold dollar value, or if the customer has insufficient transactional history with the host 106, or an insufficient credit history or credit standing for the system to process the request. The rule base can be implemented, for example, by the account manager routine which is described below in connection with step 506 of Fig. 5. A market failure detected through the comparison of requests and responding quotes, therefore, can look at discrepancies between the two in terms of the quantity, price substitution, price variance, delivery date, lead time, credit terms, past delivery history, terms of payment (e.g., currency), split or consolidated shipments, or other discrepancies, or a combination of the foregoing. Also, a market failure can be detected on some other basis such as a pricing variance that has been detected by an automated "agent" -as described next— which can be sent out by the host to identify an existing auction or venue at which a quantity of the part can be obtained at a more favorable price from a third party.

Even in the absence of a market failure, the customer optionally can be provided with a feature (e.g., a button labeled "shortage") that enables him or her to invoke the WEPS 210 and have the request conveyed to host-approved vendors. The shortage button enables a manual request by the customer to the host to convey the request to host-approved vendors, and can be done even when a customer-selected vendor, or a group of customer selected vendors, can satisfy the request. The shortage button can appear, for example, in a window displayed on the customer's computer 102, perhaps along with the quotes received from those of the customer's pre-selected vendors that responded to the request. When the customer invokes the WEPS using this button, at least a portion of the terms of the request are made available to the WEPS. For example, the WEPS is informed of the quantity of the order and its delivery terms, and may further be apprised of the part availability indicated by the customer's pre-selected vendors. However, in the preferred embodiment, the WEPS is not informed of the price bid by the customer's suppliers, or perhaps of other information concerning the customer's selected suppliers.

In furtherance of another aspect of the invention, the preferred embodiment can include an "agent" which shops the terms of a given request (e.g., an RFQ) among various auctions supported by auction servers on the Internet (see auction server 220 of Fig. 2). An "agent" is a program that gathers information or performs some other service, typically without the user's immediate presence and on some regular schedule. Typically, an agent program, using parameters specified by the user, searches all or a designated part of the Internet, gathers information in accordance with the user-specified parameters, and presents it to the user on a daily or other periodic basis. An agent is sometimes referred to as an "intelligent agent" or "bot" (short for robot).

Through the use of an agent, any auction in which a product specified in a customer's request or RFQ can be pushed into the marketplace 200 for selection by the customer. This enables the customer to enjoy the benefits of the so-called "business-to-business" auction Web sites that now exist, at which product is intended to be sold at auction, without spending time to determine if the desired part (or apart that is compatible with the desired part) is available through another forum. The use of an agent also provides the customer with the opportunity to satisfy a portion of a request at a potentially favorable price through the auction market while satisfying the remainder of the request through purchases with its established vendors.

In accordance with an important aspect of the present invention, the host processes requests received from customer through an Internet connection and reports any responses back to the customer through the Internet connection. The host web site formats the customer's request in any manner that is required to convey the request to a particular vendor selected by the customer. The host 106 includes tool sets which permit the customer to identify its designated vendors to the host 106 with the host automatically determining the appropriate format for conveying the request. On the other hand, the host maintains a database which correlates the preferred transmission modes of a plurality of vendors, including the pre-selected vendors of the customer for the particular request obtained at the host web site. Using the database 112, the host can access an ordered set of transmission modes associated with each of the pre-selected vendors and, thereafter, successively select transmission modes of descending order value so that the customer's request can be converted into a compatible format. For example, a particular vendor may prefer to have RFQs submitted by way of forms through the Internet and as an alternative mode may require all requests to be submitted by facsimile. The database 112 in this example would include a set of two transmission modes associated with that vendor and would arrange them with Internet forms as the highest order transmission mode for selection by the system and facsimile transmission as the next, lower order mode.

The transmission modes and other vendor-specific information are preferably related in the database 112 to specific goods, services, or parts. By relating in the database particular goods, services or parts to specific vendors, the customer can identify a desired ware in a web browser form and submit the form to the host 106. The host can respond with a vendor list of those vendors that the host has determined are suppliers of the designated ware. The customer can select a vendor from that list, but will only be permitted to post the request to that vendor if the customer has an existing relationship with the selected vendor. In this manner, the customer is not able to "shop" a request for quote to a vendor with whom it does not have a prior relationship. Optionally, the system filters the set of vendors in the vendors selection list to include only those that the customer has previously identified as being one of its vendors.

Upon submitting a request, the host system can parse the request to identify what is being requested and which vendors, if any, are being listed as potential suppliers of that item. Preferably, the system continuously accumulates data relating vendors and the parts that it supplies so that the system is able to readily identify sources of parts in the event that it executes its outsource-handling routine, described below. The marketplace 200 of Fig. 2 provides a service to both customers and vendors without charge. As in other Internet applications, advertisements can be displayed in the marketplace 200 web page as a source of revenue to the host 106. However, neither the customer nor the vendor need experience a charge for the services provided by the host in garnering requests from customer, disseminating them in multiple formats to pre-selected vendors, and relaying the information back to the customers. In providing this service, the host is able to accumulate information regarding vendors, the wares they sell, and the volume in their quotes and other data which enables the system to manage new and improved relationships with the customers. At all times, the marketplace 200 remains customer-centered, with each customer's vendors available through the web site for responding to requests. This contrasts sharply with presently known "aggregator" sites which choose the vendors that are available at the marketplace and therefore are not customer-centric.

The invention includes a new source of revenue which is derived from a value-added benefit provided to the customers that come to the marketplace 200. In particular, in the event that the test at step 344 fails, that is, the customer's preselected vendors have been unable to fully satisfy the customer's request, then and only then will the host 106 outsource that particular request at step 350 to determine whether some other vendor (including the host) can satisfy the request. In the prior example concerning the purchase request for paperclips, the host 106 outsources the customer's request to a host-approved vendor because the only vendor that the customer had pre-selected (vendor 104b) was unable to satisfy the terms of the request.

With reference now to Fig. 4, the process flow of a web-enabled purchasing system 210 is described as one preferred method for satisfying an outsourced request. The process of fig. 4 starts at step 400 with the receipt of the outsourced request from step 350. At step 410, the WEPS database 130 is accessed to obtain a list of one or more host-approved vendors to whom a particular request is to be sent. It should be understood that the outsourcing can be handled by any host-approved vendor, for example, by outsourcing the request through a bid engine which awards the request to a vendor based on predetermined criteria. The criteria may include whether the vendor has paid a royalty for being included on the selection list, a determination of which vendor will supply the requested ware at the lowest price or one or more other criterion.

With further reference to Fig.4, the outsource-handling routine relays the customer's request to one or more host-approved vendors, e.g., vendors that are not among the vendors that were pre-selected by the customer. Thus, for example, at step 420, a host-approved vendor Index K is initialized and used as a pointer at step 430 to point to a first vendor K to whom the request is to be conveyed. The arrangement of vendors (that is, which comes first) may be a further source of revenue in the present business model. The addressed vendor is then compared against the vendors that were selected by the customer at step 440 and if the host- approved vendor was a previously selected vendor of the customer, then the host- approved vendor Index is incremented at step 442 and a test is made at step 444 as to whether all of the host-approved vendors have been queried. If not, when the process loops back to step 430, the next vendor is addressed. On the other hand, if the addressed vendor is not among those that were pre-selected by the customer, then at step 450 the addressed vendor is queried to determine whether it can satisfy the customer's request.

Alternatively, the host-approved vendor to which the WEPS 210 conveys the request can be a vendor selected by the customer. This can occur, for example, when the host 106 knows of additional locations or fulfillment houses of that vendor that might be able to satisfy the customer's request even though the customer's request was not able to be satisfied by that vendor.

The goal of the outsource-handling routine is to locate a vendor that is able to satisfy the customer's request. Of course, there is no need to report to the customer the inability of a particular host- approved vendor to satisfy the customer's request. Therefore, in the event that the test at step 452 as to whether the vendor can satisfy the request is negative, then the host-approved vendor Index is incremented again at step 442 and, if the list of host-approved vendors has not been exhausted, then the process again loops to step 430. On the other hand, if that vendor can satisfy the request, then the outsource-handling routine posts that result to the host at step 460. The host then does price mark-ups on the identified item, including an update of its customer-vendor database 112 and ultimately reports the price quote to the customer (see arrow 8 of Fig. 2). In the event that each of the host-approved vendors has been queried as to whether they can satisfy the request and none of the vendors can do so, then at step 470 a message is relayed to the host that the outsource handling routine is unable to satisfy a customer's request, and that information is in turn conveyed to the customer 102. With reference now to Fig. 5 , the invention is described in connection with the preferred embodiment in which the requests are RFQs and the responses are quotes. In Fig. 5, the process is customer initiated as illustrated at step 500. Having connected to the host over the Internet, the customer enters into a standard form an RFQ in one of a variety of ways (see step 502). The RFQ may be entered manually with the customer entering part numbers into the form. The host 106 maintains a master catalog of all of the parts that relate to the Web site. Using the master catalog, the part numbers entered by the customer can be validated and any part number that is not recognized or included in the master catalog can be flagged as unprocessable and a suitable alert provided to the customer through the Web browser. A like processing method is used to filter and screen responses by vendors to RFQs distributed by the host to the vendors 104. Another way of entering the RFQ is to first perform a parametric search against the master catalog with part numbers being retrieved as the search results. For example, a customer can search for a timer and retrieve a part number as well as the identity of various manufacturers of the part. The selected device will be the part number included in the RFQ. Yet another way of creating an RFQ is by parsing one or more existing BOMs. The BOMs can be input to the RFQ creation process. Yet another way of creating an RFQ is through a validated upload in which a customer prepares the RFQ offline using a local tool which is thereafter uploaded to the host. Part numbers are parsed from the uploaded file and validated against the master catalog for accuracy as described above.

Upon posting the RFQ to the host 106, the contents of the form are parsed by the host and, if the customer has identified its vendors for the requested part, or if the vendor-customer database 112 includes a prior vendor selection for that customer, then the request will be automatically routed to the marketplace 200, as indicated at steps 504a, 504b, and 504c.

At step 504, the process flow of Fig. 3 is performed, including formatting the request into the appropriate format for the customer's pre-selected vendors and delivering the request to the vendor in the established format (step 504a). As described above, through the marketplace 200, quotes from the vendors can be provided to the customers and billed directly through communications in the marketplace 200 (step 504b). Communications proceed back and forth between the customer 102 and the vendor 104 byway of the host 106, with all of the transactions being logged in a discussion database for later processing. To the extent that there are requested items for which no vendor has been pre-selected, or when none of the pre-selected vendors can satisfy the customer's request, a market failure condition flag is set (step 504c), and a rule-based engine operates in response to the flag to notify the account manager, as shown at step 506.

The account manager, which preferably is an automated routine programmed to run on the server 110, responds to any RFQs and quotes prior to the customer receiving a response to the RFQ, as shown in steps 508-514. Initially, the account manager searches the master catalog that is either maintained by the host 106, one or more host-approved vendors 104, or both at step 510. In the event that the RFQ is located in inventory and the price is available from the database accessed by the account manager, as determined at step 512, then a firm quote or price with the RFQ is formatted for transmission to the customer, as at step 514, and the customer is contacted with regard to that quote at step 516 manually or automatically through the marketplace 200 provided by the host 106. If the customer accepts the quote at step 518, then a purchase order will issue. The communications between the account manager at the host 106 and the customer 102 are preferably done exclusively through the Internet. Upon issuing a purchase order, a sale order is created and routed to the back end of the system at step 520. The back end of the system forms no part of the present invention and concerns the mechanics of checking a customer's credit as at step 522, issuing a purchase order to the vendor that is supplying the part being sold to the customer at step 524, obtaining acknowledgments from the vendor at step 526, obtaining the product and the invoice from the vendor at step 528, repackaging the product in host-branded packaging and shipping same to the customer, as shown at step 530.

On the other hand, if the part requested in the RFQ is not currently available, then the process still proceeds from step 512 to step 540 wherein the RFQ is forwarded to a buyer. The buyer is an individual that works for the host and is charged with the responsibility of contacting various suppliers using any suitable transmission means to obtain quotes on pricing and availability of components as shown at step 542. The buyer interacts with a number of vendors as illustrated at step 544 and the price of inventory information obtained by the buyer is entered into the "database" at step 546 to extend the knowledge base of the master catalog. Now armed with additional price and inventory information, the system at step 548 routes the RFQ back to the account manager for further processing.

In this preferred embodiment, the information obtained by the buyer is provided to the account manager (see step 508) which marks up the price quoted by the vendor based on pricing and availability information in the master catalog. It must be remembered that the customer's pre-selected vendors were unable to satisfy the request and the host 106 has used its resources and buying power to secure a favorable price for the requested component and earn the price mark-up.

As described above in connection with steps 510 and 512, the account manager creates a quotation for a presentation to the customer at step 514. The account manager routine may communicate with the identified vendor to obtain a better price, or a flag may be set to alert a supervisor to manually call the identified vendor and attempt to negotiate a better price.

As used herein, the term "fill" refers to a responding vendor's ability to meet or satisfy the requirements stated in a request (e.g., an RFQ). The requirements of a request are fully satisfied if all of its terms are met in a vendor's response. The requirements of a request can be partially satisfied by a vendor's response which does not match all of the terms of the request.

While the preferred embodiment concerns requests for and shipping of component parts, the invention is not so limited. The invention has industrial applicability in a variety of applications including the sale of finished goods and services. In particular, in any environment in which the customer has existing business relationships with one or more suppliers of goods or services, the system and method of the present invention can be used to facilitate communications between the customer and its vendors while simultaneously freeing the customer of having to maintain catalog data in its own facilities. The system and method of the present invention extends existing customer- vendor relationships by fulfilling requests that the customers' vendors are unable to satisfy without antagonizing or straining the existing business relationships between the customer and its vendors. The present invention can be implemented in a variety of forms on a variety of machines operating under any number of software platforms. The invention is not to be limited by the foregoing detailed description but instead is to be limited only by the claims appended hereto and equivalents thereof.

Claims

What is Claimed is: 1. A method for introducing a host-selected vendor to a customer through the Internet for the purpose of selling a particular product or service and without disrupting existing relationships between the customer and its vendors for the product or service, comprising the steps of: (a) obtaining at a host Web site a request received from the customer through an Internet connection; (b) obtaining at the host Web site relationship-data which relates the request to one or more vendors selected by the customer; (c) conveying the request obtained by the host Web site to the customer-selected vendors; and (d) conveying the request to the host-approved vendor only upon a prescribed condition.

2. The method as in claim 1, including the additional step of reporting to the customer any responses to the request through the Internet connection.

3. The method as in claim 1, wherein the host- approved vendor is one of the host Web site and a third-party vendor.

4. The method as in claim 1 , wherein the requests are requests for quotes and the responses are quotes.

5. The method as in claim 1 , including the additional steps of obtaining from the customer (1) a product or service selection and (2) one or more vendor selections for said product or service selection.

6. The method as in claim 1 , wherein the conveying step comprises transmitting the request to the customer-selected vendors by means selected from the group of: EDI, e-mail, fax, telephone and the host Website.

7. The method as in claim 1, wherein the response is reported to the customer through one of EDI, e-mail, fax, telephone and the host Web site.

8. The method as in claim 1, wherein the relationship-data is maintained in a data store connected to a server, and the server maintains the host Web site.

9. The method as in claim 1, wherein the host Web site maintains a catalog of information to satisfy the request.

10. The method as in claim 1 , wherein the step of conveying the request to a host- approved vendor is performed automatically.

11. The method as in claim 1 , wherein the prescribed condition is that no single one of the customer-selected vendors can fully satisfy the order.

12. The method as in claim 11 , wherein the step of conveying the request to a host-approved vendor is performed automatically.

13. The method as in claim 1, wherein the prescribed condition is that the customer-selected vendors collectively cannot fully satisfy the order.

14. The method as in claim 13, wherein the step of conveying the request to a host-approved vendor is performed automatically.

15. A method for facilitating e-commerce between a customer and a set of pre- selected vendors with whom the customer has an existing relationship, said pre-selected vendors each having an established communication format with the customer, comprising the steps of: (a) accepting over an Internet connection a request from a customer; (b) for each of said pre-selected vendors formatting said request for delivery in the established communication format of the customer with that vendor; (c) delivering in the established communication format said request to each of said pre-selected vendors; and (d) providing to the customer over the Internet a response to said request.

16. The method of claim 15, wherein said formatting step comprises for each of the pre-selected vendors, the steps of: (1) obtaining a transmission mode correlated with one of said pre- selected vendors; and (2) converting said request in accordance with said obtained transmission mode to format said request for that vendor.

17. The method of claim 16, wherein said obtaining step comprises the steps of: (A) accessing a database containing a set of transmission modes associated with each of a set of vendors; (B) identifying for each of said pre-selected vendors with whom the customer has an existing relationship an ordered set of transmission modes; and (C) selecting the transmission mode with a highest order value.

18. The method of claim 16, wherein said delivering step includes transmitting data over a connection selected from the group of: the Internet, an electronic data interface, e-mail, a facsimile machine, and a telephone.

19. The method of claim 15, including the additional step of obtaining vendor-selection data from the customer over the Internet connection, the vendor-selection data defining at least a subset of said set of vendors wherein the vendor-selection data is selected from among a multiplicity of vendors.

20. The method of claim 19, comprising the additional step of associating a part number selection with the vendor-selection data.

21. The method of claim 15 , wherein a preexisting buyer/purchaser relationship exists between said customer and said pre-selected vendors.

22. The method of claim 15, wherein said request includes a product identifier.

23. The method of claim 15, wherein said vendors sell products.

24. The method of claim 15, wherein, in the event that there are plural responses, recommending a particular one of the responses based upon predetermined criteria.

25. A method for providing a customer with responses that satisfy a request, the request and responses thereto being conveyed across a distributed computer network between at least a customer station and a host, comprising the steps of: (a) providing from the customer station a request to purchase a product or service; (b) providing from the customer station information which relates one or more customer-selected vendors with whom the customer has an existing relationship with the product or service in the request; (c) receiving from the host any responses to the request from the customer-selected vendors; and (d) receiving from the host responses to the request from one or more host-approved vendors only upon a prescribed condition.

26. The method as in claim 25, wherein the step of receiving the request from the host-approved vendors is performed automatically upon the prescribed condition being satisfied.

27. The method as in claim 25, wherein the prescribed condition is that the customer-selected vendors collectively cannot fully satisfy the request.

28. The method as in claim 25, wherein the prescribed condition is that no single one of the customer-selected vendors can fully satisfy the request.

29. The method as in claim 25, wherein the responses from the customer-selected vendors and the host-approved vendors are in the form of one of EDI, e-mail, fax, telephone and the host Web site.

0. The method as in claim 25, wherein the host-approved vendor is one of the host Web site and a third-party vendor.