CA2394575A1 - An auction system - Google Patents
An auction system Download PDFInfo
- Publication number
- CA2394575A1 CA2394575A1 CA002394575A CA2394575A CA2394575A1 CA 2394575 A1 CA2394575 A1 CA 2394575A1 CA 002394575 A CA002394575 A CA 002394575A CA 2394575 A CA2394575 A CA 2394575A CA 2394575 A1 CA2394575 A1 CA 2394575A1
- Authority
- CA
- Canada
- Prior art keywords
- price
- auction
- bid
- messages
- current price
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/08—Auctions
Landscapes
- Business, Economics & Management (AREA)
- Finance (AREA)
- Accounting & Taxation (AREA)
- Marketing (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Entrepreneurship & Innovation (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
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
WQ OOf36533 PCTIAU99I01118 $ AN AUCTION SYSTEM
The present invention relates to an auction system and. in particular, to a system for conducting a Dutch auction or a convcntivnal auction on a communications network such as the Internet.
A number of difFerent auction systems have beezt 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.eb3y.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 arc well suited to disposal of unique and expensive goods. such as real estate and automobiles. whereas butch auctions arc well suited for disposing of a large tturxaber of less expensive goods. particularly perishable items, such as food and flowers, which decline in value over time. Internet auctiozt systems also suffer from an inherent latency problem in communications over the Internet which use the Transmission Control protocolllniernet 30 protocol (TCP/IP). In addition to the communications overhead added by TCP
to the basic Internet protocol (IP), the auction systems use help transactions to send atsd 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 tiom being a true real-time auction where bids arc handled instantaneously by tl~ic auctioning pamr, thereby '?5 giving the auction excitement and life. The latency due to the communications overhead can also lead to disputes where one parry is in a location. which results izt its bids being received with some delay. whereas another parn 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 invcntivn there is provided an auction system including a server systezz~ for sending current price messages and for receiving bid messages. characterised in that said messages are transmitted using sin2le IP packets, wa oor3s533 pCTinu99ro> > > s The present invention also provides an auction system including a server system for sending current price messages and for receivinu bid messages. characterised in that said messages arc 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 tra;~smitting said messages using single IP packets.
The present invention also provides an auction method executed using a communications system. including sending cun:ent price messages from and receiving bid messages at a server system. characterised by transmittinc Said messages using the User Data protocol (UDP).
The present invention also provides an auction method executed by a communications system_ including' 1 ~ setting a current price for a predetetrnined 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 zztediutzt, Including:
a clock device for displaying a cutrettt price based on received current price messages:
and an auction display device for displaying data represeming the state of an auction based 35 on received bid reply messages.
t1 preferred embodiment of the prc5cnt invention is hereinafter described. by yvay of example only, with reference to the accompamring drawings, wherein:
Figure 1 is a block diagram of a preferred embodiment of an auction system:
Figure a is a diagCram of UDP packets used by the unction system;
Figure 3 is a flow diagram of a procedure executed by the auction system.
Figures 4 and ~ ace web pages generated by the auction system; and Figure 6 is a diagram of the auction system broadcasting a live auction.
Wl? OW3bS33 PCT/AU99101118 An auction system includes, as shown in Figure l, an auction server 2 which is a computer system that includes web serves software 4, and JavaTM code to run on a Java virtual rnachinc 6 of the server 2. The server 2 may be a standard Unix ar Microsoft NTT't machine and the web server software 4 may be either ApacheTM. Netscape Enterprise ServerT~
or Microsoft ~ :IXSTM ox Netscape Fasttrack ServerTM. The server 2 also includes a number of HTMT. and/or active server pages which are populated with data by the JavaTM cede 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 cornzr~unications z~etwork_ such. as the Internet. and the web browser 12 may be Netscape NavigatorTH or Microsoft Internet ExplorerT~. Bidding parties are able to use their client system 14 and web browser 1? to access and use the auction system established by the server 2. The I-fl'ML arid JavaTM code of the server
The present invention relates to an auction system and. in particular, to a system for conducting a Dutch auction or a convcntivnal auction on a communications network such as the Internet.
A number of difFerent auction systems have beezt 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.eb3y.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 arc well suited to disposal of unique and expensive goods. such as real estate and automobiles. whereas butch auctions arc well suited for disposing of a large tturxaber of less expensive goods. particularly perishable items, such as food and flowers, which decline in value over time. Internet auctiozt systems also suffer from an inherent latency problem in communications over the Internet which use the Transmission Control protocolllniernet 30 protocol (TCP/IP). In addition to the communications overhead added by TCP
to the basic Internet protocol (IP), the auction systems use help transactions to send atsd 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 tiom being a true real-time auction where bids arc handled instantaneously by tl~ic auctioning pamr, thereby '?5 giving the auction excitement and life. The latency due to the communications overhead can also lead to disputes where one parry is in a location. which results izt its bids being received with some delay. whereas another parn 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 invcntivn there is provided an auction system including a server systezz~ for sending current price messages and for receiving bid messages. characterised in that said messages are transmitted using sin2le IP packets, wa oor3s533 pCTinu99ro> > > s The present invention also provides an auction system including a server system for sending current price messages and for receivinu bid messages. characterised in that said messages arc 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 tra;~smitting said messages using single IP packets.
The present invention also provides an auction method executed using a communications system. including sending cun:ent price messages from and receiving bid messages at a server system. characterised by transmittinc Said messages using the User Data protocol (UDP).
The present invention also provides an auction method executed by a communications system_ including' 1 ~ setting a current price for a predetetrnined 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 zztediutzt, Including:
a clock device for displaying a cutrettt price based on received current price messages:
and an auction display device for displaying data represeming the state of an auction based 35 on received bid reply messages.
t1 preferred embodiment of the prc5cnt invention is hereinafter described. by yvay of example only, with reference to the accompamring drawings, wherein:
Figure 1 is a block diagram of a preferred embodiment of an auction system:
Figure a is a diagCram of UDP packets used by the unction system;
Figure 3 is a flow diagram of a procedure executed by the auction system.
Figures 4 and ~ ace web pages generated by the auction system; and Figure 6 is a diagram of the auction system broadcasting a live auction.
Wl? OW3bS33 PCT/AU99101118 An auction system includes, as shown in Figure l, an auction server 2 which is a computer system that includes web serves software 4, and JavaTM code to run on a Java virtual rnachinc 6 of the server 2. The server 2 may be a standard Unix ar Microsoft NTT't machine and the web server software 4 may be either ApacheTM. Netscape Enterprise ServerT~
or Microsoft ~ :IXSTM ox Netscape Fasttrack ServerTM. The server 2 also includes a number of HTMT. and/or active server pages which are populated with data by the JavaTM cede 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 cornzr~unications z~etwork_ such. as the Internet. and the web browser 12 may be Netscape NavigatorTH or Microsoft Internet ExplorerT~. Bidding parties are able to use their client system 14 and web browser 1? to access and use the auction system established by the server 2. The I-fl'ML arid JavaTM 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 browscr 12. as described below.
I S The auction server 2 executes code on the Java virtual machine 6 to generate pages which offer items for auction in lots. 'X'he client 14 is able to join the aucti.ozt 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 apples by a further http response t 6 which begins executing on a Java virtual machine 18 of the browser 1 ? of the 30 client 14. The apples establishes a user data protocol (UDP) port 20 vn the client's system 14 which. is able to coznmuzticare with a UDP port 22 of the server 2 established by a reciprocal Java pro~rax~s executing on the server 2. Like TCP, which is connmonly 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 ?5 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 izt the Internet RFC 768. which is herein incorporated by rofercnce.
30 The auction server 2 uses the UDP pore 22 to tnulticast offer or current puce r~o~essages 30. as shown in FiQUre 2. The message 30 is shown in Figure 2 as a UDP packet comprising 32 bytes with a header that includes s message digest field of 1b bytes and a message type field.
For transmission a UDP header and an IP header are also added to the packet 30. The data WO O~I36533 PCT/AU99I01118 payload contains fields representing the number ofthe current lot; a bid number indicating how many bids have becz made in the current auction, and a current price field which represents the eurrem price at which tkte goods of the lot arc being offered. The message rypc 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 retraining 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 serer ~. The web server 4 during a session with a client web browser 1? causes the browser 12 to request the generation of a unique session key. A key agreement protocol such as the Difi<ie-Heliman protocol is used to set up the session key. Alternatively the session key can be created by either the client ! 4 or the server 2 and exchanged using a public key cryptography technique. such as si~zned Java applets or the secure sockets layer (SSLI. 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. ih.e 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 recd to be encrypted, as it is available for all clients 14 connected to the server 2.
At each stage dining the auction, on receipt of the otter messages 30. a pam~
can use the client system 14 to send a bid message 3a which comprises a UDP packet of 44 bytes_ as shown in Figure 3. For transmission a UDP header and an IP header are also added to the packet 3z.
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.
? 5 The payload includes fields far the number of the bid. the lot number of the item for which the bid is placed_ the quantity or rxuznber of items associated with the bid. and the price fvr the bid.
The header of ZS bytes includes an encrypted message digest, a held indicating the type of message, and two additional Fetds for a number representing the bidding party or client and data representing the length of the payload before encryption.
Bid reply messages 34 arc also sent as UDP packets with a structure similar to that for the bid packets 32. as the reply massages 34 also have their payload encrypted for privacy. The reply nnessage 34 inforxr~.s the bidding party that the bid of the bid message 32. or another bid.
WQ 00/36533 PCT/AU99/0111$
_j_ has been accepted. The payload ofthe 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 ~1~.,. current lot and any other lots.
The use of the message format 30 and 33 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
I S The auction server 2 executes code on the Java virtual machine 6 to generate pages which offer items for auction in lots. 'X'he client 14 is able to join the aucti.ozt 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 apples by a further http response t 6 which begins executing on a Java virtual machine 18 of the browser 1 ? of the 30 client 14. The apples establishes a user data protocol (UDP) port 20 vn the client's system 14 which. is able to coznmuzticare with a UDP port 22 of the server 2 established by a reciprocal Java pro~rax~s executing on the server 2. Like TCP, which is connmonly 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 ?5 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 izt the Internet RFC 768. which is herein incorporated by rofercnce.
30 The auction server 2 uses the UDP pore 22 to tnulticast offer or current puce r~o~essages 30. as shown in FiQUre 2. The message 30 is shown in Figure 2 as a UDP packet comprising 32 bytes with a header that includes s message digest field of 1b bytes and a message type field.
For transmission a UDP header and an IP header are also added to the packet 30. The data WO O~I36533 PCT/AU99I01118 payload contains fields representing the number ofthe current lot; a bid number indicating how many bids have becz made in the current auction, and a current price field which represents the eurrem price at which tkte goods of the lot arc being offered. The message rypc 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 retraining 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 serer ~. The web server 4 during a session with a client web browser 1? causes the browser 12 to request the generation of a unique session key. A key agreement protocol such as the Difi<ie-Heliman protocol is used to set up the session key. Alternatively the session key can be created by either the client ! 4 or the server 2 and exchanged using a public key cryptography technique. such as si~zned Java applets or the secure sockets layer (SSLI. 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. ih.e 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 recd to be encrypted, as it is available for all clients 14 connected to the server 2.
At each stage dining the auction, on receipt of the otter messages 30. a pam~
can use the client system 14 to send a bid message 3a which comprises a UDP packet of 44 bytes_ as shown in Figure 3. For transmission a UDP header and an IP header are also added to the packet 3z.
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.
? 5 The payload includes fields far the number of the bid. the lot number of the item for which the bid is placed_ the quantity or rxuznber of items associated with the bid. and the price fvr the bid.
The header of ZS bytes includes an encrypted message digest, a held indicating the type of message, and two additional Fetds for a number representing the bidding party or client and data representing the length of the payload before encryption.
Bid reply messages 34 arc also sent as UDP packets with a structure similar to that for the bid packets 32. as the reply massages 34 also have their payload encrypted for privacy. The reply nnessage 34 inforxr~.s the bidding party that the bid of the bid message 32. or another bid.
WQ 00/36533 PCT/AU99/0111$
_j_ has been accepted. The payload ofthe 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 ~1~.,. current lot and any other lots.
The use of the message format 30 and 33 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
3? add minimal overhead to network layer 1P packets.
l0 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 ordar. or the sending system is informed of an error and retcansmissian occurs. To achieve this. TCP
insists on the reccivin~ system acknowlodgin~ 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 15 sending system t~esends packets if it does not receive an acknowledgement within a short period of time, and if ai3er several attempts the sending systezza 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 20 transmission from a sending system to a rcccivine system. To address this, the packets seat by the auction system that need to be ordered arc numbered. If a current price packet is missed or arrives out of order. time constraiutts for a real-time aucdon mean that rewansmission should not be undertaken and information should simply be obtalr~ed from tlae ztext curzent puce packet.
Accordingly the current price packets 30 are not numbered. bTowever it is important to ensure 25 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 arc not replied to. whereas the bid packets 32 are replied to. As the system is an auction system. any reply packets arc used to forward inforrnativn for the conduct of an auction. For instance, the bid reply messages 3~ arc sent as reply packets. The message 30 digest fields are added to the UDP packets to enable the ref ection of any corrupted or garbled packets. The system also adds features to the UDP packets which are trot provided by TCP and are advantageous for an auction system. Fvr exzruple. the message digest is encrypted with the secret session key providing an added level of protection over TCP.
Furthermore bid messages wQ oor36s3s >'crmt199roit is ~? are repeated immediately to ensure they are received in the minimum amount of time.
without waiting for a reply message, ns 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. 3? and 34 are particularly advantageous in delivering reat_time price, bid and acceptance information during a Dutch auction. Dutch auctions arc characterised by their fast pace and their ability to dispose of lots cozztprisiztg a large number of items in a shore period of time. and are particularly useful for disposing of perishable items I 0 which degrade in value over time. In a Dutch auction. the auctioning patty 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 amownt aztd resutxles the auction. The auction for a lot continues in this manner until the stock 1 ~ 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 arc met by the communication method described above.
?0 The auction system begins a Dutch auction for a lot by setting the current price at e~ stsrt price an,d a variable strikes to 0. as shown in Figure 3 at step 40. The auction server 2 accordingly generates a Dutch auction page 64, as shown in Figures 4 and 5.
which is sent to all clients I4 logged onto the server a for display by their browsers 12. The page 60 is a dynatxt.ic 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 an the Java virtual machine 18. The interface is updated continuously by messages sent fram 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 30 display a new current price offer as indicated by the messafze 30, at step
l0 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 ordar. or the sending system is informed of an error and retcansmissian occurs. To achieve this. TCP
insists on the reccivin~ system acknowlodgin~ 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 15 sending system t~esends packets if it does not receive an acknowledgement within a short period of time, and if ai3er several attempts the sending systezza 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 20 transmission from a sending system to a rcccivine system. To address this, the packets seat by the auction system that need to be ordered arc numbered. If a current price packet is missed or arrives out of order. time constraiutts for a real-time aucdon mean that rewansmission should not be undertaken and information should simply be obtalr~ed from tlae ztext curzent puce packet.
Accordingly the current price packets 30 are not numbered. bTowever it is important to ensure 25 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 arc not replied to. whereas the bid packets 32 are replied to. As the system is an auction system. any reply packets arc used to forward inforrnativn for the conduct of an auction. For instance, the bid reply messages 3~ arc sent as reply packets. The message 30 digest fields are added to the UDP packets to enable the ref ection of any corrupted or garbled packets. The system also adds features to the UDP packets which are trot provided by TCP and are advantageous for an auction system. Fvr exzruple. the message digest is encrypted with the secret session key providing an added level of protection over TCP.
Furthermore bid messages wQ oor36s3s >'crmt199roit is ~? are repeated immediately to ensure they are received in the minimum amount of time.
without waiting for a reply message, ns 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. 3? and 34 are particularly advantageous in delivering reat_time price, bid and acceptance information during a Dutch auction. Dutch auctions arc characterised by their fast pace and their ability to dispose of lots cozztprisiztg a large number of items in a shore period of time. and are particularly useful for disposing of perishable items I 0 which degrade in value over time. In a Dutch auction. the auctioning patty 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 amownt aztd resutxles the auction. The auction for a lot continues in this manner until the stock 1 ~ 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 arc met by the communication method described above.
?0 The auction system begins a Dutch auction for a lot by setting the current price at e~ stsrt price an,d a variable strikes to 0. as shown in Figure 3 at step 40. The auction server 2 accordingly generates a Dutch auction page 64, as shown in Figures 4 and 5.
which is sent to all clients I4 logged onto the server a for display by their browsers 12. The page 60 is a dynatxt.ic 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 an the Java virtual machine 18. The interface is updated continuously by messages sent fram 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 30 display a new current price offer as indicated by the messafze 30, at step
4~. The cuzreztt price is displayed and indicated by the hand 64 of the clock 62. The system 2 then waits for a prcdctcrtnined 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 WO 00136533 PCT/AU99I~1118 _7_ at step 48 that the current price has not yet been decremented to the reserve price for the Lot then step 4Z is executed again to decremera the current price by sending a further current price tnessaee 30. The price interval of step 4v. is Iznporcant as it allows all bids reccivred within chat interval to be treated as being equal in time or isochronous. This ensures the bid process is 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 at~d 34. 'fhe 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 50 to execute the sales based on the bid messages 3? received. Once the sales have been confirmed at step 50 by forwarding the reply znessagcs 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 1 ~ moves to the salt of another tot, 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 dctctmined 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 Multi.tlora at X67_ A units remaining display field 64 indicates that 160 units remain. within the price interval. two bids arc 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 ~ treats these bids as being isachronous.
and as Lhere is sufficient units or items Iefr in the lot. both of the bids can be accepted. as 35 displayed in the page of Figure 5. This is far more preferable than accepting the bid of ~.Ilied Flowers at $59 and then continuing the auction and hoping that .A,ctxre 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 30 units, as determined 3L StCp ~7. then a dctcrntinatioti 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 WO OI1/36533 PGT/AU99/t1111S
_g_ operation proceeds to step 55 where the strilcs variable is incrcmcnted. If it is determined at step ~7 that the strikes variable does not equal .i. i_e. this conflict situation has not occurred three times before making a sale, step 56 is executed to simply ittcremeztt the price and continue with chc auction. on the chance that one of the bidding parties may not repeat their conflicting S bid. This again enhances the speed of the auction.
if .however at step 57 it is determined that the strikes variable daes equal 3. three conflicts have occurred before rxlaking a sale. and step 59 is executed to distribute the remaining stock amongst the existing parries as equitably as possible_ The auction server 3 will send corresponding sale messages 34 at step SD. after executing at step S9. tl'te following decision steps:
(i) The number of units bid for each bid is reduced at least to the number of units ar goods on offer. This is done to dell with any bidd~r that rnay have sought an excessive number of the.goods. thereby distorting the distribution procedure.
1 S (ii) A total number of the items bid for is dctcrmined. referred to hereinaRer 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)/8idrotal.
(iv) For any units leftover, these are allocated randomly amongst the bidders with the ?0 probability of a bidder getting ~ 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 S units, yet there are only 10 units available on offer, the above distribution
notwithstanding the reduction in latency provided by use of the UDP packets 30, 32 at~d 34. 'fhe 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 50 to execute the sales based on the bid messages 3? received. Once the sales have been confirmed at step 50 by forwarding the reply znessagcs 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 1 ~ moves to the salt of another tot, 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 dctctmined 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 Multi.tlora at X67_ A units remaining display field 64 indicates that 160 units remain. within the price interval. two bids arc 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 ~ treats these bids as being isachronous.
and as Lhere is sufficient units or items Iefr in the lot. both of the bids can be accepted. as 35 displayed in the page of Figure 5. This is far more preferable than accepting the bid of ~.Ilied Flowers at $59 and then continuing the auction and hoping that .A,ctxre 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 30 units, as determined 3L StCp ~7. then a dctcrntinatioti 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 WO OI1/36533 PGT/AU99/t1111S
_g_ operation proceeds to step 55 where the strilcs variable is incrcmcnted. If it is determined at step ~7 that the strikes variable does not equal .i. i_e. this conflict situation has not occurred three times before making a sale, step 56 is executed to simply ittcremeztt the price and continue with chc auction. on the chance that one of the bidding parties may not repeat their conflicting S bid. This again enhances the speed of the auction.
if .however at step 57 it is determined that the strikes variable daes equal 3. three conflicts have occurred before rxlaking a sale. and step 59 is executed to distribute the remaining stock amongst the existing parries as equitably as possible_ The auction server 3 will send corresponding sale messages 34 at step SD. after executing at step S9. tl'te following decision steps:
(i) The number of units bid for each bid is reduced at least to the number of units ar goods on offer. This is done to dell with any bidd~r that rnay have sought an excessive number of the.goods. thereby distorting the distribution procedure.
1 S (ii) A total number of the items bid for is dctcrmined. referred to hereinaRer 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)/8idrotal.
(iv) For any units leftover, these are allocated randomly amongst the bidders with the ?0 probability of a bidder getting ~ 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 S units, yet there are only 10 units available on offer, the above distribution
5 procedure may begin with bidder A being assigned 3 uztitS. plus a 1/3 chance of obtaining a further unit. If A obtains the fmzher 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 aceting an extra unit. and C will receive whatever remains.
30 More precisely, the distribution procedure of step 59 c:cccutcs the following steps:
( 1 ) Consider the t~rst/ztext bidder.
(?) Assign the bidder an initial allocation of-Truncate ((Quantity bid for x Quantity available~Bidtotal).
WO 00/3b533 PCT/AU99/01118 (3) If there is a remainder from step (2), generate a random number bctwocn 0 and 1.
(~4) If the remainder is greater rhea the raztdotn number, the bidder is allocated 1 more unit.
The quantity allocated to the bidder is subtracted from the quantity available.
30 More precisely, the distribution procedure of step 59 c:cccutcs the following steps:
( 1 ) Consider the t~rst/ztext bidder.
(?) Assign the bidder an initial allocation of-Truncate ((Quantity bid for x Quantity available~Bidtotal).
WO 00/3b533 PCT/AU99/01118 (3) If there is a remainder from step (2), generate a random number bctwocn 0 and 1.
(~4) If the remainder is greater rhea the raztdotn number, the bidder is allocated 1 more unit.
The quantity allocated to the bidder is subtracted from the quantity available.
(6) The quantity bid for is subuacted from Bidtotal.
(7) If there arc further bids to be dealt with return to step ( 1 ).
Applying the above procedure, if there are. for e,camplc. three bidders A. B
and C and each has asked for 5 units. but d,ere are only 8 uztits on offer. each is allocated 2 units plus a chance to the remaining ? units. Bidder A is initially allocated 2 units plus a ?; 3 chance of obtaininc a further unit. If A does not obtain the extra unit. the remaining ~
units arc divided equally between B and C. However if A receives the extra unit them 8 is allocated 2 units and a 1 n chaztcc of obtainine an extra unit, ssnd C receives the remairsder after B has been dealt with.
1 S 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.c.
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 ii adopts a method ? 0 of comcnuniwtion and auction procedures which enhance the speed of auctions conducted by the system. The auction system is particularly useful irJ conducting a real-tirr~e Dutch auction over a eomtxxun.icatxons network, such as the Internet. which can be used co dispose of a large number of goods in a short period of tune.
25 The auction system can also be advantageously used to conduct a canventi.onal auction.
This simply involves adjusting the system described above to execute the following conventional auction steps:
(a) set the initial offer price to the startine price for the lot;
(b) send the current offer price for display:
30 (c) waiting a predetezxxtizted 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 intecvai, rhcn 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 eu~ent bid price to biddixxe parties. The current bid price is adjusted on the basis of the current price message 3U sent during step (b).
The architecture of the auction system can be c:ctcnded to cater for broadcast oFa live auction, as shown in Figuze 6. The live auction is conducted by an auctioneer 7? 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 7S also includes a computer program to transmit curncnt 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 ?0 communications network. such as the Internet 80. The server 3 instead of gcncraano the current price messages simply relays rl~ose received from the system 78. as the auction is controlled by the auctioneer ??, not the server ?..
The broadcaster 76 is able to use the prograril of the system 78 to submit status messages, in the same format as the bid messages ~2. advising on the status oFthe auction. such as "going once", °°goine twice" and "gone''. The program also conveys bid messages received at the auction server z from other parries to the broadcaster 76. so that the broadcaster can place those bids with the auctioneer 7Z. in accordance with the received messages 33. 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 ~.
The computer system 7s may be connected to the auction server ? using one or a combination of known comnclunication paths. and may also be incorporated into the auction WO 00/36533 PC~'IAU99/01118 -II-server 2.
Many modifications will be apparent to those skilled in the art vvithoue departing from the scope of the presexxt izwentiort as herein described with reference to the accompanying drawings.
Applying the above procedure, if there are. for e,camplc. three bidders A. B
and C and each has asked for 5 units. but d,ere are only 8 uztits on offer. each is allocated 2 units plus a chance to the remaining ? units. Bidder A is initially allocated 2 units plus a ?; 3 chance of obtaininc a further unit. If A does not obtain the extra unit. the remaining ~
units arc divided equally between B and C. However if A receives the extra unit them 8 is allocated 2 units and a 1 n chaztcc of obtainine an extra unit, ssnd C receives the remairsder after B has been dealt with.
1 S 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.c.
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 ii adopts a method ? 0 of comcnuniwtion and auction procedures which enhance the speed of auctions conducted by the system. The auction system is particularly useful irJ conducting a real-tirr~e Dutch auction over a eomtxxun.icatxons network, such as the Internet. which can be used co dispose of a large number of goods in a short period of tune.
25 The auction system can also be advantageously used to conduct a canventi.onal auction.
This simply involves adjusting the system described above to execute the following conventional auction steps:
(a) set the initial offer price to the startine price for the lot;
(b) send the current offer price for display:
30 (c) waiting a predetezxxtizted 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 intecvai, rhcn 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 eu~ent bid price to biddixxe parties. The current bid price is adjusted on the basis of the current price message 3U sent during step (b).
The architecture of the auction system can be c:ctcnded to cater for broadcast oFa live auction, as shown in Figuze 6. The live auction is conducted by an auctioneer 7? 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 7S also includes a computer program to transmit curncnt 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 ?0 communications network. such as the Internet 80. The server 3 instead of gcncraano the current price messages simply relays rl~ose received from the system 78. as the auction is controlled by the auctioneer ??, not the server ?..
The broadcaster 76 is able to use the prograril of the system 78 to submit status messages, in the same format as the bid messages ~2. advising on the status oFthe auction. such as "going once", °°goine twice" and "gone''. The program also conveys bid messages received at the auction server z from other parries to the broadcaster 76. so that the broadcaster can place those bids with the auctioneer 7Z. in accordance with the received messages 33. 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 ~.
The computer system 7s may be connected to the auction server ? using one or a combination of known comnclunication paths. and may also be incorporated into the auction WO 00/36533 PC~'IAU99/01118 -II-server 2.
Many modifications will be apparent to those skilled in the art vvithoue departing from the scope of the presexxt izwentiort as herein described with reference to the accompanying drawings.
Claims (32)
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.
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 hid messages are encrypted with the session key.
7. An suction 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.
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.
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 an auction display device for displaying data based on bid reply messages.
a clock device for displaying a current price based on said current price messages: and an auction display device for displaying data based on bid reply messages.
13. 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.
13. An auction system as claimed in claim 11. 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:
(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 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).
(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 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).
15. An auction system as claimed in claim 1 or 2. wherein said auction system 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;
(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;
(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 or the current price has reached a reserve price.
(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;
(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 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.
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).
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 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.
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:
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.
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.
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 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.
displaying with a clock device a current price based on said current price messages; and displaying data based on bid reply messages.
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 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;
(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 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).
(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 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;
(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 or the current price has reached a reserve price.
(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;
(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 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.
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 far displaying data based on received bid reply messages.
a clock device for displaying a current price based on received current price messages;
and an auction display device far displaying data based on received bid reply messages.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| AUPP7775A AUPP777598A0 (en) | 1998-12-17 | 1998-12-17 | An auction system |
| AUPP9534A AUPP953499A0 (en) | 1999-03-31 | 1999-03-31 | An auction system |
| AUPP9566A AUPP956699A0 (en) | 1999-04-01 | 1999-04-01 | An auction system |
| PCT/AU1999/001118 WO2000036533A1 (en) | 1998-12-17 | 1999-12-17 | An auction system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2394575A1 true CA2394575A1 (en) | 2000-06-22 |
Family
ID=27158127
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002394575A Abandoned CA2394575A1 (en) | 1998-12-17 | 1999-12-17 | An auction system |
Country Status (2)
| Country | Link |
|---|---|
| CA (1) | CA2394575A1 (en) |
| WO (1) | WO2000036533A1 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008000025A1 (en) * | 2006-06-26 | 2008-01-03 | Real Time Innovations Pty Ltd | Real-time sales system |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9595064B2 (en) | 2000-05-25 | 2017-03-14 | Xcira, Inc | Integration of remote bidders into multiple and simultaneous live auctions |
| US6813612B1 (en) | 2000-05-25 | 2004-11-02 | Nancy J. Rabenold | Remote bidding supplement for traditional live auctions |
| NL1016192C2 (en) * | 2000-09-15 | 2002-03-18 | Onroerendgoednet Com B V | Computerized auction system for houses and land, uses database on server with details of property, guide price and start data. |
| US10002385B2 (en) | 2003-10-28 | 2018-06-19 | Bgc Partners, Inc. | Managing the execution of trades between market makers |
| WO2005079131A1 (en) * | 2004-02-25 | 2005-09-01 | Jean-Guy Moya | Network auction system and method |
| US8200568B2 (en) | 2004-07-21 | 2012-06-12 | Bgc Partners, Inc. | System and method for managing trading orders received from market makers |
| NL1028112C2 (en) * | 2005-01-25 | 2005-07-12 | Pmm Hoff Holding Bv | Auction based electronic commerce system for goods and services, uses objectively measured product market potential to set product price |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5845265A (en) * | 1995-04-26 | 1998-12-01 | Mercexchange, L.L.C. | Consignment nodes |
| AU717594B2 (en) * | 1996-03-29 | 2000-03-30 | Ebay Inc. | Method and system for processing and transmitting electronic auction information |
| US5890138A (en) * | 1996-08-26 | 1999-03-30 | Bid.Com International Inc. | Computer auction system |
| DK10797A (en) * | 1997-01-30 | 1997-01-30 | Autocom Aps | Procedure for holding an auction, as well as uses of the method |
-
1999
- 1999-12-17 CA CA002394575A patent/CA2394575A1/en not_active Abandoned
- 1999-12-17 WO PCT/AU1999/001118 patent/WO2000036533A1/en active IP Right Grant
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008000025A1 (en) * | 2006-06-26 | 2008-01-03 | Real Time Innovations Pty Ltd | Real-time sales system |
| AU2007264399B2 (en) * | 2006-06-26 | 2011-07-07 | Real Time Innovations Pty Ltd | Real-time sales system |
| US8229792B2 (en) | 2006-06-26 | 2012-07-24 | Real Time Innovations Pty Ltd | Real-time sales system |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2000036533A1 (en) | 2000-06-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20210035216A1 (en) | Method and Apparatus For A Fair Exchange | |
| US7139792B1 (en) | Mechanism for locking client requests to a particular server | |
| US7685044B1 (en) | Low latency trading system | |
| US7848349B2 (en) | Distribution of data to multiple recipients | |
| EP2839426A2 (en) | A method and a computerized exchange system for processing trade orders | |
| CA2394575A1 (en) | An auction system | |
| AU779503B2 (en) | An auction system | |
| US6263001B1 (en) | Packet data communication protocol with reduced acknowledgements in a client/server computing system | |
| AU2012209443A1 (en) | Data feed without quantities | |
| US20060026241A1 (en) | System and method for bulk data messaging | |
| US20100082767A1 (en) | Distribution of data to multiple recipients | |
| GB2436982A (en) | Fair distribution of market views/quotations over a time multiplexed stock trading system | |
| CN1894714A (en) | Operating system and method for use in auction service based upon lowest bid price | |
| JP2001216460A (en) | Auction selling/buying system, control method therefor and recording medium with recorded control program therefor | |
| AU2018201412A1 (en) | Data feed without quantities | |
| Kempgen | JSE Derivatives Trading System API Equity and Commodity Derivatives, Global Market |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |