WO2001073665A1

WO2001073665A1 - Method and device for providing continuous auctions over a communications network

Info

Publication number: WO2001073665A1
Application number: PCT/US2001/009888
Authority: WO
Inventors: Casimir Wierzynski
Original assignee: Marketboy Inc.
Priority date: 2000-03-29
Filing date: 2001-03-28
Publication date: 2001-10-04
Also published as: AU2001249536A1

Abstract

A method for non-anonymous auctioning of non-financial goods includes receiving offers at a server from plural potential sellers. Offer data includes offeror identification, goods identification and quantity and sales price. Bid data includes bidder identification, goods and quantity, and bid price. For at least one particular good, an auction feed is formed from offer and bid data and the feed is presented over a communications network. A related price feed and device are provided.

Description

METHOD AND DENICE FOR PROVIDING CONTINUOUS AUCTIONS ONER A

COMMUNICATIONS NETWORK

BACKGROUND OF THE INVENTION

1. Field ofthe Invention

The present invention relates to a method and device for providing auctions over a communications network, for example the Internet. 2. Background Information

Continuous two-way auctions are known, for example, in the financial field. The NASDAQ, for example, provides traders with a screen showing offers and bids on various publicly-traded securities. A trader selling securities may accept a bid, normally the highest bid available. A trader buying securities may accept an offer, typically at the lowest available price.

Continuous auctions differ from traditional Internet auction sites, such as e- bay (www.ebay.com), which provide a fixed time period for the auction, at which time the auction closes and a highest price is accepted if a reserve is met.

U.S. Patent No. 5,905,974 discloses an auction system similar to the NASDAQ and having a highly-structured trading protocol to determine which trader may buy or sell traded products, particularly financial instruments. The patent also provides a customized keyboard for aiding in trading financial instruments. This system has the disadvantage that it requires complicated software and large data streams to implement. Moreover, the use of this system for products other than financial products, such as in the business-to-business and consumer markets is limited and disadvantageous. The settlement mechanisms for financial products also can be very complicated, and may not be applicable to non-financial markets.

Comparison shopping mechanisms are also available on the Internet. These mechanisms search out a variety of prices for a good on the Internet, for example by using a search engine. The prices for the good can then be listed, for example with the lowest price first. Comparison shopping mechanisms often miss sellers ofthe goods and require that large amounts of data be searched to obtain the price information. They also require a two-step search process whereby shoppers must first find web pages that include the value ofthe desired good, then search through the page to find the price ofthe good.

SUMMARY OF THE INVENTION

An object ofthe present invention is to provide a device for two-way continuous auctions for use in business-to-business or consumer fields over a communications network. Another alternate or additional object is to provide buyers and sellers with a method of purchasing non-financial goods through continuous two- way auctions. Another alternate or additional objective ofthe present invention is to provide for non-anonymous two-way continuous auctions. Yet another alternate or additional objective is to provide for a price ticker for non-financial goods.

The present invention provides a method for non-anonymous auctioning of non-financial goods by a plurality of users of an auction system, the users including potential sellers and buyers, the method comprising the steps of: receiving offer data from at least one potential seller, the offer data including a respective user identification, a respective good identification, and a sales price; receiving bid data from at least one potential buyer, the bid data including a respective user identification, a respective good identification, and a bid price; forming an auction price feed for at least one particular good as a function of the offer and bid data so as to form a plurality of offers and bids for the particular good, the price feed including the user identifications, and the sales and bid prices for the particular good; and providing the auction price feed over a communications network. A non-anonymous two-way continuous auction can thus be provided, so that buyers and sellers advantageously can be provided with the actual identity ofthe companies or persons actually buying and selling the non-financial goods.

Preferably, the bid and offer data also include a quantity ofthe good to be bought or sold. Preferably the bid and offer data are received at a server of an auction service provider. The auction price feeds for individual goods advantageously may be broadcast over the communications network, which may be for example a LAN, WAN, the Internet, or a wireless network, or a combination of such networks.

The method may further include receiving an acceptance from an actual buyer, the acceptance corresponding to one ofthe plurality of offers. The actual buyer preferably accepts one ofthe offers by using a graphical interface which permits the buyer to point with a computer mouse and click on the offer.

The method also preferably includes registering the users through a central auction service provider. Thus user payment information can be centrally stored and the trading patterns of the registered users can be monitored. Quality control can thus also be ensured, so that users with poor credit or poor delivery history, for example, can be removed.

Preferably, a customized browser, called a "market" browser, may be used by users to tune into the various price feeds, for example by entering an identification for the particular good. The market browser may be for example, a plug-in to a standard browser, for example those available from MICROSOFT or NETSCAPE. Alternatively, the market browser could be a JAVA-applet or other software which runs on a standard browser. The price feeds thus may appear as a continuous stream of data on a display of, for example, a personal computer of a potential buyer. Preferably, the identifications ofthe users are displayed directly alongside the bid or offer ofthe user.

The price data, i.e. the offer and bid data, preferably include time-to-live data (i.e., how long a bid or offer is to remain current), delivery time data, delivery cost data and other information, such as new/used status of a good and location information ofthe buyer/seller, e.g. zip code. This additional data is highly advantageous for consumer and business-to-business markets.

The offer or bid prices for a particular good advantageously may be in a vectored format, so that for example, the price for a particular good includes 50 different prices which correspond to prices the potential seller wishes to offer in each U.S. state. A potential buyer, whose general information may be stored in a database of an auction service provider, can then be provided a price feed as a function of his or her residence or location as identified in the general information in the database. Other price data may also be vectored, such as delivery time data and delivery cost data.

This vectoring, also called multiplexing, is highly advantageous in that potential buyers may be differentiated based on various characteristics.

As with the offers which actual buyers can accept, actual sellers can accept bids from the potential buyers, preferably by clicking on a bid.

The market browser or standard browser may provide a side-by-side display of offer and bid streams. Preferably, the best bid (highest price) and the best offer (lowest price) are arranged at the top ofthe display, with the most recent completed transaction also being shown.

The present invention can also provide a bid/offer ticker for different non- financial goods with the user identification included, so that streams of different goods with the respective bid and offer prices along with the user identification are shown. This ticker can run for example at a side or bottom of a computer screen, or be embedded via a hyperlink on web pages or in an e-mail, so that clicking on the hyperlick makes the ticker visible. Clicking on the ticker can pull up the market browser, preferably for the good clicked on the ticker.

The ticker advantageously provides a visible manifestation of a price feed for at least one particular good, and preferably more. Various tickers may be organized by product groups, for example electronics, toiletries, etc.

Preferably, the browser first queries the user for a particular good. Most advantageously, the query may be a function ofthe universal product code (UPC). The searching and identification of goods for auction on traditional auction web sites such as E-BAY have often been confusing. The present search method aids in choosing a standardized basis for consumer or business good auctions. A cut-and- paste or drag function can also be provided to allow users to drag or cut the name of the product viewed, for example, when surfing the Internet and place the name in the search box ofthe market browser query page. Advantageously, users can "subscribe" to certain auction price feeds by paying an auction service provider. A relational database can be used to identify the subscriptions to particular goods for each user, and permit users only to view those price feeds.

A bid or offer preferably is accepted by a simple mouse click on a particular bid or offer shown on the browser. Preferably, the present invention also provides for potential sellers to be able to block certain potential buyers. Thus the offer data can include denial data identifying certain users, so that these users never can accept and/or view that particular offer. The denial data also could block certain regions ofthe country, for example potential buyers with a 10021 area code. The bid data could also include denial data to block potential sellers from accepting the bid. For example, a potential buyer posting bid data may wish to exclude a certain company from being able to accept the bid because of a previous poor experience with that company. Thus the bid data could include denial data for that company, for example, by providing the company name or identification number. The user identifications for both buyers and sellers registered with the auction service provider can be made available, for example on a password protected website.

Settlement of trades preferably occurs through a separate settlement server of the auction service provider, and most preferably occurs through credit card settlement. Credit card information of buyers preferably is stored on or accessible to the settlement server, which can verify the credit information. The settlement server also may send confirmations to both the buyer and the seller.

Preferably, the method includes a step whereby the actual buyer and/or the actual seller pays a percentage ofthe sales price to the auction service provider, either upon settlement or within a specified date thereafter.

Preferably credit card information of a potential buyer is submitted along with a bid.

Historical data for each buyer and seller and good can be stored, so that the purchasing trends for each can be used. This data may then be provided or used to alter the bidding and offer process .

All identifications discussed above may be alphanumeric character strings, and may relate to more detailed information in a relational database, for example one commercially-available from ORACLE or MICROSOFT. For example, a buyer identification may be password-protected code entered by a new subscriber, and may relate to name, credit card and address information. A seller identification may include an assigned service number which relates to the name and address ofthe seller, for example. Most preferably, the seller name is provided in the price feed, so that buyers may identify the seller. The attachment ofthe seller name to the price feed is highly advantageous in the consumer and business-to-business markets, where the brand name ofthe seller, for example COSTCO or WAL-MART, maybe the deciding factor for a potential buyer.

Preferably, the price feed display is customizable, for example, price information may be categorized by best price, but also by possible delivery date, delivery cost, or seller location, for example.

The present invention also provides a price ticker for transmission over a communications network, the price ticker including a good identification for a particular non-financial good and data related to a plurality of offers and bids for the particular non-financial good, the data including a user identification, a quantity offered, an offer or bid price, and delivery data.

The delivery data may include delivery costs and/or delivery time, for example.

The present invention also provides a system for providing continuous auctions for a plurality of non-financial goods comprising: a price server for receiving price data and broadcasting price feeds for the plurality of non-financial goods so as to provide a continuous stream of offers and bids to a browser; and a settlement server for settling accepted offers.

The settlement server preferably includes credit card information.

"Browser" as defined herein is software for displaying or outputting packet- based data (such as TCP/IP data) as a visual, audio or sensory output, and can include software for computers, personal digital assistants, internet access devices, mobile phones, and television sets. "Internet" as defined herein is a global server-based communications network for transmitting packet-based data.

BRIEF DESCRIPTION OF THE DRAWINGS The present invention will be better understood with reference to the following drawings, in which:

Fig. 1 shows a schematic overview ofthe system ofthe present invention; Fig. 2 shows a page for entering a product code for a registered user using the system ofthe present invention; Fig. 3 shows the page of Fig. 2 with an entered product code for a specific good;

Fig. 4 shows a search page accessible by the page of Fig. 2; Fig. 5 shows a results page returned by a word search on the search page of Fig. 4; Fig. 6 shows a market detail page for the specific good entered into the page of

Fig. 3;

Fig. 7 shows a join buyer or bid data entry page;

Fig. 8 shows a market detail page with the buyer data from Fig. 7 entered; Fig. 9 shows a buy page for a buyer who has accepted an offer from the page shown in Fig. 6;

Fig. 10 shows a join seller or offer data entry page; Fig. 11 shows a price vectoring data entry page; and Fig. 12 shows an embodiment of a price ticker according to the present invention.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

The present invention will be described in more detail with respect to an auction for a single UPC-coded good. It should be understood that certain aspects of the invention may also be applicable selling other goods, especially in the consumer and business-to-business fields.

Fig. 1 shows a plurality of potential sellers 10, 20, 30, who may have catalogs A, B, C respectively for certain goods. For example, each potential seller is an electronics store and offers various electronics products for sale in their catalogs, for example a variety of handheld organizers. Each catalog A, B, C, which lists a variety of goods and prices for each good, may be represented as digital data by a UPC or other specific code for a specific product (e.g. PALM V connected organizer), and price for that specific product. For example, a store may have the following three products, a PALM HI connected organizer for sale for $329.00, a PALM V connected organizer for sale for $359.00 and a PALM Vx connected organizer for sale for $ 450.00. The catalog of he seller could then be represented in a relational database for products and prices in a table as data sets (1647374643, 329.00), (1647384789,

359.00), (1672228318, 450.00), which correspond to a product code and the price. The catalog information preferably is stored in a database at each potential seller 10, 20, 30. The database may include entries as well as information on the store's shipping prices, average delivery time, and quantity available. This information may also be vectored, so that, for example, the price and shipping price includes 50 prices, one for each state in the U.S.

Thus the database entry for the PALM II product may appear as (1647374643, 329.00, 7, 8, 389), with 7 being a code for a standard shipping price which can correspond to a general weight ofthe product, 8 a code for a standard shipping time, and 389 being the number of items available for sale. A shipping database table may include code, price data such as (1, .39), (2, .75), (3, .89), (4, .99), (5, 1.35), (6, 4.34), 7, 8.99), (8, 9.99), etc., so that the shipping price for the good would be $8.99. A shipping time database table may include the entry (8, 12) so that it takes an average of 12 days for the good to arrive. In an advantageous embodiment, all ofthe data for the seller for a specific good can be vectored, for example by state, area code or zip code. For example, (1647374643, 329.00, 7, 8, 389) could have price vectored information in a three dimensional database table so to appear as: (1647374643, 329.00, 7, 8, 389) 339.00, 7, 5

312.00, 4, 5 389.00, 3, 5 399.00, 4, 4 etc. ... A further database table would include for example (1, 703), (2, 202), etc., so that each of single entries ofthe vectored price entries depending on the order would correspond to an area code, with the price for the 703 area code being $329.00 and the price for the 202 area code being $339.00. Shipping prices and average times could be vectored in a similar manner. Alternately, the vectoring can occur by a providing a separate relational database table, for example for a differential price vector for each product. For example, this table could have the codes (1647374643, 0, -3.22, -3.45,

2.23, 0, 0, ...[other entries for other area codes]), (1647384789, 0, 2.44, 0 ...), etc. The price provided to a customer would then be a price taken by the price database for a certain product, for example $359.00 for product numberl647384789, added by the vector entry for the customers area code (or other information). Thus a customer in the 703 area code could receive an offer price of 359.00+0= $359.00 while a customer in the 202 area code would view an offer price of 359.00+2.44= $361.44.

The databases used to store the information can be for example relational database software commercially available from the MICROSOFT CORPORATION or from ORACLE, or could be an object-oriented database. Interaction ofthe relational database tables can be provided by SQL-based queries, for example.

Each potential seller 10, 20, 30 is connected via secure communications lines 11, 21, 31 to a price server 40 of an auction service provider. Secure communications lines 11, 21, 31 can for example be provided over the Internet through an ISP. The communications may be encoded using, for example, public key-based encryption. The catalog data, as well as a user identification number associated with the seller 10,

20 or 30, can be sent to or retrieved by the settlement server in a predetermined data format. Preferably, the sellers 10, 20, 30 broadcast their information over the Internet to the price server 40 whenever price information changes. The price server 40 is accessible, for example through an ISP, to customers or potential buyers 50, 60, 70. The sellers 10, 20, 30 and buyers 50, 60, 70 are registered users of a central auction service provided by a central auction service provider. The central auction service provider can provide the price server 40, a settlement server 6 and also provide for a credit card clearing device 5.

A pre-defined data structure for the offers and bid can be sent over the secure communications lines 11, 21, 31. This predefined data structure maybe understood as being data words of predetermined length. For example, 10 bits may be assigned to a user identification, 20 bits may be assigned to the good (which can be for example a UPC code), 4 bits to a quantity, 5 bits to the offer (a price), and one bit for whether the potential trade is an offer or a bid. The data structures also advantageously may be different for bids and offers. The formation ofthe data structure will be discussed with reference to Fig. 7 in more detail.

Fig. 2 shows a query page 104 which can be accessed once a user has entered an identification and a password. Query page 104 preferably is generated by a browser, for example the market browser which preferably is a plug-in software application for a personal computer. However, this page also could be shown on a standard browser, such as INTERNET EXPLORER commercially available from the

MICROSOFT CORPORATION. The page can be generated using standard HTML- based code or JAVA-based software, for example. The user is identified here at location 105 as Customerl. This identification is based on the user identification entered by the user to access the query page 104. The user can enter a product code in data entry area 106. The product code can be a UPC number for example, or may be a product code specifically assigned by the auction service provider. The product code for a particular product often will not be known by the user, who thus can choose to click on a search product code button 107 to obtain a search page 207 shown in Fig. 4. Search page 207 can have predefined product or category tables 208, 209, as well as a word search data entry area 210. The word search could also be performed by a user who is surfing the Internet and decides to highlight or drag a product name, so that the product name appears in the search data entry area 210.

Fig. 5 shows a word search results page 307 based on the term Palm V entered in the area 210 of Fig. 4. For each search result, product name 310, a web site information link 309 and a hyper-linked product code 308 can be generated. The auction service provider thus has a database, which is accessible to all users to be searched. The database preferably includes a relational database table with the UPC codes for names of products, the table including the data sets (1647374643, "Palm HI connected organizer"), (1647384789, "Palm V connected organizer"), (1672228318, "Palm Vx connected organizer"), for example. In an additional table or the same table, a link to a site providing information about the products could be stored, so that for example one ofthe data sets could be (1647374643, "Palm HI connected organizer", "http://www.palm.com/products/palmiii/index.htmr').

The user can then click on hyper-linked product code 308 to generate auction information for that product code on the user's market browser.

Alternately, a mouse button click or other action could immediately begin a search in the product browser. Moreover, potential sellers 10, 20, 30 could provide for direct links from products in their catalogs to the market browser, so that a click on the catalog item pulls up the auction occurring on the market browser. As shown in Fig. 3, once a product code has been identified in any of these manners and selected, the product code appears in data entry area 106 of query page 104. The product name can appear in an item name column 111, the best bid price and best offer price in a column 112, and the quantities ofthe bids and offers in a quantity column 113. Bidder identification 114 and potential seller identification 115 preferably are shown along with their respective bid and offer prices.

More than one product can appear in the columns 111, 112, 113, and the bid and offer data can be updated continuously, if the market browser provides for realtime operation, for example by using JAVA-based code.

By clicking on one ofthe items in column 111, 112 or 113, a market detail screen 211, shown in Fig. 6, for an item can be generated. The price feeds from the price server 40 in Fig.l are organized, for example, so that the highest bid prices and lowest offer prices are shown in bid column 212 and offer column 213, respectively. In this example, AMAZON is offering 20 PALM V connected organizers at $295.00 each, while Hia95 is bidding $275.50 for two ofthe same organizers. PALM is offering 15 ofthe organizers at $310.50 each.

The user viewing the screen can choose to hit a bid or accept an offer by clicking on one ofthe bids or offers. The providing ofthe potential seller and/or potential buyer identifications is highly advantageous, since this information is highly useful for non-financial products. For example, the customer may choose to buy from PALM because it is the manufacturer ofthe good, and thus is willing to pay more. In addition to hitting a bid or accepting an offer, the user also can submit a bid by clicking on a join buyers button 214, or submit an offer by clicking on a join sellers button 215. Certain users could be permitted only to be seller or only to be buyers, based on their user identification. Moreover, certain users could be limited to seeing only certain bids or offers. For example, Customerl, based on his or her area code, could be permitted only to view offers from sellers having the same area code or a certain geographical location. Likewise, AMAZON could be permitted to hit bids only of potential buyers between the ages of 25 and 64. The limitations or restrictions can be of any type or kind, including as a function of geographic, financial, or past auction historical data. In a database ofthe auction service provider, the limitations can be stored, for example, in a relational database table.

If a user decides to make a bid for a product, the user clicks on the join buyers button 214 to access a bid submission page 414, shown in Fig. 7. The potential buyer submits a quantity in a quantity field 415, a bid price in a price field 416, and provides shipping data in field 417 and payment information in field 418. The shipping data may be pre-stored information for that user, and the payment data preferably pre- stored credit card information. More than one shipping address and information about more than one credit card can be stored and the information expanded or edited by new address button 419 and new card button 420. Once the user has entered in the bid information, a finalize bid button 421 can be clicked. A cancel button 422 is also provided. In addition to the information shown, the bid submission page could include data input fields for time-to-live data, for example the bid should be kept open for 7 days. Restriction information for the specific bid, for example AMAZON would not be allowed to bit the bid, could also be entered. Vectored price or other information for different area codes or on the basis of other data could be provided as well. If the buyer were willing to accept used goods, the bidder/buyer could so indicate.

Once submitted, the bid is sent to the central server 40 (Fig. 1) ofthe auction service provider, and may be in a format (UserlD, ProductlD, ProductQuantity, Price, ShipAddress, CardNumber, Bid/Offer). When received by the central price server 40, the bid can be assigned a confidential reference number, which can be supplied to the user for permitting bid alterations or cancellation. "ShipAddress" can be an integral number, for example from 1 to 9 indicating which address ofthe user stored in the central database should be used for that bid. Likewise, "CardNumber" can be an integral number from 1 to 9. Bid/Offer can be a 0 or 1 indicating a bid or an offer. Since the bid is submitted on the bid or join buyers page, a zero is automatically assigned. Thus the bid submitted by Customer 1, who can have a UserlD number of 599910029, may form a data structure of (599910029, 1647374643, 1, 286.99, 1, 1, 0).

When received in the central price server 40, the processor ofthe server can assign the confidential reference number (provided through a random number generator for example) and read the last bit to determine that the data is for a new bid, as opposed to a new offer. The data structure can then be added to the price feed for product number 1647374643, so as to appear on the market browser of any user viewing that product number. Fig. 8 shows the bid 511 appearing on market detail page 211. A new bid can be displayed in real-time, so that the market browser is constantly updated. In other words, the price stream is broadcast to the market browser. A new bid or offer can be highlighted or otherwise marked, as can bids or offers by the user viewing the market detail screen. For example, the Customerl bid could be displayed in red to Customerl . If the user instead of submitting a new bid wishes to accept an offer or hit a bid, the user clicks on the offer or bid, for example as shown in page 211 in Fig. 6. For example, if Customerl clicks on the AMAZON offer 216 in Fig. 6, a buy page 616 is generated, which permits the user to enter a quantity to buy in a data entry field 617, and the shipping address, credit card or payment information, and an order completion button 618. Upon completion, the order can be sent to the settlement server 6 (Fig. 1) where the credit card information and available credit are validated in clearing mechanism 5 (Fig. 1).

The completed and settled transaction information is then sent to the seller, including the shipping information, credit card information, type of good bought, quantity bought, and price. The seller then ships the good to the buyer. In a like fashion, in an accepted bid, the seller is provided the same information once the transaction is settled.

The bid or offer is then updated, either by removing the bid and offer if all of the goods in the offer or bid have been sold, or by reducing the quantity bid or offered. A cleared and settled bid or offer can be held or buffered for a certain amount of time, and compared with other actions ofthe same user, to see if the user orders other goods from a same source. This buffering permits for shipping to be combined, and permits the auction service provider to bundle orders to be sent to a seller. Fig. 10 shows a join sellers or offer submission page 711, which may be accessed for example by button 215 shown in Fig. 6. The potential seller can provide information on the quantity of goods to sell in data input area 712, and a price in data entry area 713. An average delivery time may be specified, as can the types of credit cards which the seller is willing to accept, in a pull-down menu area 714. If desired, the potential seller can provide detailed shipping cost information, as well as adding price vectoring by clicking on button 715. Although the vectoring can be much more detailed, Fig. 11 shows a simple example of a price vectoring page 811 accessible through button 715. The potential seller can add price variations from the entered price in data entry area 713 in Fig. 10.

Users with addresses in different parts ofthe country would then view different offer prices for the good. Once the price vectoring, if any, is complete the seller returns to page 711 in

Fig. 10 and can submit the offer by clicking on button 716.

The present invention also permits for a stream of actual market prices to be generated for each product, the market price being the last completed and settled transaction. The price server can broadcast this information as well, for example in ticker form, and can include the seller and/or buyer identification. This market price stream advantageously can be provided publicly, and not merely to registered users, and may be sold for example to web site operators.

Fig. 12 shows a price ticker 900 for electronic organizers, the price ticker being generated from price streams of at least three different electronic organizers. In this preferred embodiment, each ticker entry includes a product name 901, a product high bid 902, a product low offer 903, the name 904 ofthe seller providing the low offer, and the most recent completed sale price 905. The entries on the right can be more recent in a streaming, real-time fashion, so that, for example, entry 907 first appears after entry 906.

The non-anonymous two-way continuous auctions ofthe present invention provide an advantageous way for determining prices of specific non-financial goods while still permitting for inclusion of important data, such as buyer and/or seller identifications

EXAMPLE 1: The following is a description of an embodiment of the present invention using object-oriented software, with the various parts ofthe embodiment described:

Price Server

The price server may be an INTEL-processor based server, and preferably operates such that prices are not posted anywhere but rather broadcast to every user across the network, h practice it is infeasible to rebroadcast potentially millions of prices thousand of times per second; instead it suffices to broadcast only those prices that have changed, and keep a copy ofthe old prices somewhere. In other words, the Market Browser "subscribes" to certain price feeds from any one of several Price Servers that act as a sort of bulletin board. These servers keep track ofthe current bids and offers in every product, receive price updates, and pass those updates to subscribers who have expressed an interest in those prices. This creates the illusion to the Market Browser of receiving a continuous broadcast of prices.

Universal Product Database

As the name implies, the system requires a large repository of product information in order to translate product names into the product codes that are used as indices into price and subscriber databases on the Price Server, h addition it holds links to fuller descriptions ofthe products and to the products' manufacturers.

Arbitration Server

A part ofthe price server, this sub-system acts as a policeman over the rest ofthe system, ensuring, among other things, that users are authorized, accredited, and well behaved.

Settlement Server

This server takes a consummated, authenticated trade and decomposes it into smaller instructions for the exchange of cash and goods, then dispatches these instructions to other computer systems for fulfillment. It also sends a trade confirmation to both users.

The Market Browser

Similar to Web browsers, the Market Browser serves as the interface between users and the network. While the underlying predefined data structure for transmitting bids, offers, intentions to trade, trade confirmations, etc., are fixed, the interface can be varied in many ways to suit the user. E.g., a child shopping for clothes may want a completely different setup, with restrictions on permissible products and quantities. Moreover, the open architecture ofthe proposed system lends itself particularly well to automatic trading, i.e. trading performed completely by the computer according to a set of rules. This may be of interest to users who employ automatic trading "agents."

Data Structures

The following are the principal data structures used by the embodiment of example 1 in C-like pseudo-code. Bold indicates global variable names or data structures. The data structures are described as are the major types of messages that each server in the system will send and receive, as well as the algorithm for processing these messages. There is generally a close correspondence between data structures and message types, so that in many cases sending a message of type X means simply sending an instance of data structure X.

Good

This represents a good to be traded on the system. In principle the system still works if goods are multiply defined, i.e., if two fungible goods have different GoodlDs. In practice this is obviously very undesirable. Conversely, if two different goods have the same GoodlD, this will lead to unpredictable behavior and will not be allowed.

Good = { // not in the ethical sense

GoodlD; // a number

StandardUnit; // e.g., a bushel, a barrel, one unit }

User

Just as the name implies, buyers and sellers on the system are referred to as users. The system may treat buying and selling symmetrically; in other words, the system is not skewed to particular market situations, such as Ebay-style one seller / multiple buyer scenarios, or search bot one buyer / multiple sellers scenarios-instead it may include them both. The PaymentServer and DeliveryServer variables are pointers, e.g. JJP addresses, of servers that can process requests for payments and deliveries, respectively. The PublicKey is a PGP public key, or an index into a public key server.

User = {

UserlD;

EmailAddress;

IP Address;

PaymentServer; // e.g., credit card details DeliveryServer; // e.g., home address, -FedEx acct

PublicKey; // for signing messages Subscription Action

This data structure represents a user's request to start or stop subscriptions to prices for a particular good.

SubscriptionAction = {

Subscription!!-);

GoodlD; Type = {START,STOP,STOPALL};

TimeSent;

Signature; // is it really me? }

Price Action

This is the most complicated data structure. A price action is a generic term for either a bid or an offer for a given quantity of a good. It may be advantageous to show different prices to different people for the same good. This is accomplished in the system with two key elements: the notion of a classification table (which is held on a classification server), and a price vector. Simply put, a classification table is a mapping between a user ID and an integer that represents that user's category according to some criterion. A typical example would be a table that maps a user ID to a number 1 to 50 that represents the state of that user's address (assuming the user lives in the US). A user who wished to offer the same good at different prices depending on the home state of the buyer would then submit a price vector of 50 different prices (and perhaps 50 different quantities as well) depending on the category ofthe buyers. Because of its generality, this scheme would allow a user, in theory, to post a different price for each fellow user on the system for the same good. This feature is called price multiplexing. Each price action submitted to the system therefore needs to include the network address ofthe appropriate classification server, as well the number of categories to be used (the dimension ofthe price and quantity vectors).

The system can provide certain standard classification tables, such as home state, country, zip code, area code, etc., so that in most cases users would not need to build their own. And of course the system does not require a classification server — it could be set to NONE, in which case the price action in question would appear to be the same price to everyone, and the "dimension" ofthe price and quantity vectors would simply be 1.

PriceAction = { PriceActionID;

UserlD;

ClassificationServerAddress;

GoodlD;

Type = {BID,OFFER}; Dimension;

PriceVector; // per standard unit

TimePosted;

TimeToLive; // how long are the prices good?

MinimumQuantityVector; // in standard units MaximumQuantityNector; // in standard units

Morernfo; // link to information about the price

Signature; }

Cancel Price Action

To cancel a bid or order.

CancelPriceAction = {

PriceActionID; // which price do I want to cancel?

Type = {ONE,ALL} ; // just that one or all my prices? TimePosted; Signature; }

Update Price Action

This represents a request to amend either a price or a quantity for a price action that a user has aheady submitted. Needless to say a user may amend only prices she has submitted. Note that because of price multiplexing (section 3.1.4), prices and quantities may be vectors instead of scalars.

UpdatePriceAction = {

PriceActionID; Field = {PRICE,MORE_INFO,M]N_QUANTITY,MAX_QUANTITY} ;

NewNalueVector; }

Trade Action

This represents a request to effect a trade. Two things must occur for a trade to happen: first, one user must submit a price action - a bid, say; second, another user must send a trade action that says, "I want to sell you a certain quantity (between your minimum and maximum quantities) at your price." This sequence then generates a fill (see next section). TradeAction = { TradeActiorύT); PriceActionID; Type = {BUY,SELL}; Quantity; // in standard units

Signature;

}

Fill A fill refers to an effected trade, which is defined by two users, a good, a quantity, and a price. This object can be passed along to a sub-system that decomposes it into requests for payments and deliveries of goods.

Fill = { FilHD;

BuyerUserlD; SellerUserJD; GoodlD; Quantity; Price;

}

The Price Server

The Price Server is responsible for five principal tasks:

maintaining the list of current bids and offers for each good (the PriceTable); maintaining the list of current bids and offers for each user (the UserTable); maintaining the list of price feed subscribers for each good (the SubscriberTable); maintaining the list of active subscriptions for each user (the SubscriptionTable); sending price updates to subscribers when a new bid or offer appears or an old one is modified. The PriceTable is defined to be an array of lists, indexed by GoodlD, where each list contains all the bids and offers (i.e. PriceActions) referring to that good.

The UserTable is defined to be an array of lists, indexed by UserlD, where each list contains all the active PriceActions that belong to that user. Note that in principle this table could be derived from the PriceTable by searching across all PriceActions to find a given UserlD. The system can maintain these tables separately since keeping two tables is computationally more efficient than repeated searches across the PriceTable.

The SubscriberTable is defined to be an array of lists, indexed by GoodlD, where each list contains all the users who have subscribed to prices for that good.

The SubscriptionTable is defined to be an array of lists, indexed by UserlD, where each list contains all the Goods to whose prices a given user may be subscribing. Again, the information in this table aheady exists in a different form in the SubscriberTable but in order to save on search time the system maintains this table as well.

The following are the main messages that the price server handles. The algorithm for handling each message is included as well. The variables listed in parentheses after the name ofthe message correspond to arguments to the message handling routine.

> ADD_PRICE_ACTION

This message a user sends in order to submit a bid or offer on a good (a "price action").

ADD_PRICE_ACTION (PriceAction pa, User tr) ^• is pa authentic? NO: error; YES: continue is tr authorized? NO: error; YES: continue add pa to PriceTable {pa.GoodID} add pa to UserTable {pa.UserJJD} ^• SEND_PRICE (pa) // see below return to Wait State

> SEND_PRICE

This is a request for the Price Server to broadcast a given price action to the trading community. In reality it will be sent only to those users who have subscribed to prices for that good.

SEND_PRICE (PriceAction pa) retrieve list of users subscribing to prices for pa.GoodID from SubscriberTable[pa. GoodlD] ; for each user tr in the list: ^• is pa.ClassificationServer specified?

YES: send tr .UserlD to ClassificationServer and let cat be the resulting category returned. ^• NO: let cat = 0;

Send {pa.Type,pa.MinimumQuantityNector[cat], pa.MaximumQuantityNector[cat], pa.PriceNector, pa.TimeSubmitted,pa.TimeToLive, pa.GoodID, pa.PriceActionID} package to tr Return to Wait State

> SEΝD_ALL_PRICES

This is a request for the Price Server to send all the price actions for a given good to a given user. This request would take place, for example, when a user subscribes to prices for that good for the first time.

SEND_ALL_PRICES (GoodlD gid, UserlD tid)

Retrieve list of PriceActions from PriceTable {gid} For each PriceAction pa in the list: is pa.ClassificationServer specified?

YES: send tid to ClassificationServer and let cat be the resulting category returned. ^• NO: let cat = 0

Send {pa.Type, pa.MinimumQuantityNector[cat], pa.MaximumQuantityNector[cat], pa.PriceNector[cat], pa.TimeSubmitted, pa.TimeToLive, pa.GoodTD,pa.PriceActionID} package to tid Return to Wait State

> UPDATE_PRICE_ACTIOΝ (UpdatePriceAction upa, User tr)

This message is sent when a user wishes to alter some aspect of a price action she has submitted.

UPDATE_PRICE_ACTION

Is upa authentic? NO: error; YES: continue is tr authorized? NO: error; YES: continue find the PriceAction pa such that pa.PriceActionID == upa.PriceActionJ-D does pa.UserlD — tr.UserlD? NO: error; YES: continue ^• overwrite the appropriate field of pa with the new value set pa.TimePosted = now

SEND_PRICE(pa) return to Wait State

> CANCEL_PRICE_ACTION (CancelPriceAction cpa, User tr)

This message is sent when a user wishes to cancel some or all of her prices.

CANCEL_PRICE_ACTION is cpa authentic? NO: error; YES: continue is tr authorized? NO: error; YES: continue switch (cpa.Type) case ONE: find the PriceAction pa such that pa.PriceActionID — cpa.PriceActionID does pa.UserlD = tr .UserlD? NO: error; YES: continue delete pa from PriceTable {pa. GoodlD} ^• delete pa from UserTable {tr .UserlD} send updates to SubscriberTable {pa. GoodlD} case ALL:

Retrieve the list of PriceActions belonging to tr from UserTable {tr.UserlD} For each PriceAction pa in the list: ^• Delete pa from PriceTable {pa. GoodlD}

Send updates to SubscriberTable {pa.GoodID} ^• Delete UserTable {tr.UserlD} return to Wait State

> RETRIENE_PRICES_BY_User

This message is used when user A wishes to know all the prices being posted by user B, where user A and user B need not be the same person. An example of such a request is when a user loses track of what prices she may have posted and wants to retrieve them to make sure they are correct. Another is if a user wishes to see all the prices being offered by a store that happens to be in the neighborhood. The data structure does not allow anonymous prices, but in practice people may want to trade through brokers in order to be anonymous.

RETRIENE_PRICES_BY_User (User tr, UserlD target_userid) is tr authentic? NO: error; YES: continue is tr authorized? NO: error; YES: continue look up list of PriceActions in UserTable {target_userid} send this list of PriceActionTDs to tr;

> HANDLE_SUBSCPJPTION_ACTION This message is used when a user send a request either to start or stop a subscription to prices for a given good, or wishes to cancel all subscriptions at the same time.

HANDLE_SUBSCRIPTION_ACTION (SubscriptionAction sa, User tr) ^• is tr authentic? NO: error; YES: continue is tr authorized? NO: error; YES: continue does sa. GoodlD exist? NO: error; YES: continue switch (sa.Type) case STOPALL: ^• retrieve list of PriceActions in UserTable {tr.UserlD)

For each PriceAction pa in the list: remove tr.UserlD from SubscriberTable {pa. GoodlD) remove pa.GoodTD from SubscriptionTable {tr.UserlD} send Confirmation ^• return to Wait State case STOP:

Remove tr.UserlD from SubscriberTable{sa.GooάTD} Remove sa.GoodlD from SubscriptionTable {tr.UserlD} Send Confirmation ^• Return to Wait State case START:

Is User already subscribed to sa. GoodlD? ^• IfNO:

^• Add tr.UserlD to SubscriberTable {sa.GooαTD} ^• Add sa.GoodlD to SubscriptionTable {tr.UserlD}

Send Confirm

^• SEND_ALL_PMCES(sa.GoodID,tr.UserID) Return to Wait State

Arbitration Server Specifications > AUTHENTICATE_MESSAGE

Given a user and a signature, this message is a request to make sure the signature really was generated using the user's PublicKey. The crypto details are left out.

AUTHENTICATE_MESSAGE(Signature sig, User tr)

^• Was sig generated by tr.PublicKey? YES : reply YES ; NO : reply NO Return to Wait State

> AUraORIZEJJser

AUTHORIZE_User(User tr)

Is tr in the list of authorized users? YES : reply YES ; NO : reply NO. Return to Wait State

Settlement Server Specifications

> HANDLE_TRADE_ACTION

This conveys the message that user wants to effect a trade with another. When it receives this message, the settlement server checks to make sure the request is really coming from who it claims to be; makes sure the trade action is coming from an authorized user; makes sure the quantity conforms to the minimum and maximum quantities appropriate to a user in that category; and, as appropriate, either decrements the minimum and maximum quantites ofthe price action or cancels it altogether. Finally it packages together the ID' s ofthe buyer and seller, the price, good, quantity, etc., into a fill, and sends a request for this fill to be handled.

HANDLE_TRADE_ACTION(TradeAction ta, User tr) Is ta authentic? YES: continue; NO: error Is tr authorized? YES: continue; NO: error Is there a PriceAction pa in PriceTable such that pa.PriceActionJ-D = ta.PriceActionID ? YES: continue; NO: error

Does pa.UserID = tr.UserlD ? YES: error (can't trade with yourself); NO: continue ^• Compute the Category of tr by polling pa. ClassificationServer, if specified. Call it cat.

Compute TradedPrice = pa.PriceNector[cat] Compute TradedQuantity = pa.QuantityNector[caf] Is TradedQuantity between pa.MinimumQuantityNectorfcat] and pa.MaximumQuantityNector[cat]? YES: continue;. NO: error

Is TradedQuantity < pa.MaximumQuantityNector[cat] ? YES: decrement pa.MaximumQuantityNector[cat] and pa.MinimumQuantityVector[cat] by TradedQuantity (set the latter to 0 if it's negative). - NO: CANCEL_PRICE_ACTION(pa,SYSTEM) // SYSTEM is a built-in user with universal access Generate Fill fi ^• HANDLE_FILL(fι)

> HANDLE_FΓLL

This is the part ofthe system that interfaces with existing payment and delivery systems specified by both users.

HANDLE_FILL(Fill fi) Send payment message from buyer to seller to buyer's PaymentServer

Send delivery message from seller to buyer to seller's DeliveryServer Send confirm to both

Claims

WHAT IS CLAIMED IS:

1. A method for non-anonymous auctioning of non-financial goods by a plurality of users, the users including potential sellers and buyers, the method comprising the steps of: receiving offer data from a plurality of potential sellers, the offer data for each ofthe potential sellers including a respective user identification, a respective good identification, and a sales price; receiving bid data from a plurality of potential buyers, the bid data for each of the potential buyers including a respective user identification, a respective good identification, and a bid price; forming an auction price feed for at least one particular good as a function of the offer and bid data so as to form a plurality of offers and bids for the at least one particular good, the price feed including the user identifications, and the sales prices and bid prices for the particular good; and providing the auction price feed over a communications network.

2. The method as recited in claim 1 wherein the offer data and bid data are received by a central server.

3. The method as recited in claim 1 wherein the bid and offer data further include a quantity ofthe particular good.

4. The method as recited in claim 1 further comprising receiving an acceptance from an actual buyer, the acceptance corresponding to first offer data from a first ofthe plurality of sellers.

5. The method as recited in claim 1 further comprising registering the potential buyers and potential sellers through a central auction service provider.

6. The method as recited in claim 1 further comprising storing offer, bid and acceptance activity of he potential buyers and potential sellers in a central database.

7. The method as recited in claim 1 further comprising providing browser software to the potential buyers and potential sellers so that the providing step occurs in real-time.

8. The method as recited in claim 1 further comprising displaying the user identifications alongside a bid or offer ofthe user.

9. The method as recited in claim 1 wherein at least one ofthe bid price and the offer price is vectored.

10. The method as recited in claim 9 wherein the vectoring is a function of potential buyer personal data.

11. The method as recited in claim 9 wherein the vectoring is a function of at least one of geographical location data and historical activity data.

12. The method as recited in claim 1 further including providing a searchable product database, the searchable product database including product name information and product code information.

13. The method as recited in claim 12 wherein the product code information is a function ofthe universal product code.

14. The method as recited in claim 1 further including accepting credit or debit card information from the potential buyers.

15. The method as recited in claim 1 further including receiving trading restriction information from at least one ofthe potential buyers and the potential sellers.

16. The method as recited in claim 1 further including storing historical activity data ofthe potential buyers and the potential sellers.

17. The method as recited in claim 4 wherein the acceptance is cleared and then held or buffered for a period of time to await a second acceptance by the actual buyer.

18. The method as recited in claim 1 accessing the auction price feed by at least one of highlighting, clicking and cut and pasting text corresponding to the particular good.

19. A price ticker for a non-financial good comprising: a plurality of bids for the non-financial good; a plurality of offers for the non-financial good; a potential seller identification next to each ofthe plurality of offers for identifying a potential seller of each ofthe plurality of offers, the potential seller identification including an alphabetic string of characters.

20. The price ticker as recited in claim 19 further comprising a potential buyer identification next to each ofthe plurality of bids.

21. The price ticker as recited in claim 19 further comprising providing a hyperlink for each ofthe plurality of bids and offers, the hyperlink connecting to a market detail auction page.

22. A device for providing non-anonymous continuous two-way auctions for a plurality of non-financial goods comprising: a price server for receiving price data and broadcasting price feeds for the plurality of non-financial goods so as to provide a real-time stream of offers and bids to a browser, the real-time stream including the user identifications, and the sales prices and bid prices for at least one particular good; and a settlement server for settling accepted offers and bids.

23. The device as recited in claim 22 wherein one ofthe price server and settlement server include a database with credit or debit card information of potential buyers.

24. The device as recited in claim 22 further comprising a client device for accessing the price server, the client device including the browser.

25. The device as recited in claim 22 wherein the client device is one of a personal computer, hand-held personal device or wireless telephone.