WO2010057253A1 - Online auction system - Google Patents

Abstract

The present invention relates to an online auction system for controlling a plurality of auctions in which bidders must pay to make a bid. An auction is won by a bidder if a predetermined number of bids were received in a predetermined bid accumulation period during the auction. The auction may be an all pay auction in which bidders must pay for bids. If the predetermined number of bids is (1) then that bidder is the winner, otherwise if the number is greater than (1) a winner may be randomly selected or there may be multiple winners. The auctions may be divided into sets of identical auctions and bidders may be allocated to different auctions in a set of auctions. Bidders may be reallocated to different equivalent auctions in the set of auctions as bids are received or at the end of the predetermined period. A reporting period may follow the end of the predetermined bid accumulation period. Bidders could participate in multiple auctions for monetary amounts in which case the auctions may be a form of entertainment. In another aspect a sale price update function may be used to determine the sale price. In this case the seller determines the sequence of offered sale prices rather than the bidders. This allows the sale price to be decreased as bids are received, or allows the seller to control the trend of the offered prices. In all pay auctions bidders additional revenue can be generated from bids thus allowing the offered sale price to be much lower than a retail price.

Description

ONLINE AUCTION SYSTEM PRIORITY DOCUMENTS

The present application claims priority from Australian Provisional Patent Application No. 2008906013 entitled "Online Auction System" and filed on 20 November 2009. The content of this application is hereby incorporated by reference in its entirety.

FIELD OF THE INVENTION

The present invention relates to online auction systems.

BACKGROUND OF THE INVENTION

Auctions provide buyers and sellers with an opportunity to take place in a dynamic and sometimes exciting sales experience. Buyers may participate in an auction in an attempt to obtain a lower price than the typical or expected retail price. Sellers on the other hand wish to achieve the highest possible price and it is desirable to have a pool of potential buyers who will compete against each other in order to drive up the price. For the sake of clarity the term seller will be used to collectively refer to the seller or an agent of the seller such an auctioneer, or computer servers under the control of the seller, auctioneer, auction house or other organisation facilitating an auction on behalf of one or more sellers.

A range of different types of auctions are used, such as the English auction, Dutch auction, and all pay auctions. In English auctions (open ascending price auction), a seller opens up bidding to bidders who nominate prices (bids) they are prepared to pay for the item to be auctioned. This bidding process continues until no further bids are made with a certain time period at which point the last bidder wins the auction and purchases the item from the seller for the amount they offered. In such an auction the price is effectively controlled by the bidders, although the seller may set a reserve price, which the minimum price the item will be sold for. In a Dutch auction the seller gradually drops the sale price down from an upper starting price, with the item going to the first bidder to accept an offered sale price. In an all pay auction each bidder must pay an amount (bid cost price) for the right to lodge a bid to buy the (eg there is a bid cost associated), and this extra income can be used to lowering the reserve price for an item.

The growth of the internet has allowed the development of online auction systems. Online systems enable distributed buyers and sellers to take part in an auction for items, and the speed of computer servers, ability to multitask, and always on capability allow for considerably flexibility in conducting auctions compared to traditional auctions conducted by a human seller, not to mention the ability to run multiple simultaneous or overlapping auctions. The various time and cost efficiencies that an online setting provides enables some seller to do away with a physical shopfront front, thus enabling an item to be offered at a reduced price. Alternatively online auctions provide an existing retailer who has a shopfront access to customers outside their immediate geographical area, which may enable them to lower the profit per item due to increased sales that result. Buyer's can also browse or search for an item at their convenience and obtain items from remote locations. The buyer can also choose how much they are willing to pay for an item, and can review this as the auction progresses, which can provide a source of entertainment to the user, especially as the auction moves towards the conclusion.

Whilst online auctions provide many benefits to buyers and sellers compared to traditional auctions, the online nature can also lead to some problems. With auctions having a predefined end time, "bid sniping" can occur in which a bid sniper delays bidding in an auction until the last few moments before the end of the auction. Thus a bidder who may have the current winning bid up until the 30 seconds prior to the auction end may be outbid in the last few seconds and have insufficient time to respond with a counter bid. In some cases the use of automated bidders can lead to prices quickly rising. Also many online auctions are little more than simple variants of traditional auctions, and typically the savings between the achieved sale price and the nominal retail price is comparatively small, especially when buyers factor in shipping costs.

There is thus a need to develop an online auction system which addresses some of these problems, or provides an alternative to existing online systems.

SUMMARY OF THE INVENTION

According to a first aspect of the present invention there is provided a method for conducting an auction, the method comprising: offering one or more remote bidders the opportunity to purchase an item at an offered sale price by making one or more bids during at least one predetermined bid accumulation period, wherein the offered sale price is constant for each predetermined bid accumulation period; and accumulating the number of bids received during one of the at least one bid accumulation period during the auction, wherein if the number of bids received is equal to a predetermined number of bids associated with the bid accumulation period, then one or more of the bidders whose bids were received during the bid accumulation period win the auction and may purchase the item at the offered sale price.

According to a second aspect of the present invention there is provided a method for conducting a plurality of auctions, the method comprising: initialising a plurality of auctions comprising dividing the plurality of auctions into a plurality of auction sets wherein each auction in an auction set is for an identical item and for each auction a start time, an end time, an initial offered sale price, a bid cost price, at least one bid accumulation period and associated predetermined number of bids for winning the auction is associated with the auction; allocating a plurality of bidders to the plurality of all pay auctions; conducting the plurality of auctions wherein each auction is conducted according to the method of the first aspect of the invention.

According to a third aspect of the present invention, there is provided a computer program product, comprising a computer usable medium having a computer readable program code embodied therein, said computer readable program code adapted to be executed to implement a method according to the first or second aspect of the present invention.

According to a fourth aspect of the present invention, there is provided a computer server for use in an online auction system used by a plurality of remote bidders, the computer server comprising: a) an auction control module for controlling an auction for an item at an offered sale price; c) a communications interface for providing auction information to a remote bidder on the at least one auction associated with the remote bidder, and for receiving bids from the remote bidders; and d) a bid window accumulator for accumulating bids received during at least one predetermined bid accumulation period during the auction, wherein if a predetermined number of bids are received during the predetermined bid accumulation period, then the auction is won by the bidder or bidders whose bids were received during the predetermined time period, and the offered sale price is constant for each predetermined bid accumulation period

According to a fourth aspect of the present invention, there is provided a computer server for use in an online auction system used by one or more bidders in communication with the computer server for auctioning one or more items, the computer server comprising: a) a processor for simultaneously controlling one or more auctions; b) a storage device for storing one or more initialisation characteristics of one or more auctions comprising a sale price for an item or service for each auction; c) a communications interface for receiving one or more bids from one or more bidders associated with a respective auction initialised from the initialization characteristics stored on the storage device; d) a bid discriminator for discriminating bids comprising simultaneously received bids for each auction; e) a bid incidence accumulator to accumulate a total of bids for each auction; f) a sale price updater associated with each auction for updating the sale price for a respective auction according to a price update function wherein the price update function uses at least the accumulated bid incidence for a respective auction to update the sale price to a higher, lower or the same sale price; and g) a bid charge transaction module for charging a bid cost price for each received bid.

According to a fifth aspect of the present invention, there is provided a method for conducting a one or more all pay online auctions, the method comprising: initialising one or more all pay online auctions comprising associating a bid cost price, a sale price and auction end triggers with each of the one or more all pay online auctions; receiving one or more bids from one or more bidders associated with one of the one or more all pay online auctions and charging each bidder a bid cost price for submitting a bid; accumulating the total of bids received for each auction; determining whether to end the auction based upon triggering of an auction end trigger; and updating the sale price for each auction according to a price update function wherein the price update function uses at least the accumulated total number of bids received for each auction to update the sale price to a higher, lower or the same sale price.

According to a sixth aspect of the present invention, there is provided computer program product, comprising a computer usable medium having a computer readable program code embodied therein, said computer readable program code adapted to be executed to implement a method according to the fifth aspect of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS Illustrative embodiments of the present invention will be discussed with reference to the accompanying drawings wherein:

FIGURE 1 is a an online auction system according to an embodiment of the invention;

FIGURE 2A is a graph of the output of a price update function according to an embodiment of the invention; FIGURE 2B is a graph of the output of a price update function according to an embodiment of the invention;

FIGURE 2C is a graph of the output of a price update function according to an embodiment of the invention;

FIGURE 2D is a graph of the output of a price update function according to an embodiment of the invention; FIGURE 3 is a timeline of an auction according to an embodiment of the invention;

FIGURE 4 is a flowchart of an online auction system according to an embodiment of the invention;

FIGURE 5 is a flowchart of bid processing performed in Figure 7 according to an embodiment of the invention; FIGURE 6 is a timeline of an auction according to an embodiment of the invention;

FIGURE 8A is a representation of a client device of a participant in an online auction according to an embodiment of the invention;

FIGURE 8B is a representation of a display on a client device according to an embodiment of the invention; FIGURE 8C is a representation of a display on a client device according to an embodiment of the invention;

FIGURE 8D is a representation of a display on a client device according to an embodiment of the invention;

FIGURE 9 is a representation of a display on a client device according to an embodiment of the invention; and

FIGURE 10 is a display of bids received in a bid accumulation time period according to an embodiment of the invention.

In the following description, like reference characters designate like or corresponding parts or components.

DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS OF THE INVENTION

Referring now to Figure 1, there is shown an online auction system 100 according to an embodiment of the invention. A computer server 110 communicates with client devices 130, 140, and 150 associated with bidders (or potential bidders logged into, or visiting the site) using communication links 122, 124, 126 and 128 over a network such as the internet 120. A seller (not shown) may also communicate with the server over a network such as internet to provide information to the server 1 10 regarding an item or service to be auctioned by the computer server. For the sake of clarity, seller and computer server will be used interchangeably.

The computer server 110 is used to control a one or more auctions for items. These may be for goods, services, or even monetary amounts in which case the auctions may be a form of entertainment to bidders. The item could also be a tender, in which case the winner wins the tender. Auctions may be simultaneous with some auctions run in parallel having identical start and end times, or some auctions may be overlapping in time and thus only be simultaneous for a part of each auction. Multiple identical copies of items may be available for sale and thus there may be simultaneous auctions running for identical items. These could be entirely parallel (same start and end times) or run independently. Auctions may be linked so that a when an auction ends, a new auction for an identical item starts some (typically short) time later. Similarly auctions may be linked so that related goods (eg a TV and DVD player) are simultaneously offered.

In one view an auction could be broken down into a set of sub auctions or rounds in which there may be some chance of the auction being ended by an auction end trigger. Each sub auction is for a fixed duration and if there is no auction end trigger then the next sub auction starts, possibly after a brief reporting phase, for the same item at an updated sale price. In some cases when an auction end trigger is received, the auction may be allowed to continue using an equivalent item. In the case there are multiple equivalent items for sale, multiple auctions could be run in parallel, and at the end of each sub auction, bidders could be reallocated to different simultaneous sub auctions. This may be done in the background by the server so that to the bidder the auction would appear as one continuous auction.

The number of auctions in progress at any one time may be varied based upon the number of users or bidders participating in an auction or logged into the server. For example a server with 100 users may offer 25 auctions, and if a further 25 user's login, then the number of auctions may be increased to 30. The choice of the order of auctions, or items auctioned may be randomly selected from an available pool, or the pool of auctions may be subdivided into classes or sets and chosen so as to maintain a predetermined spread of auctions. For example classification could be based on the retail sale price of items. For example there could be 15 auctions for goods valued at under $100 and 10 auctions for goods over $100 (eg a predetermined number). This may be varied based upon time of day in a relevant market, demographic information regarding a target market or other information.

The computer server 110 includes a processor and associated memory (RAM, ROM, etc) 111 , a communications interface 112 and a storage device (hard disks, solid state drives, DVD, etc) 113. The server may include a number of components or modules which may be provided as software instructions, hardware or a combination of the two. The server may be in the form of a distributed system featuring networked multiple processors and associated databases spread over multiple sites in which the various components are distributed but communicatively coupled to enable the desired functionality to be achieved. In the embodiment shown in Figure 1 the server includes software modules for controlling one or more auctions stored as computer instructions, or executable code on a storage device 113. The software modules are executed by the processor 111 and may interact with other components of the server such as the communications interface 112. These software modules may be used to control various elements of online auctions and may include an auction selector module 114, a bid incidence accumulator 115, a sale price updater 116, a bid charge transaction module 117, a bid selector 118 and an auction end determiner 119.

The communications interface 112 enables the server to communicate with client devices 130, 140, and 150 such as over the internet 120. Communication links may be wired or wireless links, and data may be transferred using standard protocols and applications such as TCP/IP, HTTP/HTTPS, SSL, SSH etc. Typically during an auction the communications interface receives incoming data (e.g. bids) or data requests (e.g. a request for information on a particular auction) from client devices, and prepares data (e.g. auction update information) which may be sent to client devices. The server may push the data out to clients, or it may act in response to a request from a client device. The communications interface may also include a bid discriminator module for assigning a time to an incoming or received bid and for discriminating the order bids are received in. The bid discriminator may also assign a unique identifier so that it may be associated with a bidder and auction. The discriminator may place the bids in a list associated with an auction, and the list may be ordered. In the case of simultaneously received bids, the order could be randomly assigned or assigned based on past bidding history. The server is thus able to rapidly respond to multiple incoming bids including simultaneous received bids whilst controlling a multiple auctions.

The storage device 113 may be used to store software modules instructions for controlling online auctions. The storage device 113 may also store metadata associated with each auction or item. This metadata may an item description, retail sale price and auction initialisation characteristics such as may be include a reserve price for an item, minimum and maximum sale prices, the type of auction, the sale price update function to be used (discussed below) the time the auction is to begin, a default auction end time and/or a list of possible triggers and triggering criteria that maybe used to terminate an auction such as a threshold number of bids received. For example when an auction is initialised the appropriate events and event handling routines could be registered based upon the metadata associated with the auction. Storage device 113 may also be used to store outcomes of auctions, manage billing and user information (eg login credentials), and track user participation and other marketing information. The storage device 113 may be internal or external to the server and contained in one or more databases. When a bid is received information on the bidder may be associated with the bid, such as a username and account, along with information relating to the auction, such as item and the sale price current at the time the bid was made or associated with the bid.

The server may include an auction selector 114 for selecting a subset (eg 1, 2, 5 10, all) of the plurality of auctions to be associated with a remote bidder, or which a remote bidder may be offered the chance to participate in. The server may include a bid incidence accumulator 115 to accumulate or count the total number of bids for each auction. This may be used to count the total number of bids received during predetermined time periods or over the entire auction.

The server may also include a sale price updater 116 which may be associated with one or more auctions. In this case the sale price is controlled by the server (and thus the seller) rather than by the bidders as is the case in traditional auctions. Accordingly the offered sale price may increase, decrease or even maintain the current price from bid to bid. The sale price updater may update the sale price according to a price update function and may update the sale price on the basis of the accumulated bid incidence. This may be performed to provide a sale price that will encourage bidders to bid in the respective auction and increase the overall number of bids. A sale price update function may be used for the entire auction, or different functions to be used at different stages. Stages could be characterised on the basis of the total number of bids received in the auction.

In some but not necessarily all embodiments the online auctions will be all pay auctions in which bidders are charged a bid cost price (bidding fee) for making a bid and thus the computer server may include a bid charge transaction module 117 for charging a bid cost price for each received bid. The bid price could be a small amount such as $1 to provide a low barrier to participation. Lower (eg Ic, 5c, 10c) or higher (eg $10, $20, $100) could be charged as deemed appropriate by the seller and could be based upon value of the item. All pay auctions allows the seller to generate revenue and so offer the item at a price substantially below the retail price, which may serve as an incentive to potential bidders. The bid cost price may be fixed for the duration of the auction or may be allowed to vary as the auction proceeds, for example decreasing as more bids are received. This could be done regardless of the bidder, or applied on a per bidder basis. In another embodiment the bid cost could increase with the number of bids made in order to drive the auction to an end point. In another embodiment the bid cost price could vary as a function of the number of bids made, with bid cost price increasing and decreasing within the same auction. In another embodiment the bid cost price may be fixed for the duration of the auction which facilitates pre-selling of bids for use in an auction. Such pre-sold bids or credits could be encoded with an identifier or receipt so that upon reception the authenticity of the alleged pre-sold bid can be verified, such as by the discriminator or by some other verification module included or communicatively coupled to the online auction system. In another embodiment, part of the bid cost price of each bid may be put in a pool and used towards a discount off the sale price of the item or service or as a cash prize to the winning bidder. In such a case if there are sufficient bids the winner may both receive the item at no cost and also receive an additional cash prize. For example if 50c of each $1 bid is placed in a pool, and 100 bids are made for a item that has a sale price of $30, then the winning bidder receives the item as well as $20 (100*0.5 - 30 = 20).

Bidders could pre-buy bids (credits) to be used in auctions, or an account could be debited as bids are received. In all pay auctions the bid incidence accumulator 115 can be used to determine if the auction has made a profit, and can be used to control or influence the sale price offered to bidders or when to terminate the auction.

Various price update functions may be used. The price update function may update the sale price between a predetermined minimum sale price and a predetermined maximum sale price. This may be randomly determined between these limits or allowed to vary in some other way. The price update function may have the property that as the accumulated number of bids increases, a robust average of the previous sale prices approaches a predetermined minimum or maximum sale price. Thus a very low sale price could initially be offered to encourage bidding and then increased towards a maximum sale price or alternatively the initial sale price may be higher and then gradually decrease toward a minimum sale price.

Figure 2A shows a price update function 210 in which sale prices are randomly chosen between defined minimum and maximum sale prices of $0 and $100 respectively.

Figure 2B shows a price update function 220 in which the price update function has the property that as the accumulated number of bids increases, a robust average (i.e. one insensitive to outliers such as the median or a trimmed mean) of the previous sale prices increases towards a predetermined maximum sale price (that is trends towards this value). Thus a very low sale price could initially be offered to encourage bidding and then increased towards a maximum sale price. In Figure 2B a set of 30 consecutive sale prices were chosen using a function based upon price = min(l .5*bid number + 10, 50) + random(-5,5). The first part of the function uses a linear increase which is then capped at $50 (the predetermined maximum sale price). Variability is added through the addition of a random number selected in the range -5 to 5.

Another price update function is a function having a sale price vs bid number curve which has a dip portion (global minimum) or possibly several dip (local minimum) portions. Figure 2C shows an example of one such price update function 230 in which a set of 30 consecutive sale prices were chosen using a function based upon price = 0.5*(bid number -1 1)² + 10 + random(-5,5) until the minimum at bid 11. For bids in excess of 12 the function used was price = min(0.5*(bid number -H)² + 10, 35) + random(-5,5), which allows an increase up from the minimum until a threshold of $35 at which point the price randomly fluctuates. As can be seen in Figure 2C the sale price initially keeps dropping to act as an incentive for bidders to participate. The sale price is then allowed to rise slightly to a predefined threshold which is typically (but not necessarily) well below the retail sale price. The dip or global minimum encourages participation of bidders. The location of the minimum may be chosen at a point where the sale price plus number of bids is equal to a reserve price. After that point the price may settles on a threshold value (which is still low) until the auction is ended or possibly increase to drive the auction to an end point.

Figure 2D shows a price update function 240 in which the price update function has the property that as the accumulated number of bids increases, a robust average or the median of the previous sale prices decreases towards a predetermined minimum sale price. In Figure 2D a set of 30 consecutive sale prices were chosen using a function based upon price = MAX(90 - (A132-l)*(A132-l)/5,10) + random(-5,5). As can be seen in Figure 2D the sale price initially keeps dropping towards $10 where it then fluctuates. Thus bidders are provided an incentive to bid, as this drives the price down towards some low threshold which may be substantially below the retail sale price. Bidders may keep bidding around this low price, although a given bidder is unlikely to make an excessive number of bids as this will offset the savings made with respect to the retail sale price. Such an auction system enables the seller to ensure that an effective minimum reserve price, defined as the sale price plus the number of bids times the bid cost price, is maintained.

Examples 2B to 2D used a random number selected in the range (-5,5) which was added to each price. The magnitude of this variation could be allowed to change over time, such as modulation by a sinusoid or other modulation function. It is also to be understood that the price update function need not include a random component. Randomness provides variability to the price update function but it is to be understood that other functions could be used to produce variation in the price update function, for example using one or more sinusoids, polynomials or other functions.

The sale price update function may allow prices to decline as the number of bids increases. Declining prices may provide an incentive to bidders to bid, thus increasing the number of bids. In order to obtain a threshold number of bids, a local or global minimum may be located near this threshold.

Similarly the general shape of the price update function may be chosen encourage or provide incentive for at least a threshold number of bids to be made. After this threshold, the price update function may be allowed to increase so as to move the auction towards an end phase. The end phase may be characterised by a predefined bid accumulation period wherein if a predefined number of bids a received during this period the auction is ended. Alternatively the end phase may be characterised by a period in which the probability of an auction end offer being made to a bidder is increased (or increases with), or the probability that a bid triggers a random bid end trigger is increased (or increases with time), or the sale price update function increasing the price towards a maximum or the retail sale price so that bidders are less likely to continue to lodge further bids.

Sale prices for an auction could be determined prior to the start of the auction and stored in an array of lookup data as metadata associated with the auction. This would also facilitate providing a list of future sale prices to bidders (via the communications interface).

In one embodiment, the sale price may be updated in response to every bid received. In such an embodiment the sale price current at the time the bid was made, and the sale price current at the time the bid is received and/or processed may be different. Thus bidders may not necessarily be aware of the price which will be associated with their bid as other bidders bids may be received prior to theirs, leading to changes in the offered sale price. In one embodiment a predetermined number of future sale prices could be provided to bidders, so that they have information on a likely sale price or sale prices that may be associated with their bid.

In another embodiment, when a sale price is updated, an identifier could be associated with the offer and the offer provided to potential bidders. If the bidders chose to accept the offer and make a bid, the identifier such as current sale price, could be associated with the bid at the time the bid is sent. When bids are received the bid discriminator could group all the bids associated with a particular offer and select one of these bids to be the preferred bid. This could for example be the earliest bid received in the group, or perhaps the bid associated with a frequent bidder, or a bid with a higher bid cost price. The bids not selected as the preferred bid could then be discarded. The selection of one of the bids may trigger a sale price update by the sale price updater and this process could then be repeated.

The sale price updater may be used in an all pay auction to update the sale price in response to an increase in the accumulated number of bids in an auction. That is as the total number of bids increases during the auction, the sale price may be adjusted by the server on the basis of the revenue raised. Bidders are effectively charged a participation fee which increases with the amount of bids made (i.e. with their participation). In contrast to conventional auctions, the bid does not determine what the new price will be, rather a bid is offer by a bidder to purchase the item at the offered sale price which the server conditionally accepts. This bid is referred to as the preferred bid. The server then determines a new price that bidders may then make a subsequent bid to obtain the item. In the case that multiple bids are received for an item at and offered sale price, a bid selector 118 may be used for selecting a preferred bid from the list of bids associated with an auction such that when the auction is ended the preferred bid is made the winning bid. In some embodiments no price update function is used, and instead bidders may nominate the price they wish to purchase the item for (as in a conventional English auction).

The server may include an auction end determiner 119 for determining when to end each auction and for controlling the end of the auction. At the end of the auction the preferred bid in the auction is selected as the winning bid. The auction end determiner may end an auction after expiration of a predetermined time period since the start of the auction. The auction determiner ends may also end an auction when the accumulated number of bids in the auction exceeds a predetermined threshold or when some other secret reserve threshold (e.g. time, revenue, etc) is exceeded. The auction end determiner could also use the communications interface to send an auction end bid offer to a selected bidder and upon reception of the accepted auction end bid offer from the selected bidder, the bid is selected as the preferred bid and the auction end determiner ends the auction. In this case selection of the bidder to make the auction end bid offer to may be based upon the total number of bids made by each bidder during the auction.

In another embodiment of the invention if a bid is received within a predetermined end time period before the current end time of the auction, the auction end determiner extends the end time by a predetermined auction extension time period. The predetermined end time period and the predetermined auction extension time period may be of the same length, such as 20 seconds. The extension time period may begin from the time the extending bid is received or from the previous auction end time. For example if the predetermined end period was 20 seconds and the bid extension period was 20 seconds and a bid was received with 17 seconds remaining, the new auction end time could be 17+20 = 37 seconds from the time the bid was received (20 seconds after the previous end time), or alternatively another 20 seconds after the bid was received (3 seconds after the previous auction end time). Alternatively rather than a predefined extension period being used the period could be dynamically calculated such as by dividing the bid extension period into several time windows and using the window within which the bid was received as the basis for the auction extension time. The communications interface may be used to notify the bidder that caused such an extension, and indicate that they are the currently preferred bidder. The bidder may be further updated during the extension period as to whether any further bids have been received during the extension period.

Figure 3 illustrates the extension of the auction end time 300. The auction is started at 310 and a first bid 312 is received. Several more bids are received, including two simultaneously received bids 314 which the discriminator randomly orders. As each bid is received the discriminator uniquely identifies the bid and assigns to the auction. Each bid is then accumulated (counted). The auction end time is designated 340, and a predetermined auction extension time period is indicated by dashed box 320. Bid 330 is received within the predetermined auction extension time period. This bid is selected as the preferred bid, and this selection forces extension of the auction end time for a predetermined auction extension time period starting at the time the bid is received 322 and ending at a new auction end time 342. Alternatively the extension could have started from the previous auction end time 340. A subsequent bid 332 is received after the previous auction end time 340 but before the current auction end time 342 (that is within auction extension time period). This bid is then selected and forces a further extension of the auction end time by the auction extension period 324 to a new auction end time 346. As no further bids are received during this period the auction is ended and the bid 332 (the preferred bid) is made the winning bid.

In another embodiment of the invention the auction end determiner may also include a post auction handler. The post auction handler may offer the bidder of the winning bid the opportunity to sell back the item or service at a predetermined sale price, such as the retail sale price. Thus the bidder could make a profit from participation which provides added incentive to participate. This option may be offered to the winning bidder irrespective of the sale price or the total number of bids, or such an offer may be conditional on a sale price or a threshold number of bids being received in the auction. The existence of a sell back offer may be an inbuilt part of the auction and bidders may be informed that such an option is guaranteed of as part of participation in the auction. Alternatively it may be made available during the auction or at the end of the auction as a form of a bonus. In one example this could be implemented once the value of bids made (that is the total number of bids times the bid cost price) exceeds the retail sale price or reserve price of the server/seller. The post auction handler may also provide other functionality, such as notifying successful bidders, handling payments and shipping of goods.

In one embodiment the sell back option could be combined with the use of a bid cost price in a conventional auction. This could be implemented in the current frame work using a sale price updater that uses a sale price that is associated with the bid that is provided by the bidder (eg the bid discriminator could extract the bidders nominated sale price in the bid message and this would be associated with the bid). Alternatively a sale price updater could be used which incrementally increases or decreases the sale price when a bid is received or accumulated. In such a case the bid increment could be a fixed amount such as 50c, $1, $5, $10 etc for each $1 bid made. The amount could be fixed based upon factors such as the value of the goods, a retail sale price, reserve price, the initial price, and whether the increment is positive or negative. For example a positive increment could be used when increasing from a low initial price or negative increment (decrement) could be used when decreasing from a high initial price. Alternatively this combination of features could be used along with a sale price updater which uses a sale price updater function under the control of the seller that allows the sale price to increase, decrease or stay the same with each bid as described above.

In further aspect the auction end module uses the communications interface to send an offer to sell equivalent items or services to the auctioned item or service to one or more selected bidders who have made one or more bids in the auction. The one or more selected bidders could be a predetermined number of the bidders, such as 3, whose bids were most recently received before the end of the auction. The price at which the equivalent item or service is offered may be the price the winning bidder paid, or it may instead be the price associated with the selected bidders. In another embodiment the selected bidders could be bidders who had preferred bids during the auction, or had made a threshold number of bids during the auction or some other participation criteria, such as participation in other auctions.

The auction end point could be based upon the retail sale price or monetary amount (entertainment auctions). For a low value items there may be a high probability of the auction ending after relatively few bids whereas for a higher value items there may be a low probability of the auction ending after few bids, with the probability increasing with the number of bids. For example an auction could be configured to sell a monetary amount of $10, a bid cost price of $1, a random sale price between $1 and $5, with the auction ended automatically after receiving the 12^th bid. Alternatively the probability of the auction ending in the first 10 bids could be zero, with it increasing in by 0.1 with each bid after the 10^th thus ending the auction on or by the 20^th bid. Such an auction will thus generate a profit for the seller, as well as a likely profit for winning bidder. This could be varied from a monetary amount of $500 by using a random sale price between $10 and $50, an initial low probability (0) of ending the auction which increases once 490 bids have been received. Additionally the auction could be ended automatically after the 550* bid.

To further assist with understanding the invention, a flowchart of an online auction process 400 according to an embodiment of the invention is illustrated in Figure 4 and will now be described. The auction is first initialised 410 using metadata associated with the auction and may include details of the item for auction, the initial sale price, the bid cost price, auction start time and nominal auction length. An event handler for handling sale price update triggers or events and an event handler for handling auction end triggers or events may also be initialised. Information on one or more sale price update functions to be used by the sale price updater during the auction may also be stored along with details on when different functions are to be used. A range of sale price update triggers, or events may be used during the auction to force an update of the sale price, such as the when a preferred bid is selected, the expiration of predetermined time period after a preferred bid is selected, the expiration of one or more predetermined time periods since the start of the auction, etc. A range of auction end event triggers or event may be used during the auction to end the auction. This may include expiration of a predetermined time period, a predetermined number of bids being made, a predetermined value of bids being made, expiration of a random time period, or an auction end bid. Typically the sale price update and auction end event triggers to be used will be registered at the start of the auction. Additional triggers may be registered during the auction, such as in response to another triggering event such as a threshold number of bids received. In another alternative embodiment no triggers may be registered during initialisation and one or more triggers may be registered as the auction proceeds.

At step 420 the main event processing loop is started following initialisation of the auction. The processor performs a test to determine if one or more bids have been received by the communications interface. If yes 422 then the bid discriminator uniquely identifies the bids and determines the order of the bids and places the received bids in a list 424 and returns control back to the point 426 if there were no more bid received. At 430 the processor performs a test to determine if there are any bids to process in the received bids list 430. If yes 532 then one or more bids in the received bids list are processed. This is described in more detail in Figure 5 which is discussed below.

If there are no bids to process, or one or more bids have been processed 434, then the processor performs a test to determine if there are any auction end events 440. For example these events may be generated due to an auction end timer expiring or an auction end bid being received. If yes 442 then the auction is ended 444. Typically the preferred bidder will be selected as the winner and further auction end processing may then be performed such as by a post auction handler which may notify the winning bidder and facilitate payment and transfer of goods.

If no auction end events have been generated, then the processor next tests if there are any sale price update events 450. This may be due to a bid being selected as the preferred bid, or the expiration of a timer since such a bid was selected. If yes 452 then the sale price updated updates the sale price 454. If no such events have occurred, or the sale price has been updated, 456 then a test is performed if there are any auction update requests received that need to be processed 460. If yes 462 then an auction status update is prepared and sent via the communications interface 464. If there were no requests or the requests have been, or are being processed, 466, then control goes to back to the start of the loop 468. This process continues until the auction is ended at step 454. Figure 5 illustrates a flowchart of bid processing according to an embodiment of the invention. Bid processing proceeds by first checking 510 whether bids are to be processed individually, or in groups of bids. If bids are to be processed individually 512, then a bid from the received bids list is selected to be the preferred bid, with the rest of the bids left in the list for later processing 520. In one embodiment this list may be in the form of time ordered queue as determined by the bid discriminator, with the ordering based on the time a bid was received at the server, or possibly the time the bid was made by the bidder provided that the bids include such information and the times can be verified, and the bid that is selected is the first bid in the time ordered queue.

A bid accumulator is then incremented and the bidder charged a bid cost price for making the bid 522. In alternative embodiments, charging the bid cost price may be performed upon reception of the bid, or in the case of prepaid bids may take the form of verification of the authenticity of the prepaid bid.

If received bids are not to be processed individually then a group of bids are selected and the rest of the bids are left in the list 530. Next a bid accumulator is incremented and each bidder is charged a bid cost price 532. Next a bid is selected from the group and the preferred bid and the remaining bids are discarded 534. This selection may be random or based upon past bidding history.

When the auction ends, the preferred bid becomes the winning bid. A sale price is thus associated with the preferred bid 540, and should the preferred bid become the winning bid then this associated sale price is the price the bidder will be required to pay for the item or service. The sale price that is associated with the preferred bid may be the sale price that was current at the time the bid was made, the sale price current at the time the bid was received, or may be the sale price current at the time the bid is selected as the preferred bid. A sale price update event is also triggered 550. Next a check is made if the auction end time is to be extended 560. If yes 562 then the auction is extended by a predetermined amount, such as 20 seconds 564. Control then moves to 566 where it returns to Figure 4 and step 426.

In another embodiment of the invention, a bid window accumulator is used which accumulates bids received in at least one predetermined bid accumulation time period during the auction (including the entire length of the auction). If a predetermined number of bids (the winning accumulated bid amount) are received during a predetermined bid accumulation period associated with the auction, then the auction is won by the bidder or bidders whose bids were received during the predetermined time period (that is their bid may be selected as the preferred and winning bid). The bid accumulation time period is predetermined prior to the start of the accumulation period. Preferably this is a fixed time period but a random time period between defined limits could also be used, or some other predetermined function for determining the time period prior to the start of the time period. A bid accumulation time period may be the entire duration of the auction or some fraction of the total period, and there may be multiple periods during an auction. There could be no limit on the number of bids which may be received during a bid accumulation period. A predetermined bid reporting period then begins for reporting the results to each bidder. At the end of the predetermined bid accumulation time period, or during the bid reporting period bidding may be closed (and any further received bids are discarded and not charged).

The bid reporting period could simply be a report or an indication as to whether or not a bidder was the winner or it could be used to display the number of bids received in the predetermined bid accumulation time period. The bid accumulation and bid reporting periods (phases, or stages, windows etc) may be further subdivided into a plurality of time slices (or slots, periods, windows etc) for bid reporting purposes. Preferably these are adjoining non overlapping time slices, but in some embodiments they could be overlapping. They need be of the same duration (that is of non-uniform length or duration). There may be a 1 : 1 correspondence between time slices in the bid accumulation period and time slices in the bid reporting period and a time slice in the bid reporting period may be used to report the number of bids received during the corresponding bid accumulation time slice. The order of the reporting time slices may be different from the order of the bid accumulation slices. This may add randomness and generate additional excitement for the winning bidder as they must wait until the end of the bid reporting period to find out if they are the winning bidder. If they are not the winner they may then be shown the new offered sale price and given the chance to continue in the auction. Optionally if only one bid was received during the predetermined bid accumulation time then the auction may be ended without starting a predetermined bid reporting period (and reporting the bids).

The bid accumulation period may occur at any time during an auction, or may be cover the entire duration of the auction, in which case if the predetermined number of bids was received then there may be no winner for the auction. The bid window accumulator may be included in the auction end determiner or may be a stand alone component. Multiple bid accumulation periods (and associated bid reporting periods) may be used within a single auction, and the auction may be a progressive sequence of bid accumulation and reporting periods. A sale price update function may be used to update the sale price from round to round (of bid accumulation), so that the offered sale price of the item is constant over the bid accumulation period or each bid could be an offer to purchase the item at a price nominated by the bidder.

If predefined number of bidders for ending the auction (i.e. the winning accumulated bid amount) is more than one, but there is only to be one winner, the single winner may be declared based on random selection or some predetermined criteria such as the order the bid was received (eg first, fifth, last, etc). Alternatively only some the bidders may be declared as winners (for example the even received bids). Alternatively all the bidders in a bid accumulation window may be made joint winning bidders if the number of bids is equal to the predefined number or in a predefined range. For example if there are between 5 and 10 bidders in a bid accumulation period then all such bidders are winners, but if there are less than 5, or more than 10, the auction continues. In the case of multiple winners, the winners would preferably receive duplicate or equivalent items or services rather than having to divide up the auctioned item or service.

In one embodiment if only one bid is received during the predetermined bid accumulation time period, the auction is ended and the received bid is selected as the preferred and winning bid. Otherwise the sale price updater associated with the auction updates the sale price and repeats the bid accumulation process for another predetermined bid accumulation time period. If two or more bids were accumulated during the predetermined bid accumulation time period then the bid window accumulator may use the communications interface to send a message to the two or more bidders wherein the message includes the total number of bids received during the predetermined bid accumulation time period.

Figure 6 illustrates an embodiment of the invention 600 in which there is a sequence of bid accumulation periods, all of which having requiring one bid to be received in order to end the auction (that is the predetermined number of bids is one for each accumulation period). In this embodiment bid accumulation periods follow directly after each other (e.g. predetermined bid accumulation time period could be 1 minute), and there is no exclusive bid reporting period following a bid accumulation period. An auction begins 600 and a first bid accumulation time period 620 begins. Bids 622, 624, and 626 are received during the accumulation window. As more than two bids were received, another bid accumulation time period 630 begins after the previous time period 620. The sale price may be updated for the new time period. Two bids 632 and 634 may be received in this time window. Again, two or more bids was received another bid accumulation time period 640 begins after the previous time period 630. In this bid accumulation window, no bids are received. However the auction is not ended and another bid another bid accumulation time period 640. One further bid 652 is received in the bid accumulation period 650 which begins after the end of the previous bid accumulation period 640. As only one bid was received the auction is ended with bid 652 selected as the winning bid.

In one embodiment the server is configured to offer a plurality of auctions in which if there is a predetermined number of bids (eg 1) in a predetermined bid accumulation time period (1 minute). The predetermined bid accumulation time period could be the entire length of the auction, at the end of the auction, or some period during the middle. There could be multiple such periods, interspersed with reporting periods, or general bidding. Multiple auctions could be synchronised so that they each run simultaneously for the same length of time equal to the predefined time window (eg 1 minute), and a series of sequential sets of auctions could be performed. Thus if the predetermined number of bids is received during the auction, a winner is declared in that auction, otherwise there is no winner. Either an equivalent item (in the case of a winner), or the same item is then re-offered in the next auction in the series. The item could be offered at the same or another sale price (such as one selected using a sale price updating function). Thus to the bidder there may appear to be several continuous auctions running.

The plurality of auctions may further be divided into a plurality of auction sets in which each auction in a set is for an identical item. Alternatively auction sets could be for related goods (eg TV, DVD players, set top boxes etc) with metadata indicating the relevant class for an item. The individual auctions in an auction set may run simultaneously and the server may use an auction selector module to allocate a bidder to a specific auction in an auction set. This could be performed randomly, or each auction could be assigned a weighting factor in order to influence the number of bidders participating in a particular auction. For example there may 5 simultaneous auctions in a set and 100 bidders to be allocated. The weightings applied to each auction in a set could be 0.02, 0.245, 0.245, 0.245 and 0.245 so that on average there are 2 bidders in the first auction, and 24 or 25 bidders in auctions 2 through 5. If the number of bidders increases to 125, an additional auction could be added with the weights being 0.02 for the first auction, and 0.196 for auctions 2 through 6. This preserves the number of bidders in the auctions so on average there are 2 bidders in the first auction, and 24 or 25 bidders in auctions 2 through 6. Other formulas or probabilistic based approaches could be used to obtain a certain distribution of bidders over the auctions, or to provide each bidder with a certain chance of winning an auction (either over all auctions or an auction in set of auctions).

Lodging a bid could trigger reallocation of the bidder to a different auction in the set by the auction selector. If the auctions are in a set are of identical duration, for identical items and at identical prices, then such a change may in fact be invisible to the bidder. Allocation of bidders to auctions in an auction set could be performed at the common start or end of each auction or bid accumulation period. Alternatively a bidder could monitor the current sale price of an item in an auction (unaware there are actually multiple simultaneous auctions) but only be allocated to a specific auction in a set of auctions when the bid is received.

Bidders may chose to participate in multiple simultaneous auctions, and could choose the sets of auctions they are interested in bidding in. This could be for related items, or they may choose to participate in entertainment auctions where the items are monetary amounts (eg $5, $50, $100 and $500 auctions). For example in the case of 100 bidders there could be 20 simultaneous auctions divided into 4 sets of 5 auctions with the 4 sets being for monetary values of $5, $50, $100 and $500. The auction selector may randomly assigned bidders to auctions, or selection or reallocation of bidders may be performed to minimise the likelihood that a remote bidder is allocated to the same plurality of auctions that another remote bidder is allocated to. This could be achieved by randomly selecting a set of auctions and then checking if the same set of auction has already been assigned to another bidder. If so, one auction could be selected and replaced with a new random auction and further checking performed to determine if the set of auction is unique. Automatic selection by the server also has benefits to bidders, as it frees them up from the manual task of browsing and selecting auctions to participate in and they can indicate auctions of interest in the knowledge that they are unlikely to be directly competing against another bidder in all of their auctions.

The total number of auctions and the distribution of different sets of auctions may be selected or varied based upon the number of bidders logged into the server (i.e. load balancing). For example as the number of bidders logged on increases the total number of auctions may be increased. This may be performed by progressing adding an additional auction to each auction set so that the number of bidders in any one auction remains below some threshold number. As the number of bidders logged on drops, auctions that are won may not be replaced with identical auctions, or the auction end module may vary the criteria for selecting a winner, such as by randomly choosing a winner, selecting the last bidder at a predetermined time or increasing the predetermined number of bids required in the predetermined window.

To further assist with understanding the invention, a flowchart of an online auction process according to an embodiment of the invention 700 is illustrated in Figure 7 and will now be described. This process may be performed for a plurality of sets of auctions, each set having a plurality of identical auctions.

Auctions are first initialised 710 using metadata associated with each auction. This may include determining the number of auctions from a set of auctions to be simultaneously offered and may be based upon the number of bidders logged in, as well as details of the item for auction, the initial sale price, the bid cost price, and duration of bid accumulation period. Various event handlers may also be initialised as required.

At step 720 the auction selector allocates bidders an auction in the set of auctions available. At step

730 the bid accumulator accumulates bids in each auction for a predetermined time period. At step 730 the number of bids received and accumulated in each auctions is compared the predetermined number of bids associated with that auction. If they are not equal the process continues 748 otherwise if they are equal (Yes) 742 then that auction is ended 744 and the bidder (or bidders) may proceed to purchase the item. A replacement item from the set of items is then substituted and a replacement auction is initialised 746. The process then continues at 748 wherein each auction enters a bid reporting phase in which the results of bids made by bidders during the previous bid accumulation period is reported to bidders 750. Next a further check is made if the total number of bidders has changed 760. If no 766 the process continues. If the number did change (Yes) 762 then the number of simultaneous auctions may be varied (increased or decreased) 764. This may include ending one or more auctions. The process then continues 766. If there are still ongoing auctions then the process if repeated for a further bid accumulation period 768.

This process could be further varied by swapping steps 720 and 730 so that allocation is made after bids are received, or they could be performed simultaneous with allocation occurring as bids are received during the bid accumulation period.

Table 1 below describes an auction according to an embodiment of the invention. A set of auctions comprises auctions for 5 lots of an item (1.1 through 1.5). Four 4 simultaneous auctions are initiated at a starting bid price of $20 and using an increasing sale price update function in which the price rises by $1. The auctions are broken down into a series of bid accumulation phases (Ni through N₅), effectively sub auctions, with each bid accumulation phase followed by a bid reporting phase (Ri through R₅). Bidders are allocated to one of 4 auctions, with each row in Table corresponding to an auction. In the first bid accumulation period, 40 bidders are received, with 10 bidders allocated to each auction. In the second bid accumulation period, bidders were reallocated to the 4 auctions, with only 1 bidder being allocated to the second auction for item 1.2. This bidder wins this auction and item 1.2 is replaced with item 1.5 and the second auction then continues as before. An alternate view is that a fifth auction is initiated to replace the second auction, using the current parameters associated with auctions 1, 3 and 4. In the third bid accumulation period, bidders were allocated or reallocated to the 4 auctions (the same bidders do not have to keep participating in an auction and old bidders could be replaced by new bidders). No winners are declared in the third reporting phase. The fourth bid accumulation phase then occurs, but in this case only 30 bidders participated. The server detects this change in the total number of bidders and decides to terminate the fourth auction. A winner is randomly selected from the 4 bidders that bid during the fourth bid accumulation phase of the fourth auction. No replacement item is substituted so that in the firth bid accumulation phase only three simultaneous auctions are conducted. Table 1

The auction system can be used for entertainment purposes. For example auctions could be for monetary amounts, and multiple auctions could be offered for different amounts such as $5, $50, $100 and $500. Auction sets could be created based on the monetary amount. The duration of an auction, or likelihood of winning could be linked to the price value, such as through the frequency of the server offering an auction ending bid (i.e. offered more frequently for low value auctions). Similarly auctions using a random price update function, or with various end of auction criteria such as random end time can be utilised. A bidder could thus participate in multiple auctions, each for a different auction set ($5, $50, $100 and $500) with the auction selector selecting which auction in each auction set to allocate the bidder to. For example with 4 auction sets, each with 5 auctions, a bidder could be allocated to auctions 1.2, 2.1, 3.1, and 4.5. Another bidder could be allocated to a different set, such as 1.1, 2.1, 3.3, and 4.2.

In auctions in which an auction is won if a predetermined number of bids is received in a predetermined bid accumulation period, a sale price update function may be used which takes into account the number of bids received at different times in the overall bid accumulation time period (which may be different to the predetermined bid accumulation period). The price direction (up or down) may be based upon the number of bids, or the time the bids were received. For example the bid accumulation period may be broken down into 4 distinct periods. If the most bids were received in periods 1 or 3 the price goes up and if the most bids were received in periods 2 or 4 the price goes down. Further the magnitude of the movement may depend upon the number of bids received in total, or in one of the periods. For example if a large number of bids are received the price may change by a large amount and if only a few bids are received the price may change by only a small amount.

In one embodiment a plurality of "one bid auctions" could be offered, in which the duration of the auction is the bid accumulation period, and an auction is only won if there was one bid made in the auction. There is no winner if there are any more or any less than this number. The number of such auctions run simultaneously could be determined based upon the number of bidders logged in and bidders allocated in order to follow a desired odds profile or ensues bidders each have a certain chance or likelihood of winning. This could be performed using random allocation with appropriate weightings allocated to each simultaneous auction.

The auction system may also provide time of bid based bonuses. Bidders might receive bonuses if their bid is received in a particular order or position relative to other bids. Bonuses could be awarded to the bidder who is the first to bid within the first 20 seconds, or if they are the last, or middle position, 6th or possibly if their bid is the one received with the most time space away from the time other bids are received. Bidders could also be granted quantity of bids based bonuses which may provide incentive for bids in which few bidders are participating. The bonus could be in the form of a monetary bonus, a refund, a future discount, eligibility for a future auction or some other offer. The offering of a bonus could also be factored into the price update function.

Some auctions could be offered only after bidders have qualified to enter. This might be through the number of bids, or having won an earlier auction, such as within a certain time period (eg last 5 minutes). In one embodiment a winning bidder could be offered the chance to participate in a special auction in place of the receiving the goods. This may be used in the case that a winning bidder is offered the chance to sell back the item or service, or the item was a monetary value which the bidder obtained at a bid price less than the monetary value of the item. For example the item could be $25, with the auction sale price being $12 and winning bidder making 3 $1 bids. This winning bidder could elect to give up the $10 profit, and instead take part in an auction for $100 or $500.

In one embodiment, bidders may be able to bid multiple bids, all at the same sale price during a bid accumulation phase. In this embodiment the winner of the auction may be based on a predetermined number of bids being received from a single bidder. In another variant if a bidder lodges multiple bids, then they may be declared the winner if the predetermined number is less than or equal to the total number of bids lodged by the bidder. E.g. if the predetermined number N is 3, and the bidder lodged 5 bids, they may still qualify to win the auction. In another embodiment a bidder may win multiple times for each multiple of the predetermined number of bids. E.g. if the predetermined number N is i, and the bidder lodged 5 bids, they may win 5 times. To facilitate these embodiments the bidder's display may include a "Bid X 5" (or other number) option or button.

Auctions need not be all pay auctions in which bidders must purchase bids for a bid cost price. Whilst this model provides one way of funding the auction system, this is not the only model, and features such as the use of bid accumulation periods, bid reporting periods and sale price update functions could be used in other types of auctions. For example instead of charging a bid cost price per bid, bidders could be charged an auction entry fee or a subscription fee. Different levels of subscription could allow access to different value auctions. Alternatively revenue could be raised by other means such as advertising on the website, commissions from sellers based on the item sale price, or through setting the reserve prices of auctions a certain profit margin above the seller's cost price for the item.

Turning now to the bidder or client side, Figure 8A is a representation of a client device 800 of a bidder (participant) in an all pay online auction according to an embodiment of the invention. The client device may include a processor 814, a memory 812, a storage device 816, a communications interface 818 and a display 820. The communications interface can communicate 819 with the computer server 110. The processor may execute instructions for displaying information from the server, as well as sending requests to the server. Information displayed may be displayed in a browser window or in the window of a client application such as an application written in an appropriate programming language and which may be provided via the computer server 110.

The display 820 includes a display of the item 822, the currently offered sale price 824 of $50 and the time left in the auction 826. A bid actuator in the form of a bidding button 830 may be clicked to allow the user to make a bid. The cost of making a bid is indicated 832 as is the total number of bids made in the auction 834, with the number of bids made by this bidder placed in brackets. The next 5 prices that that the item will be offered is also shown 840. If a user clicks the bid button, then the bid is send to the computer server for processing. Other information to identify the user, and allow the bidder to be charged is also provided to the server. The client device may request regular updates on the status of the auction (such as changes to the sale price) from the server, or the server may provide this to the client on its own initiative.

Figure 8B represents an alternative display 850 in which the bidder has been offered the opportunity to make an auction ending bid. The bidding button 830 has been replaced with a special bidding actuator (in this case a button) which is displayed as item 852. If the bidder actuates (clicks) the button then an auction end bid is sent to the server for processing which upon reception will lead to selection of the bid as the winning bid. Figure 8C represents an alternative display 860 when the auction is counting down the final 80 seconds. The time is replaced with two question marks 868. The remaining 20 seconds is divided into 5 time periods, each of 4 seconds which are represented by symbols 862, 864, 866 in the display. Each symbol is associated with one of the time periods and each symbol displayed in either a neutral state, a pending stated or an expired state depending upon whether the current time is before the start of the associated time period, during the associated time period, or after the end of the associated time period. In Figure 8C, the current time period is designated by the star 864, the previous time period by the square 862 and the remaining time periods by grey circles 866.

Figure 8D represents an update of the display following reception of a bid. Another symbol 872 is then placed over the top of the star 864 to designate that a bid was made and that the time period has now been extended and a further bid may be made.

The order of the symbols could be randomised, and the symbol corresponding to the current time period could be animated such as by spinning or flashing. Such displays could be provided to all bidders, or just the bidder who has the preferred bid at the start of the predefined time period (or bid accumulation period) before the end of the auction, or by a subsequent bidder who becomes the preferred bidder and triggers an auction end time extension.

According to another embodiment of the invention a display 820 could be used to display multiple auctions 900 as illustrated in Figure 9. Figure 9 displays 4 auctions 910, 920, 930, 940, each for items of different value. The client device may display a multiple bid option 950 which if selected sends a bid to all displayed auctions (or all auctions the bidder is participating in).

The client device may also display a new auction selector which is associated with one of the plurality of auctions displayed on the client device. Similarly an all new auction selected could be provided in order to replace all currently displayed auctions. The request could be for an auction or auctions for identical goods, or criteria regarding the type or category for each auction could be specified. The auction selector module will receive this request and allocate the bidder to one or more auctions, and the display of client device will be updated. As discussed above, in one embodiment a bidder may be assigned to a new auction or auctions each time a bid is made.

In one embodiment, each time a bid is made the bidder may be assigned to a new set of auctions. In some embodiments, the status could be reported prior to displaying the new set of auctions or the screen could be divided into two sections, one showing the current auctions the bidder can bid in, and the other reporting status of recent bids made. The status could be in the form of a simple report indicating whether they are currently the preferred or winning bidder. Alternatively a countdown type display as illustrated in Figures 8C and 8D could be provided for each auction to build the excitement.

The display of the results to a bidder on the bidder's client device could be performed by splitting the predetermined window into a plurality of time periods. These can be equal lengths, or each period of the plurality could be a different length to at least one other period in the plurality and would typically be non overlapping. A symbol could be associated with each of the plurality of time periods. Each of the symbols could be displayed in an initial state, and the state displayed subsequently changed into a reporting state to reflect the results of the bid accumulation period. This could be the number of bids or a yes/no type indicator to indicate if they are the winner. The order of the change of display into a reporting state could be in the time order of the associated time period being represented by the symbol or in a random order.

There are multiple ways the symbols could be randomized. One possibility is that the symbols are laid out left to right according to the chronological time period they reflect. The change in state is randomized so that the order of change of state is not necessarily left to right but done in a random fashion. Another possibility is that the change of state is done across the screen from left to right in order however the order of the symbols is randomized so that they do not necessarily represent the sections of the bid accumulation period in chronological order from left to right. Thus the left most symbol might not represent the earliest section of the bid accumulation period and so on. Alternatively the change in state of the symbols may all be displayed at once. If the change of state/revealing of the number of bids is done progressively in time, the time at which a symbol is displayed in the bid reporting state may correspond to the time period the symbol is associated with. For example if the bid reporting period was 10 seconds and the bid accumulation period was 100 seconds, the bids made in each 10 second portion of the bid accumulation period may be revealed in each 1 second portion of the bid reporting period.

The randomization of the symbols may be done after each round to give a new randomized order each time. The bidder may or may not be displayed the information about which symbol represents which time period. Alternatively the symbols do not change state but when they appear initially they are in a state reflecting the bids received during the bid accumulation period. The randomization may be random, pseudo random, sampled from a specific distribution, or varied using a formula designed to achieve higher entertainment value for the bidder or other desired effects. In other possible embodiments other display layouts such as right to left, up to down, around a circle and the like may be used. The state that the symbols change into might reflect the number of bids received during the corresponding segment. This might be a display of the actual number of bids received, or a more general indicator. For example a different symbol could be used for greater than 4 bids as opposed to 2 bids. Alternatively only the symbol representing the first bid received from another bidder is changed into the state reflecting that another bid has been received. This would be for entertainment value, and could increase bidder suspense in some situations. It would increase likelihood that the user would be displayed a closer result to what would be displayed in the event of winning the auction.

In one embodiment where the results of multiple auctions are being displayed simultaneously the order of the auctions is also randomized before the results are displayed. In this embodiment the actual auction that each of the sets of symbols represent is hidden from the user until each of the symbols has changed state.

Figure 10 is a display of bids received in a bid accumulation time period 1000 on the display 820 of a client device according to an embodiment of the invention. In this embodiment the first predetermined window is 10 seconds and the second predetermined bid reporting period is also 10 seconds. The first predetermined window is split into 5 consecutive 2 second windows. In this example 1 bid was made in the first 2 seconds, 4 bids in the next two, 2 in the next two, and 0 in the next two seconds and 1 in the last two seconds of the 10 second period. At the start of the bid reporting period 1070 the symbols are displayed as stars 1020, 1030, 1040, 1050 and 1060 and are displayed in an initially spinning state. The client display 820 also indicates the current sale price for the bid accumulation period that has just ended and a message is displayed that bidding is now closed 1010. Then in the middle of each of the corresponding associated time period (that is at Is, 3s, 5s, 7s, and 9s) each star is progressively displayed in a static (non spinning) state with a number inside corresponding to the number of bids which in this case is 1, 4, 2, 0, and 1. The display order is randomised so that window numbers 4, 1, 5, 2, 3 are displayed left to right and the bids are revealed in window number order (1 through 5) so that the bidder will not know which symbol will be the next to be displayed in the static state. At 1 second into the bid reporting period 1072 window number 1, which is second from the left, displays that 1 bid 1032 was received in first two seconds of the bid accumulation period. Then at 3 seconds into the bid reporting period 1074 window number 2, which is second from the right, displays that 4 bids 1052 were received in next two seconds of the bid accumulation period. Then at 5 seconds into the bid reporting period 1076 window number 3, which is on the right, displays that 2 bids 1062 were received in next two seconds of the bid accumulation period. This process continues for the next two periods revealing the second star from the left then the middle star with 0 and 1 bids respectively. In other embodiments the display spatial order may be time ordered, randomised or otherwise varied from the time order.

The bid reporting period may be split so that the time slices are of different lengths. They may represent scaled portions of the bid accumulation period. If there are many bids received, having some time-slices relate to a shorter period of time than other slices would increase the chances of the display period showing symbols relating to no bids received (the display symbols indicating to the user that they are successfully on track to win).

The various components and modules, and steps in flowcharts may be provided by software, hardware or a combination of the two. For a hardware implementation, components modules and interfaces may be implemented within one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof. For a software implementation, the techniques described herein may be implemented with modules (e. g., procedures, functions, and so on) that perform the functions described herein. The software or program code may be stored as instructions in a memory unit and executed by a processor. The memory unit may be implemented within the processor or external to the processor, in which case it can be communicatively coupled to the processor via various means as is known in the art. The invention may also be provided as a computer program product comprising a computer usable medium having computer readable program code embodied within. The server and client applications may be written in any appropriate programming language such as C, C++, C#, JAVA, JavaScript, PHP, .NET framework, and may interface with databases using SQL queries or other appropriate database languages or protocols.

The invention advantageously provides a new highly configurable online auction system that utilises the technological capabilities of a computer server to enable conducting a wide range of simultaneous or overlapping auctions to distributed bidders. The server is able to respond to bidders much faster than a conventional seller. In some embodiments the auction may be ended if a predetermined number of bids are received during a predetermined bid accumulation period. This could be a predetermined time during an auction, or at period prior to a predefined or expected end time. The auction extended if the number of bids received was different from the predetermined amount. In some embodiments the server controls how the sale price changes with new bids enabling the sale price to be decreased during the auction, allowed to random vary, follow a predefined trend, and/or made to stay within a predefined range. This is significantly different from a convention auction in which a reserve price is set, but control of the sale price is handed over to bidders and in which it always increases.

An additional feature is that bidders may be charged a bid cost price for making a bid. This aspect can be used to compensate for decreasing bid prices allowing the seller to set a low reserve price or otherwise cover the cost of the item as it is spread over the bidders taking part, rather than being borne by the single winning bidder in a traditional auction. To encourage participation a proportion of the bid cost price may be added to a pool which may be provided to the winning bidder or the winner may be offered the option to sell back the item to the seller. This may encourage more speculative bidding or allow the winning bidder to make a profit from participating. To further stimulate participation future bid prices may be shown so that bidders can make a more informed choice in the knowledge that if they unsuccessful they will have future chances to obtain the item or service at a low sale price. Adding features include offering a special auction ending bid to a bidder. This could be randomly offered after a certain time point or once a threshold number of bids or revenue has been exceeded, or assigned to the bidder who has made the most bids at a certain point in time. This provides incentive to participate with knowledge that the auction will not continue indefinitely.

A server can be configured to run multiple simultaneous auctions wherein each individual auction is highly configurable and thus two auctions for the same items can be run quite differently. Some auctions may be provided purely for entertainment purposes. Such auctions tend to have more randomness in the price update function, or include bonuses, random end triggers etc, and the auctioned item could be a monetary amount. For a low value monetary amount there may be a high probability of the auction ending after relatively few bids whereas for a higher value monetary amount their may be a low probability of the auction ending after few bids, with the probability increasing with the number of bids.

The display of the results of the auctions may also be controlled or configured for increasing the excitement and entertainment of bidders. Symbols may be associated with a one or more time periods before the end of the auction or at the end of a bid accumulation period and the symbols may be displayed in various states representing the number of bids received in the associated time period. These may be progressively displayed in randomised order to bidders on display devices so as to provide added entertainment or build the excitement.

Throughout the specification and the claims that follow, unless the context requires otherwise, the words "comprise" and "include" and variations such as "comprising" and "including" will be understood to imply the inclusion of a stated integer or group of integers, but not the exclusion of any other integer or group of integers. Also the reference to any prior art in this specification is not, and should not be taken as, an acknowledgement of any form of suggestion that such prior art forms part of the common general knowledge of the person skilled in the art.

It will be appreciated by those skilled in the art that the invention is not restricted in its use to the particular application described. Neither is the present invention restricted in its preferred embodiment with regard to the particular elements and/or features described or depicted herein. It will be appreciated that the invention is not limited to the embodiment or embodiments disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the scope of the invention as set forth and defined by the following claims.

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS

1. A method for conducting an auction, the method comprising: offering one or more remote bidders the opportunity to purchase an item at an offered sale price by making one or more bids during at least one predetermined bid accumulation period, wherein the offered sale price is constant for each predetermined bid accumulation period; and accumulating the number of bids received during one of the at least one bid accumulation period during the auction, wherein if the number of bids received is equal to a predetermined number of bids associated with the bid accumulation period, then one or more of the bidders whose bids were received during the bid accumulation period win the auction and may purchase the item at the offered sale price.

2. A method as claimed in claim 1, further comprising: reporting the results of a bid accumulation period to the remote bidders who lodged bids during the bid accumulation period.

3. A method as claimed in claim 1 or 2 wherein the auction is an all pay auction in which each bidder must pay a bid cost price to lodge a bid to buy an item at the offered sale price.

4. A method as claimed in claim 2 or 3, wherein the results are reported during a bid reporting period associated with and after a bid accumulation period during which no further bids are accepted.

5. A method as claimed in claim 4, wherein the auction proceeds as a series of bidding and reporting rounds, each round comprising a bid accumulation period followed by a bid reporting period.

6. A method as claimed in any one of claims 2 to 5 wherein a predetermined bid accumulation period is split into a plurality of time periods, and the number of bids received in each of these time periods is reported to each bidder that sent a bid during the predetermined bid accumulation period.

7. A method as claimed in claim 6, wherein each time period is represented by a symbol for display on a display device associated with the bidder and the symbols are progressively replaced with the number of bids received in the time period associated with the symbol.

8. A method as claimed in claim 7 wherein the order of the symbols is not the time order of the plurality of time periods.

9. A method as claimed in any preceding claim, wherein if remote bidder wins an auction they are provided with the option of selling the item back to the seller at the offered sale price.

10. A method as claimed in any preceding claim, further comprising: accumulating the total number of bids received during the auction; and updating the sale price after the end of a predetermined bid accumulation period if there was no winner, wherein the offered sale price is updated by a sale price updater according to a price update function wherein the price update function uses at least the accumulated bid incidence for a respective auction to update the sale price to a higher, lower or the same sale price.

11. A method for conducting a plurality of auctions, the method comprising: initialising a plurality of auctions comprising dividing the plurality of auctions into a plurality of auction sets wherein each auction in an auction set is for an identical item and for each auction a start time, an end time, an initial offered sale price, a bid cost price, at least one bid accumulation period and associated predetermined number of bids for winning the auction is associated with the auction; allocating a plurality of bidders to the plurality of all pay auctions; conducting the plurality of auctions wherein each auction is conducted according to the method of any one of claims 1 to 10.

12. A method as claimed in claim 11 wherein at least two auctions in each auction set are initialised to be conducted simultaneously with identical start and end times and are configured so that they are indistinguishable to a bidder.

13. A method as claimed in claim 12 wherein the number of simultaneously conducted auctions is based upon the number of bidders participating in the plurality of all pay online auctions.

14. A method as claimed in claim 12 or 13 wherein the step of allocating a plurality of remote bidders further comprises randomly allocating bidders to different simultaneously conducted auctions in an auction set.

15. A method as claimed in claim 12 or 23 wherein the step of allocating a plurality of remote bidders further comprises allocating bidders to different auctions according to predetermined allocation criteria.

16. A method as claimed in claim 15 wherein the predetermined criteria is a weighting scheme.

17. A method as claimed in any one of claims 11 to 16 wherein the end of the bid accumulation period is common for simultaneous auctions.

18. A method as claimed in claim 17 wherein at the end of the bid accumulation period for each auction, a remote bidder is reallocated to an auction in the same set of auctions.

19. A method as claimed in claim 18 wherein a remote bidder is participating in a plurality of auctions for a plurality of items and reallocation is performed to minimise the likelihood that the remote bidder is allocated to the same plurality of auctions that another remote bidder is allocated to.

20. A method as claimed in any one of claims 11 to 19, wherein a remote bidder is associated with two or more the plurality auctions and an all bid selector is provided to a remote bidder wherein upon selection by the remote bidder a single bid is submitted in all auctions the remote bidder is associated with.

21. A computer program product, comprising a computer usable medium having a computer readable program code embodied therein, said computer readable program code adapted to be executed to implement a method according to any one of claims 1 to 20.

22. A computer server for use in an online auction system used by a plurality of remote bidders, the computer server comprising: a) an auction control module for controlling an auction for an item at an offered sale price; c) a communications interface for providing auction information to a remote bidder on the at least one auction associated with the remote bidder, and for receiving bids from the remote bidders; and d) a bid window accumulator for accumulating bids received during at least one predetermined bid accumulation period during the auction, wherein if a predetermined number of bids are received during the predetermined bid accumulation period, then the auction is won by the bidder or bidders whose bids were received during the predetermined time period, and the offered sale price is constant for each predetermined bid accumulation period

23. A computer server as claimed in claim 22, further comprising: e) a bid window reporter for reporting the results of a bid accumulation period to the remote bidders who lodged bids during the bid accumulation period.

24. A computer server as claimed in claim 22 or 23, wherein the auction is an all pay auction and the computer server further comprises: f) a bid charge transaction module 117 for charging a bid cost price for each bid sent by a bidder.

25. A computer server as claimed in claim 23 or 24 wherein at the end a predetermined bid accumulation period, the auction controller places the auction in a bid reporting period during which no further bids are received and results of the auction are reported to the remote bidders by the bid window reporter.

26. A computer server as claimed in claim 23, 24 or 25 wherein a predetermined bid accumulation window is split into a plurality of time periods, and the number of bids received in each of these time periods is reported to each remote bidder that sent a bid during the predetermined bid accumulation period.

27. A computer server as claimed in claim 26, wherein each time period is represented by a symbol for display on a display device associated with the remote bidder and the symbols are progressively replaced with the number of bids received in the time period associated with the symbol.

28. A computer server as claimed in claim 27 wherein the order of the symbols is not the time order of the plurality of time periods.

29. A computer server as claimed in any one of claims 22 to 28, wherein if remote bidder wins an auction they are provided with the option of selling the item back to the seller at the offered sale price.

30. A computer server as claimed in any preceding claim, further comprising: g) a bid incidence accumulator to accumulate the total number of bids received for the auction; and h) a sale price updater associated for updating the offered sale price according to a price update function wherein the price update function uses at least the accumulated bid incidence to update the offered sale price to a higher, lower or the same sale price.

31. The computer server as claimed in claim any one of claims 22 to 30, wherein the auction control module controls a plurality of auctions wherein each auction is for an item at an offered sale price and the communications interface further provides information on each auction to each bidder; and the bid window accumulator accumulates bids for each auction, and the computer server further comprises an auction selector for associating each remote bidder with at least one auction.

32. A computer server as claimed in claim 31 wherein the plurality of auctions is divided into a plurality of auction sets wherein each auction in an auction set is for an identical item.

33. A computer server as claimed in claim 32, wherein two or more auctions in an auction set are conducted simultaneously with identical start and end times and are configured so that they are indistinguishable to a bidder.

34. A computer server as claimed in claim 33, wherein the number of simultaneously conducted auctions is based upon the number of bidders logged into the computer server.

35. A computer server as claimed in claim 33 or 34, wherein the auction selector randomly allocates bidders to different auctions in an auction set.

36. A computer server as claimed in claim 33 or 34, wherein the auction selector allocates bidders to different auctions according to predetermined allocation criteria.

37. A computer server as claimed in claim 36, wherein the predetermined criteria is a weighting scheme.

38. A computer server as claimed in any one of claims 33 to 37 wherein the end of the bid accumulation period is common for simultaneous auctions.

39. A computer server as claimed in claim 38 wherein at the end of the bid accumulation period for each auction, a remote bidder is reallocated to an auction in the same set of auctions.

40. A computer server as claimed in claim 39 wherein a remote bidder is participating in a plurality of auctions for a plurality of items and reallocation is performed to minimise the likelihood that the remote bidder is allocated to the same plurality of auctions that another remote bidder is allocated to.

41. A computer server as claimed in any one of claims31 to 40, wherein a remote bidder is associated with two or more the plurality auctions and the communications interface further provides an all bid selector to a remote bidder wherein upon selection by the remote bidder a single bid is sent to the communications interface which upon receipt submits a bid in two or more auctions the remote bidder is associated with.

42. A computer server for use in an online auction system used by one or more bidders in communication with the computer server for auctioning one or more items, the computer server comprising: a) a processor for simultaneously controlling one or more auctions; b) a storage device for storing one or more initialisation characteristics of one or more auctions comprising a sale price for an item or service for each auction; c) a communications interface for receiving one or more bids from one or more bidders associated with a respective auction initialised from the initialization characteristics stored on the storage device; d) a bid discriminator for discriminating bids comprising simultaneously received bids for each auction; e) a bid incidence accumulator to accumulate a total of bids for each auction; f) a sale price updater associated with each auction for updating the sale price for a respective auction according to a price update function wherein the price update function uses at least the accumulated bid incidence for a respective auction to update the sale price to a higher, lower or the same sale price; and g) a bid charge transaction module for charging a bid cost price for each received bid.

43. A computer server as claimed in any one of claim 42, further comprising: h) a bid selector for selecting a bid to be a preferred bid, associating a sale price with the preferred bid and triggering the sale price updater to update the sale price; and i) an auction end determiner for determining when to end each auction and ending the auction, wherein the preferred bid in the auction is selected as the winning bid.

44. A computer server as claimed in claims 43 wherein if a bid was received within a predetermined end time period before the end of the auction the auction end determiner extends the auction by a predetermined auction extension time period and the communications interface provides auction status information to one or more client devices such that the display of a client device displays a plurality of symbols each associated with a distinct time period of the currently remaining auction time and each symbol is displayed in either a neutral state, a pending stated or an expired state depending upon whether the current time is before the start of the associated time period, during the associated time period, or after the end of the associated time period.

45. A method for conducting a one or more all pay online auctions, the method comprising: initialising one or more all pay online auctions comprising associating a bid cost price, a sale price and auction end triggers with each of the one or more all pay online auctions; receiving one or more bids from one or more bidders associated with one of the one or more all pay online auctions and charging each bidder a bid cost price for submitting a bid; accumulating the total of bids received for each auction; determining whether to end the auction based upon triggering of an auction end trigger; and updating the sale price for each auction according to a price update function wherein the price update function uses at least the accumulated total number of bids received for each auction to update the sale price to a higher, lower or the same sale price.

46. A computer program product, comprising a computer usable medium having a computer readable program code embodied therein, said computer readable program code adapted to be executed to implement a method according to claim 45.