Skip to main content

Full text of "USPTO Patents Application 09869538"

See other formats


WO 00/72213 


Hec'dPCT/PTO 27JUN2001 




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, 
10 entitled "Systems and Methods for Electronic Commerce," which application is 
hereby incorporated by reference as if set forth in its entirety herein. 


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

20 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 


Over the centuries, commerce has taken on many forms but none has 

WO 00/72213 PCT/USOO/14365 


5 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 

10 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 

15 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. 

20 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. 

25 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 

WO 00/72213 PCT/US00/14365 


5 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, 
eToys and Dell Computer which let buyers place orders over the web. 

The buy-side commerce model places the electronic catalog at the 

10 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 

15 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 

20 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, 
25 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 

WO 00/72213 PCT/US00/14365 


5 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, 

10 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 

15 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 

20 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 

25 the buyers and sellers. The present invention satisfies these and other needs as 
described below. 

WO 00/72213 PCT/US00/14365 



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 

10 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 

1 5 disrupted nor are they displaced because those vendors were not able to satisfy the 

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 

20 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 

25 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 

30 be advised of the identity of the host-approved vendor in the event that such a vendor 

WO 00/72213 PCT/US00/14365 


5 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 

10 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 

15 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 

20 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 

25 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 

30 a distributed computer network for providing a customer with responses that satisfy 

WO 00/72213 



5 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 

10 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 

1 5 Description. 


Fig. 1 is an illustration of a hardware arrangement that is used with the 
present invention; 

20 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 
25 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. 


WO 00/72213 PCT/US00/14365 


5 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 

10 (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 

15 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 

20 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 

25 vendors 104a, 104b, 104c, etc. (more generally, vendors 104) through an electronic 
marketplace maintained by a host server 1 06. Customers access the host 1 06 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 

WO 00/72213 


5 connections over the Internet 1 08, but can communicate with the host 1 06 using other 
hardware devices. 

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 

10 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 

1 5 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). 

20 The host 106 may further include a Web enabled purchasing system 

(WEPS) database 1 30 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. 

25 Through the hardware arrangement 1 00, customers access the host 1 06 

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 

The host includes a server 110 which is configured to implement the 

WO 00/72213 ^ PCT/US00/14365 


5 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. 

10 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 1 12 at the host 106. In a conventional manner, the vendors 

15 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 

20 particular customer 1 02 may purchase staples from vendors 1 04a 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 1 12 for vendor contact information. The host conveys 

25 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 1 02; however, in the event 
that none of the vendors can satisfy the request or in the event that only a portion of 

WO 00/72213 PCT/US00/14365 


5 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 2 1 0, it is preferably conveyed by a LAN connection 
between the host and WEPS, a WAN connection, or could be a signal transmission 

10 within the same machine. That is, WEPS 210 can be a program running on the 
server 1 10 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 

15 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 

20 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 

25 (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 

WO 00/72213 PCT/US00/14365 


5 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 

10 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 

1 5 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 

20 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 

25 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 

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 

WO 00/72213 PCT/US00/14365 


5 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 

1 0 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 

15 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 

20 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 

25 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, 

WO 00/72213 PCT/US00/14365 


5 a second index J is used (step 3 10) 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 

1 0 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 

1 5 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 

20 transfer was successful at step 324 and, if unsuccessful, repeats the loop through steps 
3 12-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 

25 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 

WO 00/72213 




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 

10 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 1 06, in accordance with a further 

1 5 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. 

identified in a particular vendor response) can be tabulated for all of the pre-selected 
20 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. 
25 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 

Alternatively, the results (i.e., the number of parts, goods, etc. 


WO 00/72213 



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 

10 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 

1 5 WEPS 2 1 0 or directly to any host-approved vendor. 

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 

20 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 

25 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 

A market failure is detected by way of a software program which 

WO 00/72213 PCT/US00/14365 


5 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. 

10 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 

1 5 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 

20 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 

25 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 

WO 00/72213 PCT/US00/14365 


5 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 

10 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 

1 5 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 

20 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 a part 
that is compatible with the desired part) is available through another forum. The use 

25 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 

WO 00/72213 




5 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 1 06 with 
the host automatically determining the appropriate format for conveying the request. 

10 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 

1 5 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 1 12 in this example 
would include a set of two transmission modes associated with that vendor and would 

20 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 1 12 to specific goods, services, or parts. By relating 
in the database particular goods, services or parts to specific vendors, the customer 

25 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 

WO 00/72213 PCT/US00/14365 


5 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 
10 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. 

15 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 

20 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 

25 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. 

WO 00/72213 PCT/US00/14365 


5 In particular, in the event that the test at step 344 fails, that is, the customer's pre- 
selected 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 1 06 outsources the 
10 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 

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 

15 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 

20 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 

25 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 

WO 00/72213 PCT/US00/14365 


5 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 

10 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 

15 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 

20 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, 

25 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). 

WO 00/72213 PCT/USO0/14365 


5 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. 

1 0 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 

15 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 

20 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. 

25 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 

WO 00/72213 PCT/US00/14365 


5 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 

10 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 

15 provided to the customers and billed directly through communications in the 
marketplace 200 (step 504b). Communications proceed back and forth between the 
customer 1 02 and the vendor 1 04 by way of the host 1 06, 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 

20 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 

25 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 1 06, 
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 

WO 00/72213 PCT/US00/14365 


5 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 

10 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 

15 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 

20 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 

25 "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 

WO 00/72213 PCT/US00/14365 


5 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 5 1 2, the account 

10 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 

15 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 

20 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 

25 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 

WO 00/72213 



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.