WO2000036533A1

WO2000036533A1 - An auction system

Info

Publication number: WO2000036533A1
Application number: PCT/AU1999/001118
Authority: WO
Inventors: Michael Peter Groves
Original assignee: Michael Peter Groves
Priority date: 1998-12-17
Filing date: 1999-12-17
Publication date: 2000-06-22
Also published as: CA2394575A1

Abstract

An auction system including a server system (2) for sending current price messages (30) and for receiving bid messages (32), where the messages are transmitted using single IP packets, and in particular are transmitted using the User Data Protocol (UDP). This significantly improves latency associated with delivery of auction data. The system may be a Dutch auction system which sets a current price for a predetermined interval, and determines all bids received during the interval as being at that price. The current price is increased when the bids are not accepted. The system also has an interface which includes a clock device for displaying the current price based on received current price messages and displaying other data based on received bid reply messages.

Description

AN AUCTION SYSTEM

The present invention relates to an auction system and. in particular, to a system for conducting a Dutch auction or a conventional auction on a communications network such as the Internet.

A number of different auction systems have been established to trade goods over the Internet. Some of the systems have proved extremely popular, with one example being the system provided by Ebay at http://www.ebay.com. Most of the auction systems are based on conventional auctions, where the highest bid is accepted by the auctioning party to complete a sale. Conventional auctions are well suited to disposal of unique and expensive goods, such as real estate and automobiles, whereas Dutch auctions are well suited for disposing of a large number of less expensive goods, particularly perishable items, such as food and flowers, which decline in value over time. Internet auction systems also suffer from an inherent latency problem in communications over the Internet which use the Transmission Control protocol/Internet protocol (TCP/IP). In addition to the communications overhead added by TCP to the basic Internet protocol (IP), the auction systems use http transactions to send and acknowledge bids, and may even require completion of a CGI form in order to submit a bid. A delay in the submission and responses to bids handled in this manner prevents the auction system from being a true real-time auction where bids are handled instantaneously by the auctioning party, thereby giving the auction excitement and life. The latency due to the communications overhead can also lead to disputes where one party is in a location which results in its bids being received with some delay, whereas another party in a different location is not subject to any significant delay. It is desired to provide an auction system and method which are able to alleviate the above difficulties, or at least provide a useful alternative.

In accordance with the present invention there is provided an auction system including a server system for sending current price messages and for receiving bid messages, characterised in that said messages are transmitted using single IP packets. The present invention also provides an auction system including a server system for sending current price messages and for receiving bid messages, characterised in that said messages are transmitted using the User Data protocol (UDP).

The present invention also provides an auction method executed using a communications system, including sending current price messages from and receiving bid messages at a server system, characterised by transmitting said messages using single IP packets.

The present invention also provides an auction method executed using a communications system, including sending current price messages from and receiving bid messages at a server system, characterised by transmitting said messages using the User Data protocol (UDP).

The present invention also provides an auction method executed by a communications system, including: setting a current price for a predetermined interval; determining all bids received during said predetermined interval as being at said price; and increasing said current price when said bids are not accepted.

The present invention also provides an auction interface stored on a computer readable storage medium, including: a clock device for displaying a current price based on received current price messages: and an auction display device for displaying data representing the state of an auction based on received bid reply messages.

A preferred embodiment of the present invention is hereinafter described, by way of example only, with reference to the accompanying drawings, wherein:

Figure 1 is a block diagram of a preferred embodiment of an auction system; Figure 2 is a diagram of UDP packets used by the auction system;

Figure 3 is a flow diagram of a procedure executed by the auction system: Figures 4 and 5 are web pages generated by the auction system; and Figure 6 is a diagram of the auction system broadcasting a live auction. An auction system includes, as shown in Figure 1, an auction server 2 which is a computer system that includes web server software 4, and Java™ code to run on a Java virtual machine 6 of the server 2. The server 2 may be a standard Unix or Microsoft NT™ machine and the web server software 4 may be either Apache™, Netscape Enterprise Server™ or Microsoft IIS™ or Netscape Fasttrack Server™. The server 2 also includes a number of HTML and/or active server pages which are populated with data by the Java™ code and are forwarded as http responses 8 to http requests 10 received from a web browser 12 of a client computer system 14. The client system 14 may be connected to the server 2 by a communications network, such as the Internet, and the web browser 12 may be Netscape Navigator™ or Microsoft Internet Explorer™. Bidding parties are able to use their client system 14 and web browser 12 to access and use the auction system established by the server 2. The HTML and Java™ code of the server 2 controls access to the auction system, operation of the system and generation of the pages for display by the client browser 12. as described below.

The auction server 2 executes code on the Java virtual machine 6 to generate pages which offer items for auction in lots. The client 14 is able to join the auction by forwarding a http request 10 to the server's IP address in order to be provided with the pages in http responses 8. The client 14 on accessing the server 2 in this manner also receives a Java applet by a further http response 16 which begins executing on a Java virtual machine 18 of the browser 12 of the client 14. The applet establishes a user data protocol (UDP) port 20 on the client^'s system 14 which is able to communicate with a UDP port 22 of the server 2 established by a reciprocal Java program executing on the server 2. Like TCP, which is commonly used with the Internet protocol (IP), UDP is a transport layer service. However unlike TCP, messages can be sent using a single IP packet whereas TCP always establishes a connection that requires a minimum of three IP packets, the connection request, the reply and a connection confirmation packet, to send a message. UDP also only adds a short header to IP packets. UDP provides direct access to IP packets to the extent that UDP packets can be considered to be equivalent to IP packets. UDP is described in detail in the Internet RFC 768. which is herein incorporated by reference.

The auction server 2 uses the UDP port 22 to multicast offer or current price messages

30. as shown in Figure 2. The message 30 is shown in Figure 2 as a UDP packet comprising 32 bytes with a header that includes a message digest field of 16 bytes and a message type field. For transmission a UDP header and an IP header are also added to the packet 30. The data payload contains fields representing the number of the current lot. a bid number indicating how- many bids have been made in the current auction, and a current price field which represents the current price at which the goods of the lot are being offered. The message type field in the header represents that the message is a current price message. A message digest for the rest of the header is obtained by executing the MD2 message digest algorithm on the remaining fields of the packet 30 and then encrypting the result with the digital encryption standard (DES) algorithm using a session key for the session between the client 14 and the server 2. The web server 4 during a session with a client web browser 12 causes the browser 12 to request the generation of a unique session key. A key agreement protocol such as the Diffie-Hellman protocol is used to set up the session key. Alternatively the session key can be created by either the client 14 or the server 2 and exchanged using a public key cryptography technique, such as signed Java applets or the secure sockets layer (SSL). The message digest is used to confirm that the source of the packet 30 is the auction server 2. Before the receiving the packet 30. the client system 14 decrypts the message digest and compares it with a message digest determined using the MD2 algorithm on the received data payload to ensure that the two are the same, thereby guaranteeing that the packet 30 with a price offer has been sent by the auction server 2. The payload of the offer message 30 does not need to be encrypted, as it is available for all clients 14 connected to the server 2.

At each stage during the auction, on receipt of the offer messages 30. a party can use the client system 14 to send a bid message 32 which comprises a UDP packet of 44 bytes, as shown in Figure 2. For transmission a UDP header and an IP header are also added to the packet 32. Until a bid is acted on the by the server 2, the data contained in the bid message 32 should be kept secret, so the bid message has its data payload encrypted using DES with the session key. The payload includes fields for the number of the bid. the lot number of the item for which the bid is placed, the quantity or number of items associated with the bid. and the price for the bid. The header of 28 bytes includes an encrypted message digest, a field indicating the type of message, and two additional fields for a number representing the bidding party or client, and data representing the length of the payload before encryption.

Bid reply messages 34 are also sent as UDP packets with a structure similar to that for the bid packets 32, as the reply messages 34 also have their payload encrypted for privacy. The reply message 34 informs the bidding party that the bid of the bid message 32. or another bid. has been accepted. The payload of the bid reply message 34 includes fields for the result of the bid with data being provided on the bids which have been accepted for the client for the current lot and any other lots.

The use of the message format 30 and 32 with UDP is particularly advantageous as this significantly reduces latency associated with transmitting auction price and bid information between clients and servers of an auction system. The message formats 30 and 32 add minimal overhead to network layer IP packets.

As discussed above. TCP provides a guarantee that packets sent will be received by the intended recipient within a reasonable amount of time, and in the correct order, or the sending system is informed of an error and retransmission occurs. To achieve this. TCP insists on the receiving system acknowledging all information packets with a reply packet. TCP also adds a short checksum to each packet so that the receiving system can reject erroneous packets. The sending system resends packets if it does not receive an acknowledgement within a short period of time, and if after several attempts the sending system is not able to receive a successful acknowledgement, the user is informed accordingly.

UDP on the other hand only offers IP packets which can be lost or corrupted in transmission from a sending system to a receiving system. To address this, the packets sent by the auction system that need to be ordered are numbered. If a current price packet is missed or arrives out of order, time constraints for a real-time auction mean that retransmission should not be undertaken and information should simply be obtained from the next current price packet.

Accordingly the current price packets 30 are not numbered. However it is important to ensure that bid packets 32 arrive in order, and so these packets are numbered. Similarly, with regard to acknowledgements and replies, only those packets which require replies are replied to. The current price packets 30 are not replied to. whereas the bid packets 32 are replied to. As the system is an auction system, any reply packets are used to forward information for the conduct of an auction. For instance, the bid reply messages 34 are sent as reply packets. The message digest fields are added to the UDP packets to enable the rejection of any corrupted or garbled packets. The system also adds features to the UDP packets which are not provided by TCP and are advantageous for an auction system. For example, the message digest is encrypted with the secret session key providing an added level of protection over TCP. Furthermore bid messages 32 are repeated immediately to ensure they are received in the minimum amount of time, without waiting for a reply message, as with TCP. Bid reply messages 34 are similarly duplicated for duplicate bid messages 32.

The auction system can be used to establish a Dutch auction, as described below, and when doing so. the packet formats 30. 32 and 34 are particularly advantageous in delivering real-time price, bid and acceptance information during a Dutch auction. Dutch auctions are characterised by their fast pace and their ability to dispose of lots comprising a large number of items in a short period of time, and are particularly useful for disposing of perishable items which degrade in value over time. In a Dutch auction, the auctioning party or auctioneer begins at a high price for a lot and then descends by steps until a bidder indicates his intention to buy at the current price. The successful bidder nominates all or part of the goods on offer. If any goods remain in the current lot. the auctioneer increases the offer price by a predetermined amount and resumes the auction. The auction for a lot continues in this manner until the stock for the lot is exhausted or a reserve price is reached. Current price information needs to be sent rapidly to the client 14 on a continual basis, and as a bid is normally automatically accepted, bid price information needs to be received and responded to in a timely and secure manner. These requirements are met by the communication method described above.

The auction system begins a Dutch auction for a lot by setting the current price at a start price and a variable strikes to 0. as shown in Figure 3 at step 40. The auction server 2 accordingly generates a Dutch auction page 60, as shown in Figures 4 and 5, which is sent to all clients 14 logged onto the server 2 for display by their browsers 12. The page 60 is a dynamic interface, having a clock 62 which displays the current offer price and remaining data fields on the page being generated by a Java applet running on the Java virtual machine 18. The interface is updated continuously by messages sent from the server 2, such as the UDP messages 30 and 34.

The server 2 broadcasts a current price message 30 to decrement the current price and display a new current price offer as indicated by the message 30. at step 42. The current price is displayed and indicated by the hand 64 of the clock 62. The system 2 then waits for a predetermined period time, i.e. a price interval, at step 44. and determines whether any bid messages 32 have been received at step 46. If no bids have been received and it is determined at step 48 that the current price has not yet been decremented to the reserve price for the lot then step 42 is executed again to decrement the current price by sending a further current price message 30. The price interval of step 44 is important as it allows all bids received within that interval to be treated as being equal in time or isochronous. This ensures the bid process is 5 equitable and fair for bidding parties located in a variety of distributed locations, notwithstanding the reduction in latency provided by use of the UDP packets 30, 32 and 34. The interval may be set as desired, and typically may be 1 second. If bids are received within the price interval, as determined at step 46, and the number of items bid for in total is less than or equal to the available stock, as determined at step 47. then the auction server proceeds to step

10 50 to execute the sales based on the bid messages 32 received. Once the sales have been confirmed at step 50 by forwarding the reply messages 34, the server determines at step 52 if all of the units or items of the lot have been sold. If not. the strikes variable is set to 0 at step 54 and the current price is incremented by a sale increment at step 56. by sending the corresponding current price message 30. and operation returns to step 42 to continue the auction. The auction

15 moves to the sale of another lot, at step 49. if it is determined at step 48 that the current price has reached the reserve price for the lot, or if it is determined at step 52 that all of the items of the lot have been sold.

The page 60 shown in Figure 4 indicates that the auction is progressing and that so far 0 there has been a sale of 140 units of the current lot to a bidder Multiflora at $67. A units remaining display field 64 indicates that 160 units remain. Within the price interval, two bids are then received when the hand 64 reaches S59, one from Allied Flowers and one from Acme Flowers for 50 and 60 units respectively. The server 2 treats these bids as being isochronous, and as there is sufficient units or items left in the lot. both of the bids can be accepted, as 5 displayed in the page of Figure 5. This is far more preferable than accepting the bid of Allied Flowers at $59 and then continuing the auction and hoping that Acme Flowers will again bid at $59. The speed of the auction is also enhanced.

If the number of bids received within the price interval relates to more than the available 0 units, as determined at step 47. then a determination is made by the server 2 at step 53 as to whether the bidders correspond to one bidding party. If the determination is positive, then there is no conflict and the remaining stock can be distributed to the bidding party at step 59 and reply messages sent at step 50 to confirm the sale. If however there is more than one bidder, then operation proceeds to step 55 where the strikes variable is incremented. If it is determined at step 57 that the strikes variable does not equal 3, i.e. this conflict situation has not occurred three times before making a sale, step 56 is executed to simply increment the price and continue with the auction, on the chance that one of the bidding parties may not repeat their conflicting bid. This again enhances the speed of the auction.

If however at step 57 it is determined that the strikes variable does equal 3. three conflicts have occurred before making a sale, and step 59 is executed to distribute the remaining stock amongst the existing parties as equitably as possible. The auction server 2 will send corresponding sale messages 34 at step 50. after executing at step 59. the following decision steps:

(i) The number of units bid for each bid is reduced at least to the number of units or goods on offer. This is done to deal with any bidder that may have sought an excessive number of the goods, thereby distorting the distribution procedure. (ii) A total number of the items bid for is determined, referred to hereinafter as

Bidtotal.

(iii) The bidders are allocated each a number of units based on a truncation of

(Number of items bid for x Number of items available)/Bidtotal. (iv) For any units leftover, these are allocated randomly amongst the bidders with the probability of a bidder getting an additional unit being based on the remainder the bidder had in the formula of step (iii) prior to truncation.

For example, if there are three bidding parties A. B and C and each submits bid messages for 5 units, yet there are only 10 units available on offer, the above distribution procedure may begin with bidder A being assigned 3 units, plus a 1/3 chance of obtaining a further unit. If A obtains the further unit, then the remaining 6 units are divided equally between B and C. If the procedure however determines that A does not receive the additional unit, then B obtains 3 units and a 1/2 chance of getting an extra unit, and C will receive whatever remains.

More precisely, the distribution procedure of step 59 executes the following steps:

( 1 ) Consider the first/next bidder.

(2) Assign the bidder an initial allocation of:

Truncate ((Quantity bid for x Quantity available)/Bidtotal). (3) If there is a remainder from step (2), generate a random number between 0 and 1.

(4) If the remainder is greater than the random number, the bidder is allocated 1 more unit.

(5) The quantity allocated to the bidder is subtracted from the quantity available. (6) The quantity bid for is subtracted from Bidtotal.

(7) If there are further bids to be dealt with return to step (1).

Applying the above procedure, if there are. for example, three bidders A, B and C and each has asked for 5 units, but there are only 8 units on offer, each is allocated 2 units plus a chance to the remaining 2 units. Bidder A is initially allocated 2 units plus a 2/3 chance of obtaining a further unit. If A does not obtain the extra unit, the remaining 6 units are divided equally between B and C. However if A receives the extra unit then B is allocated 2 units and a 1/2 chance of obtaining an extra unit, and C receives the remainder after B has been dealt with.

The above distribution procedure for step 59 can of course be varied, and bidders can be given the option of selecting that their bid cannot be adjusted, i.e. either it is accepted on the basis of the values of the bid message 30 or rejected.

The auction system described above is particularly advantageous as it adopts a method of communication and auction procedures which enhance the speed of auctions conducted by the system. The auction system is particularly useful in conducting a real-time Dutch auction over a communications network, such as the Internet, which can be used to dispose of a large number of goods in a short period of time.

The auction system can also be advantageously used to conduct a conventional auction.

This simply involves adjusting the system described above to execute the following conventional auction steps:

(a) set the initial offer price to the starting price for the lot;

(b) send the current offer price for display: (c) waiting a predetermined amount of time for a bid;

(d) if a bid is received in the time interval, set the current offer price to the bid price and return to step (b);

(e) if no bid is received in the interval, then declare the lot is ""going once": (f) repeat steps (c) and (d);

(g) if no bid is received in the interval, then declare the lot is "going twice"; (h) repeat steps (c) and (d); and

(i) if no bid is received in the interval, then declare the lot "gone^", sold to the highest bidder, then move on to the next lot if any and return to step (a).

For a conventional auction the price clock 62 displays the current bid price to bidding parties. The current bid price is adjusted on the basis of the current price message 30 sent during step (b).

The architecture of the auction system can be extended to cater for broadcast of a live auction, as shown in Figure 6. The live auction is conducted by an auctioneer 72 with a number of bidders 74 present, together with a broadcaster 76 who may also bid on his or other^'s behalf. The broadcaster has a computer system 78 connected to, or part of, the auction server 2. The computer system 78 constitutes a client system 14 and accordingly is able to receive all of the interfaces generated by the server 2. In addition, the computer system 78 also includes a computer program to transmit current price messages to the server 2, in the same format as the current price messages 30. This allows the broadcaster to relay current price information from the auctioneer 72 to others using client machines 14 connected to the server 2 over a communications network, such as the Internet 80. The server 2 instead of generating the current price messages simply relays those received from the system 78. as the auction is controlled by the auctioneer 72. not the server 2.

The broadcaster 76 is able to use the program of the system 78 to submit status messages, in the same format as the bid messages 32. advising on the status of the auction, such as "going once", "going twice^"' and "'gone^". The program also conveys bid messages received at the auction server 2 from other parties to the broadcaster 76, so that the broadcaster can place those bids with the auctioneer 72, in accordance with the received messages 32. Once the bids have been accepted by the auctioneer 72. the broadcaster 76 uses the software to send bid reply messages back to the clients 14 via the server 2.

The computer system 78 may be connected to the auction server 2 using one or a combination of known communication paths, and may also be incorporated into the auction server 2.

Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as herein described with reference to the accompanying drawings.

Claims

CLAIMS:

1. An auction system including a server system for sending current price messages and for receiving bid messages, characterised in that said messages are transmitted using single IP packets.

2. An auction system including a server system for sending current price messages and for receiving bid messages, characterised in that said messages are transmitted using the User Data protocol (UDP).

3. An auction system as claimed in claim 1 or 2. wherein said messages include a message digest encrypted with a session key.

4. An auction system as claimed in claim 3. wherein said current price messages include a header with said message digest and a message type field, and data fields representing a current lot and a current price for at least one item of the lot.

5. An auction system as claimed in claim 3. wherein said bid messages include a header with said message digest and fields representing message type, total length of data fields and a bidder, and data fields representing a current lot. a bid. and a price for the bid.

6. An auction system as claimed in claim 5, wherein said data fields of said bid messages are encrypted with the session key.

7. An auction system as claimed in claim 1 or 2. wherein said server system sends bid reply messages with fields representing acceptance of bids of said bid messages.

8. An auction system as claimed in claim 1 or 2. wherein said auction system is a Dutch auction system that includes: means for setting a current price for a predetermined interval; means for determining all bids received during said predetermined interval as being at said price: and means for increasing said current price when said bids are not accepted.

9. An auction system as claimed in claim 8. wherein said bids are not accepted when they correspond to more than the available stock for an auction lot. and there is more than one bidding party.

5 10. An auction system as claimed in claim 9. wherein said stock is distributed and sold when said bids are not accepted a predetermined number of times.

11. An auction system as claimed in claim 1 or 2. including: a clock device for displaying a current price based on said current price messages; and 10 an auction display device for displaying data based on bid reply messages.

12. An auction system as claimed in claim 11. wherein said current price is a current offer price which is decreased when said bid messages are not received by said server system.

15 13. An auction system as claimed in claim 1 1. wherein said current price is a current bid price.

14. An auction system as claimed in claim 1 or 2, wherein said auction system is a conventional auction system having means for executing the following: 0 (a) set a current price to an initial price for a lot;

(b) send a current price message to display said current price;

(c) set said current price to the price of a bid message received within a predetermined period of time and return to step (b);

(d) send a message to indicate the lot is going once when a bid message is not 5 received within said predetermined period of time;

(e) repeat step (c);

(f) send a message indicating the lot is going twice if no bid is received within said predetermined period of time:

(g) repeat step (c); and 0 (h) send a bid reply message indicating sold to the highest bidder when a bid is not received within said predetermined period of time and return to step (a).

15. An auction svstem as claimed in claim 1 or 2. wherein said auction svstem includes means for executing the following:

(a) initialising a current price of an auction and displaying the current price on a display;

(b) initialising the value of a price adjustment factor;

5 (c) maintaining the current price for a price interval time period;

(d) decrementing the current price if no bids are received within said interval:

(e) treating all bids received within any one price interval as being isochronous and equal;

(f) accepting received bids by considering the isochronous bids, an amount of items 10 within a lot of the auction, and an amount of items for which respective bids were made;

(g) adjusting the current price displayed on the display by the price adjustment factor depending upon whether bids have been accepted: and

(h) repeating steps (c) to (g) until said items of said lot are allocated to accepted bids 15 or the current price has reached a reserve price.

16. An auction method executed using a communications system, including sending current price messages from and receiving bid messages at a server system, characterised by transmitting said messages using single IP packets.

20

17. An auction method executed using a communications system, including sending current price messages from and receiving bid messages at a server system, characterised by transmitting said messages using the User Data protocol (UDP).

25 18. An auction method as claimed in claim 16 or 17, wherein said messages include a message digest encrypted with a session key.

19. An auction method as claimed in claim 18, wherein said current price messages include a header with said message digest and a message type field, and data fields representing a

30 current lot and a current price for at least one item of the lot.

20. An auction method as claimed in claim 18. wherein said bid messages include a header with said message digest and fields representing message type, total length of data fields and a bidder. and data fields representing a current lot. a bid, and a price for the bid.

21. An auction method as claimed in claim 20, wherein said data fields of said bid messages are encrypted with the session key.

5

22. An auction method as claimed in claim 16 or 17. including sending bid reply messages with fields representing acceptance of bids of said bid messages.

23. An auction method as claimed in claim 16 or 17. including for a Dutch auction: 10 setting a current price for a predetermined interval: determining all bids received during said predetermined interval as being at said price; and increasing said current price when said bids are not accepted.

15 24. An auction method as claimed in claim 23, wherein said bids are not accepted when they correspond to more than the available stock for an auction lot, and there is more than one bidding party.

25. An auction method as claimed in claim 24, including distributing and selling said stock 0 when said bids are not accepted a predetermined number of times.

26. An auction method as claimed in claim 16 or 17, including: displaying with a clock device a current price based on said current price messages; and displaying data based on bid reply messages. 5

27. An auction method as claimed in claim 26, wherein said current price is a current offer price which is decreased when said bid messages are not received by said server system.

28. An auction method as claimed in claim 26. wherein said current price is a current bid 30 price.

29. An auction method as claimed in claim 16 or 17. including executing the following: (a) set a current price to an initial price for a lot: ( b) send a current price message to display said current price;

(d) send a message to indicate the lot is going once when a bid message is not received within said predetermined period of time:

(e) repeat step (c);

(f) send a message indicating the lot is going twice if no bid is received within said predetermined period of time;

(g) repeat step (c); and ( h) send a bid reply message indicating sold to the highest bidder when a bid is not received within said predetermined period of time and return to step (a).

30. An auction method as claimed in claim 16 or 17. including executing the following:

(a) initialising a current price of an auction and displaying the current price on a display:

(b) initialising the value of a price adjustment factor;

(c) maintaining the current price for a price interval time period;

(d) decrementing the current price if no bids are received within said interval;

(e) treating all bids received within any one price interval as being isochronous and equal:

(f) accepting received bids by considering the isochronous bids, an amount of items within a lot of the auction, and an amount of items for which respective bids were made;

(h) repeating steps (c) to (g) until said items of said lot are allocated to accepted bids or the current price has reached a reserve price.

31. An auction method executed by a communications system, including: setting a current price for a predetermined interval; determining all bids received during said predetermined interval as being at said price: and increasing said current price when said bids are not accepted.

32. An auction interface stored on a computer readable storage medium, including: a clock device for displaying a current price based on received current price messages; and an auction display device for displaying data based on received bid reply messages.