WO2001013300A2

WO2001013300A2 - Aggregation engine

Info

Publication number: WO2001013300A2
Application number: PCT/US2000/022022
Authority: WO
Inventors: Robert Milton Schulman; Patrick Edmund Burns
Original assignee: Demandline.Com, Inc.
Priority date: 1999-08-13
Filing date: 2000-08-10
Publication date: 2001-02-22
Also published as: AU6538100A; WO2001013300A8

Abstract

A method for conducting an on-line auction is provided. A plurality product demands for a product are received from a plurality of buyers. The plurality of product demands are aggregated into an aggregated demand. The aggregated demand is transmitted to at leastg one vendor. At least one bid price is received from the at least one vendor for the aggregated demand. A winning bid price is determined and transmitted to the plurality of buyers.

Description

AGGREGATION ENGINE

BACKGROUND OF THE INVENTION Field of the Invention

This invention relates generally to demand aggregation, and more particularly to aggregating product/service demand and pooling it into a larger aggregated block using the Internet and a competitive bidding/reverse auction.

Description of Related Art

There are dozens of different buyer-seller protocols in use today. Almost all of these protocols are seller-driven in that they focus on the methods and processes available to the seller, allowing the seller to price, package or configure goods and services more effectively. Stores, catalogs, classified advertisements, telemarketing, auction houses, even on-line computerized reservation systems are all seller-driven. Traditionally, it is the seller's job to attract buyers and then to complete the sale. Thus, in a seller-driven system, the advertising cost of the transaction and the attendant risks that such advertising will be unsuccessful falls upon the seller.

Most goods and services sold are done so using a general seller-driven protocol whereby the seller sets a price and the buyer decides whether or not to accept that price. Prices for some services, such as airline tickets, might change frequently, but the buyer must still wait for the seller to offer a price he finds acceptable. Obviously, some forms of commerce offer far more give and take with offers and counteroffers being exchanged, however the vast majority of retail purchases utilize seller-driven, fixed-price, non-negotiable pricing protocols. Auctions are probably the most frequently used system whereby prices are not fixed by the seller. Auctions are generally seller-driven. The buyer does not find the seller, rather the seller attracts numerous buyers who, as a group, determine the final selling price which the seller may subsequently reject unless the item auctioned is being sold without a reserve. Other commerce systems are exchange-driven. These systems, such as

NASDAQ or the New York Stock Exchange (NYSE) match buyers and sellers by offering an efficient, fair and orderly marketplace. They favor neither buyers nor sellers, but simply effectuate communications that allow for the matching process to take place.

A buyer-driven system is one in which buyers find sellers, such as a "wanted to buy" classified ad. A help wanted ad is a buyer-driven inquiry since the employer is looking to locate and buy the services of a qualified employee. The inquiry is advertised to a large number of potential "sellers," a number of which may respond by submitting their resumes to the prospective employer. Bilateral buyer-driven systems seek to consummate contracts between buyers and sellers based on mutual promises to perform. Bilateral buyer-driven systems, however, currently represent an extremely small portion of overall commerce due to a variety of factors. First, and perhaps foremost, buyers generally either cannot or do not want to invest the time, money or other resources required to locate an indefinite number of potential sellers and communicate the buyer's purchasing needs to each of the potential sellers. This is especially true of smaller businesses that often cannot afford to pay substantial transaction costs.

As a rule, the greater the number and complexity of the buyer's purchase conditions, the more difficult it is to have a buyer-driven market, since advertising costs generally rise with the number of conditions that must be communicated, and the potential number of sellers who can understand and fulfill increasingly complex conditions usually declines. Buyer-driven markets function best when there is a well-defined purchase need, when a "brand" provides quality assurance to the buyer such as the name of a major airline carrier or when the item is a commodity.

An example of a regularly used bilateral buyer-driven process is the system utilized by large organizations such as companies or governments which want to purchase significant amounts of goods or services at the lowest possible price. To begin, large organizations formulate a detailed written specification setting forth the quantities and requirements of what they are looking to buy.

This document is typically called a "Request for Proposal" (RFP). Once finalized, RFPs are then distributed to a list of known potential suppliers. If the value of the RFP is high enough, as it is might be with a large government contract, the buyer may bear the added expense of trying to attract the widest number of sellers by paying to publish the RFP in newspapers and trade magazines. Potential suppliers which identify an RFP evaluate it to decide whether or not to invest the necessary time and effort to submit a formal proposal. Typically, some number of suppliers submit binding proposals to the buyer by a deadline established in the RFP. Once submitted, proposals are then evaluated by the buyer. One proposal is usually selected and the corresponding supplier notified that it has "won" the business at the price quoted.

Large organizations can take advantage of the benefits afforded by the RFP process because their volume buying represents a worthwhile opportunity for suppliers to compete for their business. They also have the resources to communicate their buying needs to a sufficient number of suppliers. As a result, large organizations can often achieve substantial unit cost savings, especially on commodities and service industries where there are high fixed costs, excess capacity, multiple lots of competitors and high customer acquisition costs.

Smaller organizations cannot effectively participate in such bilateral buyer-driven systems because they generally do not have the buying power and resources of large organizations. Some small organizations have found ways to group together in order to achieve some measure of the volume buying power enjoyed by large organizations. Many smaller organizations are deterred from joining buying groups because of the groups' various requirements and limitations.

As commerce seeks to utilize the inherent advantages of the Internet, many types of commerce systems, such as malls, catalogs and auction house, are being implemented on the Internet. These approaches generally seek to create better seller or exchange-driven systems whereby the sale of goods and services is made more efficient.

Accordingly, there is a need for a centralized system of bilateral electronic commerce capable of being utilized by even smaller orgamzations to communicate their purchasing needs globally to potential sellers. There is a further need for a centralized system of bilateral electronic commerce that aggregate buyer demand. Yet a further need exists for an Internet method and apparatus that provides demand aggregation to achieve favorable pricing and service for smaller organizations.

SUMMARY OF THE INVENTION Accordingly, an object of the present invention is to provide a method and apparatus for aggregating buyer demand and pooling it into a large aggregated block. Another object of the present invention is to provide a method and apparatus for aggregating buyer demand on the Internet.

Another object of the present invention is to provide a method and apparatus for aggregating buyer demand in a reverse auction.

These and other objects of the present invention are achieved in one embodiment in a computer implemented auction system. The auction system includes at least one buyer system and a vendor system. A host system is coupled to the buyer and vendor systems. The host system includes aggregation resources to create an aggregate demand of at least two buyer demands for a product. The host system generates and transmits the aggregated demand to the vendor system and receives bids from the vendor system for the aggregated demand. The host system further includes a database of aggregated demand information.

In another embodiment of the present invention, a method is provided for conducting an on-line auction. A plurality of product demands for a product are received from a plurality of buyers. The plurality of product demands are aggregated into an aggregated demand. The aggregated demand is transmitted to at least one vendor. At least one bid price is received from the at least one vendor for the aggregated demand. A winning bid price is determined and transmitted to the plurality of buyers. In another embodiment of the present invention, a method of an on-line auction includes providing a computer implemented auction system. The auction system includes a host system, at least one buyer system coupled to the host system and at least one vendor system coupled to the host system. The host system has aggregation resources to create an aggregate demand of at least two buyer demands for a product. A plurality of product demands are received for a product from a plurality of buyers. The plurality of product demands are aggregated by the host system aggregation resources into an aggregated demand. The aggregated demand is transmitted from the host system to at least one vendor utilizing the vendor system. At least one bid price is received from a vendor for the aggregated demand and is transmitted from the vendor system to the host system. A winning bid price for the aggregated demand is determined at the host system. The winning bid price is transmitted to the plurality of buyers from the host system to the at least one buyer system.

BRIEF DESCRIPTION OF THE FIGURES Figure 1 is an overall system architecture of one embodiment of a product aggregation system of the present invention. Figure 2 is a screen display of one embodiment of a buyer registration interface.

Figure 3 is flow chart illustrating one embodiment of a buyer log in/authentication process.

Figure 4 is a screen display of one embodiment of a demand registration interface.

Figure 5 is a screen display of one embodiment of a demand registration summary interface.

Figure 6 is a flow chart illustrating one embodiment of a database structure of the present invention. Figure 7 is a flow chart illustrating one embodiment of vendor and auction information storage.

Figure 8 is a screen display of one embodiment of a bid submission interface.

Figure 9 is a screen display of another embodiment of a bid submission interface.

Figure 10 is a schematic diagram illustrating factoring the aggregated buyer demand into sub-pools. Figure 11 is a flow chart of one embodiment of aggregation and factoring buyer demand into sub-pools.

Figure 12 is a graphical representation illustrating one embodiment of total quantity of requested aggregated buyer demand and price compared to the most likely actual aggregated buyer demand.

Figure 13 is a graphical representation from Figure 12 of cumulative demand overlaid with a historical scoring graph for actual aggregated demand.

Figure 14 is a flow chart of one embodiment of a vendor log in and authentication process. Figure 15 is a flow chart of one embodiment of a verification protocol.

Figure 16 is a flow chart of one embodiment of a demand registration process used with the present invention.

Figure 17 is a flow chart of one embodiment of a vendor bidding protocol useful with the present invention. Figure 18 is a flow chart of one embodiment of an auction process of the present invention.

Figure 19 is a flow chart of one embodiment of a demand cycle flow process.

Figure 20 is a schematic diagram of one embodiment of a system architecture of the present invention.

Figure 21 is a schematic diagram of one embodiment of a system architecture of the present invention with an HTTP server and a separate application server.

Figure 22 is a schematic diagram of one embodiment of a system architecture of the present invention with clustered servers.

DETAILED DESCRIPTION The present invention provides a centralized system of bilateral electronic commerce that aggregates multiple buyer purchasing requirements in a multi-vendor reverse auction process. Buyer demand is pooled into a larger aggregated block. The aggregation provides more favorable pricing and service than available for individual buyers, and is particularly suitable for smaller businesses and organizations. Information from buyers is communicated to a host, and the host communicates with the vendors. Communications are by cables, cybercast sources, modems, a direct broadcast satellite system, telephone lines, wireless, LAN's, WAN's, fiber optic and the like. Preferably, the Internet is used. The auction used in the present invention can be of a variety of different types, having different rules, practices, or methodologies according to which bids are accepted and evaluated. For example, in some types of auctions, information is available to bidders about each other's bids during the bidding, whereas in other types of auctions, each bidder knows only its own bid. As another example, the type of auction can affect the way in which price is determined upon close of auction. Thus, in a sealed-bid second-price auction, no bidder knows the value of any bid other than its own, and the final price is set according to the second-place bidder's bid rather than according to the winner's bid. The type of auction used in the specific embodiment can be chosen according to the circumstances of the marketplace and the particular auction, taking into account considerations such as customer and supplier preferences and the nature and characteristics of the document service being auctioned. Any number of different types of auctions can be used. Some illustrative examples are sealed-bid second-price auctions, English auctions, and Dutch auctions. These and other types of auctions are well described in the literature on auctions and auction theory.

Information is collected from every buyer who wishes to participate in the aggregation and the reverse auction. This creates a demand for vendor products and services, collectively "the Product" on a larger scale than for one individual purchaser. The aggregated demand consists of a pool of buyers. Potential vendors of the Product participate in a reverse auction to provide the best price and service. The buyer is not necessarily committed to purchase from a particular vendor and can select from different vendors that offer the Product. Vendors submit bids in response to the aggregated demand and typically the lowest price wins. As illustrated in Figure 1, one embodiment of the present invention includes a product aggregation system architecture with a demand collection engine, a database, a demand viewer engine and an auction engine. A demand collection engine is coupled to a database of registered buyers, displays and web browsers. The database includes buyer registration information, demand information, transaction information, lists of vendors, vendor contacts, auction and bid data, and the like.

The demand collection engine also can supply information to the buyers on the Products, the vendors, historical ratings, surveys and feedback on the vendors from previous buyers, analysts, and 3rd party organizations, and the like. The demand collection engine can also provide information about the total demand collected so far, the savings generated so far, the demand collected during the current acquisition cycle, the estimated savings for the current cycle, and estimated prices that will likely be met in the current cycle. At a display associated with the demand collection engine a buyer with a web browser fills out a series of forms to specify relevant information regarding the desired Product. Examples of services and products include but are not limited to telecommunications, hi-speed data networking, web hosting, insurance; 40 IK, moving, auto rental, temporary staffing, printing, copying and photos, painting, electrical, finance and accounting, recruiting, travel, customer service outsourcing, sales/telemarketing outsourcing, fuel, computer equipment and services, human resources, legal consulting, real estate and construction, office management, office supplies, janitorial and waste, security and safety, lodging and convention, and food services. Examples of information that can be input by the buyer include but are not limited to a list of Products, allowed vendors, commitment prices and quantities, costs expressed as per unit price, a reserve price (a price at which the buyer is willing to purchase the product) which is optional, time periods over which the Product will be acquired as well as time periods for the vendor to complete the transaction, delivery/installation times, length of term, guaranteed uptime for web-hosting and the like, guaranteed service times, start-up costs, right of renewal, and the like. With the present invention, a buyer has a variety of options including viewing its current demand, registering a new demand for one or more Products, view its demand history to date, see what others say about selected vendors as well as voice its opinion regarding vendors. Additionally, the present invention provide an on-line and an off-line help line.

Figure 2 illustrates an interface that can be used by a buyer to register for participation in the buyer aggregation. A buyer enters its log in ID and password into a client application. As shown in Figure 3, a browser can optionally encrypt the information using SSL or other standard encryption techniques. An example of the buyer's demand registration is illustrated in

Figure 4. Figure 4 provides a specific example of registration for a long distance carrier. It will be appreciated that demand registration is not limited to long distance carriers.

As shown in Figure 5, after the buyer has completed its demand registration, the buyer can be optionally presented with an interface that summarizes the demand, provides terms and conditions of sale to the buyer, and a buyer acceptance line.

Figure 6 illustrates one embodiment of a database structure of the present invention. The database structure includes buyer information and demand registration information. Examples of buyer registration information stored in a Buyer table with capture fields includes buyer identification, company name, title, first name, middle initial, last name, phone number, fax number, E-mail address, the type of industry of the buyer, years in business, the DUNS number, the number of employees, revenue of the buyer, address, and the like.

Buyer demand registration information is stored in the Demand table. Examples of possible demand registration can include demand identification, buyer identification, auction identification, date and time of the auction, reserve price, quantity commitment, time horizon and the like. Demands for Products are stored in Demand tables. In one embodiment, there is a Demand table for each Product. In another embodiment, Demand tables can be created for multiple Products with common fields, as illustrated in Figure 6. It will be appreciated that information common to multiple Demand tables can be located in a Demand table that has fields that are common to multiple demands. Figure 7 illustrates the process whereby the vendor and auction information is stored. Vendors create and submit bids in response to the buyers demand registration, as shown in Figures 8 and 9.

The pool of buyers can be broken down to tiers or sub-pools. Each sub- pool aggregates buyers with one or more common characteristics, which allow the vendor to provide the appropriate Product desired by the sub-pool of buyers. Separation into sub-pools leads to distinct auctions from the vendor perspective, where each auction has a different price and demand pool. A different sub-pool might be served by different sets of vendors.

An example is a sub-pool for buyers with 100K or greater demand, another for 76-100K, another for 51-75K, and the like. This can yield tiered pricing based on the size of the organization. However, even with sub-pooling a small buyer in a sub-pool still gets a better price than if it were negotiating as a single entity on its own.

The sub-pool criteria includes but is not limited to intended start date, committed quantity /amount, industry or type of company the buyer represents, required service levels, bandwidth needs, startup costs, length of term, number of employees, number of offices/sites/buildings, proximity to vendor infrastructure such as branch office or service facility, quantity of service per employee, credit rating and the like. The sub-pool criteria might be driven by the need to achieve a minimal pool size or to maintain parity across pools. For example, if there is a total of 3MM total demand, the pool might be broken down into 3 sub-pools of 1MM each. Another example of sub-pool criteria might be driven by attributes collected during sign up process, such as geography, industry type, company size, vendor preference, length of contract desired and actual portfolio of services desired.

Factoring of demand into sub-pools is illustrated in Figures 10 and 11. A demand viewer engine is also coupled to the database. The demand viewer engine is used by the vendors to learn of the aggregated demands and to make their bids for the Products. The vendors do not have the ability to modify the demand portion of the database. During each auction, each vendor will have access to the aggregate demand information for the associated demand pool. In this embodiment, the vendor can view aggregate quantity, grouped by reserve price. The aggregate information includes only the demand for that vendor.

For example, if X-axis is the reserve price, Y-axis is demand quantity at that price. Both incremental and cumulative demand can be shown as in Figures 12 and 13. Optionally, the aggregated demand reserve price data can be hidden from the vendor, to force a "blind" bidding on the vendors. In this embodiment, it is anticipated that vendors will bid competitively to meet the reserve price, and thereby fulfill as much demand as possible. The amount of information available to the vendors is dynamically driven based on the nature of the vendors and Products.

Vendor authentication may be required with a user name and password for authentication purposes. Other means of authentication include, but are not limited to the following: network address of the vendor (e.g., IP address), digitally signing a bid with a digital certificate (an X 509 or other standard format) that verifies the identity of the bidder, or other standard means of authentication. Optionally, each bid may be authenticated by confirming by E-mail, fax, phone, in person or other means, as shown in Figure 14.

In various embodiments, the demand viewer can provide a variety of different information including, a mean/median demand per buyer which can displayed in a variety of forms such as a graph, last year/quarterly/monthly demands, geography breakdowns, credit quality, company size, age, revenues, number of employees, industry classifications and listing of current vendors, rating of buyer based on previous usage of demand aggregation service, reserve price, current price paid for Product, and the like. Further a target price can be entered and aggregated demand can be segmented by a maximum price entered. The demand viewer can project for the vendor the marginal business that will be achieved by bidding at a given price, accounting for the lower overall unit price and the incremental demand resulting from the lower price. In one embodiment, each vendor sees a customized view of the aggregated demand that reflects the vendor preferences expressed by the buyers. For example if IMM of demand is registered, suppose 100% are willing to deal with Vendor A, but only 10% are willing to deal with Vendor B. Vendor A would see IMM of demand, but Vendor B would only see 100K. Vendors A and B could be provided with aggregate information about the buyers' vendor preferences. In this instance Vendor B could find out from the database that only 10% of the total pool is willing to consider them.

The demand view engine can also show vendors the percentage breakdown of the aggregated demand of the vendor and its competitors. This provides vendors with an incentive to be competitive in order to keep their customers or to increase their market share. The demand view engine can also show authenticated vendors subsets of the available information about the registered demand. These subsets can provide the authenticated vendors an indication of incremental business to be won by placing a bid that beats the current leading bid.

An auction engine is provided and enables vendors to submit pricing based on requested Product volume. Vendor bids are entered, as in Figures 8 and 9, and processed in the order of receipt. Optionally, before processing of a bid, the bid can be verified as shown in Figure 15.

In one embodiment, the identity of the leading vendor is not disclosed to other vendors, only the lowest bid amount. The auction engine provides an open or closed time period of collecting demand, bidding, revelation of leading pricing for authenticated vendors and then ends. The auction can either end at a fixed time, published to the vendors before the auction begins or can end when no bids have been received within a specified time interval, e.g., 15 minutes or after a minimum number of bids have been placed, a minimum quantity of demand has been met, and the like. Vendors can view the current leading bid on-line, watch as bids change and can ask a question to the auction manager. Vendor names can be hidden from other bidders. In another embodiment, the bids might be sealed. When the auction closes a pool of buyers that form the aggregated demand is released to the winning vendor. It is then the responsibility of the winning vendor to complete the necessary arrangements and contracts with the pool of buyers. In this embodiment, aggregation is separated from the actual individual transaction. The aggregated demand information can be released in many formats to the winning vendor, including by not limited to, a text file sent over a network or on a physical media, an XML document, a database, a spreadsheet, a fax or printout.

Many different XML forms can be used. One example of such an XML document is as follows:

File 1: XML sample of matched buyer info for transmission to winning vendor

<?xml version = '1.0'?> <Auction id = "A0001"> <! — Auction characteristics -->

<Date> 10/l/99</Date> <WinningVendor id="V0001 ">Acme Co oration<AVinningVendor>

<Service>Long Distance</Service> <WinningPrice units = "USD">.064<AVinningPrice>

<! — Sub-pool characteristics --> <MinimumMonthlyCommit units = "USD"> 1000</MinimumMonthlyCommit>

<Buyer>

<Name>Aaa Widgets</Name> <Industry>Manufacturing</Industry> </Company>

<Name>

<First>Joe</First> <MI>K/MI> <Last>Smith</Last

</Name> <Phone>

<Area>805</Area> <Number>4321100</Number> <Extension>10K/Extension>

</Phone> <Fax>

<Area>805</Area> <Number>4321087</Number> </Fax> <Email>joes@aaawidgets.com</Email>

</Contact> <Demand>

</Demand> <Credit>

<Buyer>

<Name>California Dreams </Name> <Industry>Consulting</Industry> </Company>

<Name>

<First>Amanda< First> <MI>L</MI> <Last>Jones</Last>

</Name>

<Title>President</Title> <Phone>

</Phone> <Fax>

<Area>415</Area> <Number>279550K/Number> </Fax>

<Email>ajones@caldream.com</Email> </Contact> <Demand>

<Register Date>09/29/99</RegisterDate> <MonthlyCommit units =

"USD">2500</MonthlyCommit> </Demand> <Credit>

</Buyer> </Auction> Optionally, the demand information can be directly written to a vendor database.

A flow chart of the demand registration process is shown in Figure 16. A buyer selects one or more available Products. Optionally, the buyer can provide prior Product use information. Vendors are then selected and may be ranked. The buyers can view other buyer comments/ratings of the vendors. The buyer then specifies its demand, the optional reserve or limit price and can also provide credit or other qualifying information. This is then submitted to the demand collection engine which then sends a confirmation, preferably electronically, on-screen, by e-mail, pager, fax, telephone, TV, radio CB radio, cell phone, and the like.

In one embodiment, qualifying information is provided and factored by the demand viewer. This information includes total revenue, number of employees, revenue per employee, years in business, credit card information, tax identification number. DUNS number, history of using the demand aggregation service, industry, type of corporate entity, number of sites, location, current usage, current vendor, difference between current usage and projected usage and the like. The vendors use some or all of the qualifying information, in real time, to do their calculations and provide a pricing. Optionally, a sampling of the buyer pool is done in order to assess credit. This can be achieved with a small sampling in order to create a credit index for the vendors. Vendors can then utilize credit-worthiness in determining their pricing. Lower pricing would be expected for buyer pools with solid credit ratings. The credit ratings are determined by a variety of standard methods. Vendors can be given enough information to enable them to calculate, using their own heuristics, to predict the actual demand that they'll get. This enables vendors to rate the quality of a lead from the demand aggregation service using the information provided.

In one embodiment, vendors are provided with registration information and factoring from previous auction cycles. Vendors are provided with aggregate information on close rates for buyers according to various criteria, including but not limited to total revenue, number of employees, revenue per employee, years in business, credit card information, tax identification number, DUNS number, history of using the demand aggregation service, industry, type of corporate entity, number of sites, location, current usage, current vendor, difference between current usage and projected usage, reserve price, difference between reserve price and current price, commit quantity/amount, and the like.

As illustrated in Figure 17, a vendor enters a log in ID and a password from a client application, typically a web browser. The browser encrypts information using SSL or other standard encryption techniques.

Registered demand does not always result in 100% consummation of the purchase. There may be a fall off for a variety of reasons. The fall off can be mitigated by requiring buyers to submit an initial deposit during some point of the reverse auction process.

An example of aggregate buyer data, for a reverse auction, broken down by state and reserve price is as follows (as expressed in an XML format): XML File containing aggregrate buyer data

<?xml version = '1.0'?>

<! — Auction characteristics — > <Service>Long Distance - Interstate</Service> <Date> 10/l/99</Date>

<! — Sub-pool characteristics --> <MinimumMonthlyCommit units= "USD">1000</MinimumMonthlyCommit>

<! — Example 1 : group by reserve price in increments of .005 -->

<! — Describe group, list results — > <Buyer Result>

<! — Define group — > <Attribute>

<Name>ReservePrice</Name> <Type>Number</Type> <Increment>.005 </Increment>

</Attribute>

<! — Aggregate Data --> <BuyerGroup>

</ReservePrice>

</ReservePrice> </Characteristics>

</BuyerGroup> <! — And so forth... -->

</BuyerResult>

<! — Example 2: group by state -->

<! — Describe group, list results — >

<! — Define group --> <Attribute>

<Name> State</Name> <Type> String</Type>

</Attribute>

<! — Aggregate Data — > <BuyerGroup>

<State>

<! — And so forth... — >

</BuyerResult> </BuyerAggregation>

Representation of same data in report format

.065 - .069 .070 - .074 Lost 155 15

Closed 364 210

Invalid 12 8

CA CO

Lost 35 5

Closed 846 43

Invalid 25 2

In various embodiments, vendors then view the total demand as well as current prices and bid increments and then begins to bid based on a total pool aggregation or of a sub-pool. For a given auction, the vendor is allowed to view a subset of the demand information in a graphical format, illustrated in Figures 12 and 13, to provide insight into the quantity of business that is likely to be won from a given bid. In Figure 12, the solid line shows the total registered demand while the dotted line represents a likely yield of actual demand from historical data. The vendor submits bids on-line or off-line. Pre-set vendor bids are also accepted, that is, a vendor can submit a limit price that will automatically generate bids that beat the leading price from other vendors until the limit price is reached. Vendors receive daily updates, via e-mail, telephone, fax, pager, or other means. Bids are placed in a queue and processed in order of receipt. Price is one of the parameters of a bid. Price need not be the only factor in determining the winning bid. Other parameters, including but limited to service, delivery schedules, availability, payment terms, and the like can be the factor in winning the bid. When price is the primary parameter in selecting the winning bid, the auction engine can send out regular status reports to vendors, rejections if bids are too high or incomplete and confirmations when the bid is the lowest. During and after the auction, the name of the leading vendor is not disclosed to the other vendors. Additionally, vendors can pool together and aggregate their Products to provide lower pricing. In this manner, smaller vendors can create an aggregation of supply to pool together and more effectively compete with larger vendors.

A flow chart of one embodiment of auction process is illustrated in Figure 18. Bids are received and a query made to determine if the auction is still open. The lowest bids are located from the auction bid database, the winning vendor is notified and a delivery order is forwarded to the winning vendor. Those matched buyers in the pool for that auction with compatible requirements are then notified. In one embodiment, a buyer is compatible if the optional reserve price was met, the vendor is on the approved list of the buyer, the vendor provides the Product specified by the buyer, and so forth. In this manner every qualified buyer from the aggregated pool is guaranteed to get the same price from the winning price or vendor irrespective of stated reserve prices. This matching process gives the buyer incentive to submit reasonable requirements, as those that do not match are excluded from the notification list.

Unsuccessful vendors are also notified but are not advised of the winning price or vendor. Only the host of the auction has access to the individual demand information and the vendor bids.

The host continues to accept bids until an ending criterion for the auction is met. For example, the auction can end after a certain time interval has elapsed or when a certain maximum number of bids has been received, whichever comes first, or when no further bids are received for some elapsed time interval or upon satisfaction of any other appropriate ending criterion or criteria. Bidding then closes. When all bids are in the host determines which vendor has won. If at least one bid is at or below an optional reserve price, or if no reserve price is specified, the host selects a winning bid or a set of one or more potential winning bids. The host makes this selection automatically based on one or more criteria that define what makes a winning bid. Typically, the winning bid is the bid indicating the lowest price. In some auctions, however, criteria other than or in addition to low price can be used as a basis for selecting a winning bid. Moreover, the final selection of the winner can be left to a buyer process, which automatically or with human input selects one from a set of potential winning bids provided by the host. Additionally, there can be multiple auctions at once and many auctions in rapid succession. Different auctions can overlap in time.

Figure 19 provides a summary that illustrates one embodiment of an entire cycle of the buyer aggregation reverse auction of the present invention. An example of an entire cycle is as follows: Flow of Entire Cycle Demand Acquisition

Store info from Form 1 into Buyer table in database OR authenticate

Buyer Log in (see Fig. 3)

Collect info from Form 2 (see Fig. 4)

Present Form 2A. (see Fig. 5) IF user accepts values, Store info from Form 2 into Demand,

Product_Demand, ProductVendorPrefs tables in DB

2. Determine sub-pool criteria 3. Create Auctions

4. Break into Sub-pools

5. Conduct auction(s)

For each participating vendor, perform Vendor Log in Authentication (see Fig. 8, collect bids using Form 3)

Store in Bid, Bid_Product tables

6. Close auction(s)

Add AuctionEvent record(s), update Auction.WinningBidID

7. Transmit matched buyer information to winner Send buyer info for all demands that are in corresponding auction sub- pool, as long as buyer expressed willingness to deal with winning vendor, update Demand.DemandMet

8. Notify each buyer of winning vendor, price/terms, by email, fax, telephone, pager, mail, etc.

9. Close transaction:

9a) vendor closes directly with each buyer offline OR 9b) contract is completed online and forwarded to both buyer and vendor via email, fax, mail, etc. and update demand info in database (Demand. CloseDate, Demand.LostDate)

File 2: Vendor Result File (XML format)

The following is sent by the vendor with resulting buyer contract information. This data is used for scoring future demand pools. <?xml version = '1.0'?> <AuctionResult id = "A0001"> <! — List of matched buyers -->

<Starus> Closed</Status> <CloseDate> 10/2/99</CloseDate> < Buyer> <Buyer id = "B0011"> <Status>Lost</Status> <LostDate> 10/l/99</LostDate> </Buyer> </AuctionResult

10. (if closed by vendor using method 9a) Receive closure data from winning vendor (see File 2)

Update demand info (Demand.CloseDate, Demand.LostDate) as appropriate

Figures 20 through 22 illustrate various embodiments of system architectures useful with the present invention. In Figure 20, a web browser communicates over a network, including but not limited to the Internet, with a web server with application extensions using a standard protocol such as HTTP and is optionally encrypted using SSL and the like. At least one web server computer can be designed to serve a host of computer browsers. The browsers have the capability to participate in various auctions. Each auction can be of a single Product, at a specified time with a specified amount of available Product. However, multiple Products with other determining parameters can also be auctioned. The web server cooperates with a separate database computer and separated from the web server computer by a firewall. The database computer is accessible to the web computer server computer to allow selective retrieval of information.

In the embodiment of Figure 21, the application server is separated from the web server, behind a firewall, for improved security and performance. In Figure 22, load balancing components have been added between the web and application servers for scalability and fault tolerance purposes.

The foregoing description of a preferred embodiment of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Obviously, many modifications and variations will be apparent to practitioners skilled in this art.

Claims

CLAIMS What is claimed is:

1. A computer implemented auction system, comprising: at least one buyer system; at least one vendor system; and a host system coupled to the at least one buyer and vendor systems, the host system including aggregation resources to create an aggregate demand of at least two buyer demands for a product, the host system generating and transmitting the aggregated demand to the vendor system and receive bids from the vendor system for the aggregated demand, the host system further including a database of aggregated demand information.

2. The auction system of claim 1 , wherein the host system includes a demand collection engine.

3. The auction system of claim 2, wherein the host system includes a demand viewer engine.

4. The auction system of claim 3, wherein the host system includes an auction engine.

5. The auction system of claim 1 , wherein the database includes individual buyer information.

6. The auction system of claim 5, wherein the database includes individual vendor information.

7. The auction system of claim 1 , wherein the host system includes a first communication system coupled to the buyer system to receive and transmit messages to the buyer system, and a second communication system coupled to the vendor system to receive and transmit messages to the vendor system.

8. The auction system of claim 7, wherein the buyer system includes an interface for transmitting and receiving messages to and from the . host system, and the vendor system includes an interface for transmitting and receiving messages to and from the host system.

9. The auction system of claim 1 , wherein the host system includes a decision making resource to determine if an auction should continue or not.

10. The auction system of claim 9, wherein the decision making resource determines a lowest vendor bid for the aggregated demand.

11. The auction system of claim 1 , wherein the host system further includes a buyer sub-pooling resource that divides the aggregated demand into at least two sub-pools of buyer demand.

12. The auction system of claim 1 , wherein the product is a physical product.

13. The auction system of claim 1, wherein the product is a service.

14. The auction system of claim 1, wherein each of the buyer, host and vendor systems are coupled to the Internet.

15. A method of auction on-line, comprising: receiving a plurality product demands for at least one product from a plurality of buyers; aggregating the plurality of product demands into an aggregated demand; transmitting the aggregated demand to at least one vendor; receiving at least one bid from the at least one vendor for the aggregated demand; determining a winning bid; transmitting information regarding the winning bid to the plurality of buyers.

16. The method of claim 15, further comprising: transmitting the winning bid to a winning vendor.

17. The method of claim 15 , further comprising : registering buyers in a host system database from a list of the plurality of buyers.

18. The method of claim 15, further comprising: registering buyer identification information in the host system database.

19. The method of claim 15, further comprising: registering buyer financial information in the host system database.

20. The method of claim 15, further comprising: transmitting to each buyer a summarization of the buyer's demand.

21. The method of claim 20, further comprising: transmitting to each buyer a list of terms and conditions of sale.

22. The method of claim 21 , further comprising: transmitting to each buyer an acceptance of terms and conditions of sale.

23. The method of claim 15, further comprising: registering vendors in a host system database from a list of a plurality of vendors.

24. The method of claim 15, further comprising: registering vendor identification information in the host system database.

25. The method of claim 24, further comprising: registering vendor financial information in the host system database.

26. The method of claim 15, further comprising: registering a vendor's selected authentication preference in the host system database.

27. The method of claim 26 further comprising: using the vendor's selected authentication preference to provide an authentication of a vendor.

28. A method of an on-line auction, comprising: providing a computer implemented auction system that includes a host system, at least one buyer system coupled to the host system and at least one vendor system coupled to the host system, the host system including aggregation resources that create an aggregate demand of at least two buyer demands for a product; receiving a plurality of product demands for at least one product from a plurality of buyers; aggregating the plurality of product demands with the host system aggregation resources into an aggregated demand; transmitting the aggregated demand from the host system to at least one vendor that utilizes the vendor system; receiving at least one bid from a vendor for the aggregated demand that is transmitted from the vendor system to the host system; determining a winning bid for the aggregated demand at the host system; transmitting information regarding the winning bid to the plurality of buyers from the host system to the at least one buyer system.

29. The method of claim 28, further comprising: transmitting the winning bid price to a winning vendor.

30. The method of claim 28, further comprising: registering buyers in a host system database from a list of the plurality of buyers.

31. The method of claim 28, further comprising: registering buyer identification information in the host system database.

32. The method of claim 28, further comprising: registering buyer financial information in the host system database.

33. The method of claim 28, further comprising: transmitting to each buyer a summarization of the buyer's demand.

34. The method of claim 33, further comprising: transmitting to each buyer a list of terms and conditions of sale.

35. The method of claim 34, further comprising: transmitting to each buyer a buyer acceptance of the list of terms and conditions of sale.

36. The method of claim 28, further comprising: registering vendors in a host system database from a list of a plurality of vendors.

37. The method of claim 28, further comprising: registering vendor identification information in the host system database.

38. The method of claim 37, further comprising: registering vendor financial information in the host system database.