Abstract:
Bidding activity is analyzed over a duration in which multiple bids are received in the auction. A bid increment is dynamically determined for the auction in response to auction activity. An online auction system can utilize the bid increment to determine or suggest the next bid that can be received in the auction for purpose of supplanting the current bid.

Description:
RELATED APPLICATIONS 
       [0001]    This application claims benefit of priority to Provisional U.S. Patent Application No. 61/802,319, filed Mar. 15, 2013; the aforementioned priority application being hereby incorporated by reference in its entirety for all purposes. 
     
    
     TECHNICAL FIELD 
       [0002]    Examples described herein relate to online auctions, and more specifically, to a flexible asset pool for online auctions. 
       BACKGROUND 
       [0003]    Numerous online auction forums exist that enable consumers and sellers to transact for various kinds of items, such as collectibles, electronics and other goods or services. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0004]      FIG. 1  illustrates an exemplary system for implementing flexible asset pools in an online auction. 
           [0005]      FIGS. 2A-2B  illustrate an exemplary flexible asset pool. 
           [0006]      FIG. 3  illustrates an exemplary method of implementing a flexible asset pool. 
           [0007]      FIG. 4  illustrates an exemplary method of implementing an online auction using a flexible asset pool. 
           [0008]      FIG. 5  illustrates an example bidder interface in which a flexible asset pool record is displayed. 
           [0009]      FIG. 6  is a block diagram that illustrates a computer system upon which embodiments described herein may be implemented. 
       
    
    
     DETAILED DESCRIPTION 
       [0010]    Examples described herein provide for online auction forums that utilize flexible asset pools for purposes of dynamically adding and/or removing assets associated with an asset pool. By defining an asset pool as a “flexible” (e.g., dynamically-modifiable) object, asset pools can be updated and/or modified in real-time. Furthermore, bidders may be able to view documents that are associated with new assets as soon as they are added to the asset pool. The use of flexible asset pools can enable asset pool auctions to be carried through to completion even if one or more assets in an asset pool becomes unavailable before the auction is completed. 
         [0011]    According to some embodiments, a system and method is provided for generating flexible asset pools in an online auction environment. In some examples, an asset pool is generated based on a set of instructions from the seller. The asset pool is associated with a set of items to be sold in the auction. In examples described herein, the auction system may detect a change in status for the set of items associated with the asset pool (e.g., items being added to and/or removed from the item set). In response thereto, the auction system may dynamically update the asset pool (e.g., to reflect the changes to the set of items) based, at least in part, on the detected changes. 
         [0012]    Among other benefits, examples described herein recognize that the status of items associated with an asset pool are susceptible to change. For example, a particular item may become unavailable (e.g., lost, stolen, or destroyed), or the seller may change its mind about selling the item, before the auction period expires. Under conventional implementations, the current asset pool is removed from the auction, and a new one may be created (e.g., manually by the seller) to take its place. Creating a new asset pool typically entails creating a new auction altogether. Accordingly, a clock or timer (e.g., for a “due diligence period”) associated with the auction is often reset when the new asset pool is created (e.g., to provide bidders with adequate time to review any documentation associated with the items in the new asset pool). 
         [0013]    In contrast, examples described herein recognize that, when a new asset pool is created, typically only a small number of items are new (i.e., the majority of items in the new asset pool are carried over from the old asset pool). It may thus be undesirable to restart the due diligence period, since only a limited number of new documents are likely to be associated with the new items. Therefore, examples described herein provide a mechanism for dynamically updating an asset pool without restarting the due diligence period for the auction. 
         [0014]    By way of example, a loan is termed “non-performing” if the borrower fails to perform the terms of the loan agreement (e.g., the owner of real estate is unable to pay the mortgage). Such a loan is called a non-performing loan (NPL). NPLs are typically pooled together and auctioned off as a group to offset the risks associated with individual loans in the loan pool. However, if a homeowner suddenly pays off his or her mortgage, that homeowner&#39;s loan may fall out of the loan pool (thus becoming unavailable). Examples described herein enable a seller of the loan pool to dynamically add a new NPL to the pool to replace the loan that fell through. 
         [0015]    For some embodiments, one or more asset pool parameters may be updated after modifying (e.g., adding to or removing from) the set of items associated with a particular asset pool. For example, the asset pool parameters may indicate the number of items in the pool, the type(s) of items in the pool, the total value of the asset pool, the value of individual items in the pool, and/or the (geographical) locations of items in the asset pool. 
         [0016]    In other embodiments, one or more items may be programmatically added to an asset pool (e.g., to replace items that fell out of the pool) in accordance with a set of predefined asset pool parameters. For example, the seller may configure the asset pool to have one or more “fixed” parameters. Thereafter, if an item associated with an asset pool becomes unavailable, the auction system may add one or more new items (e.g., from a database of items) to the asset pool without the need for seller input. 
         [0017]    One or more embodiments described herein provide that methods, techniques and actions performed by a computing device are performed programmatically, or as a computer-implemented method. Programmatically means through the use of code, or computer-executable instructions. A programmatically performed step may or may not be automatic. 
         [0018]    One or more embodiments described herein may be implemented using programmatic modules or components. A programmatic module or component may include a program, a subroutine, a portion of a program, or a software component or a hardware component capable of performing one or more stated tasks or functions. As used herein, a module or component can exist on a hardware component independently of other modules or components. Alternatively, a module or component can be a shared element or process of other modules, programs or machines. 
         [0019]    Furthermore, one or more embodiments described herein may be implemented through the use of instructions that are executable by one or more processors. These instructions may be carried on a computer-readable medium. Machines shown or described with figures below provide examples of processing resources and computer-readable mediums on which instructions for implementing embodiments of the invention can be carried and/or executed. In particular, the numerous machines shown with embodiments of the invention include processor(s) and various forms of memory for holding data and instructions. Examples of computer-readable mediums include permanent memory storage devices, such as hard drives on personal computers or servers. Other examples of computer storage mediums include portable storage units, such as CD or DVD units, flash or solid state memory (such as carried on many cell phones and consumer electronic devices) and magnetic memory. Computers, terminals, network enabled devices (e.g., mobile devices such as cell phones) are all examples of machines and devices that utilize processors, memory, and instructions stored on computer-readable mediums. Additionally, embodiments may be implemented in the form of computer-programs, or a computer usable carrier medium capable of carrying such a program. 
         [0020]    Auction Architecture 
         [0021]      FIG. 1  illustrates an exemplary system for implementing flexible asset pools in an online auction. A system  100  such as shown by an example of  FIG. 1  can be implemented in connection with an online auction service for any type of commercial item, such as, for example, real property items (e.g., homes, real-estate notes, commercial property), motor vehicles (e.g., automobiles, motorcycles, boats), consumer electronics, collectibles, clothing, and/or non-performing loans (NPLs). 
         [0022]    In an example of  FIG. 1 , system  100  includes functionality that can be implemented by processes, logical components and/or modules. In one implementation, the system  100  includes a bidder interface  110 , a transaction component  120 , an auction database  130 , pool configuration logic  140 , and a seller interface  150 . When an online auction is initiated, persons (e.g., bidders) can interact with the bidder interface  110  to determine whether to place a bid, and to submit the bid for the item being auctioned. The transaction component  120  can implement a set of auction rules and logic for receiving bids and advancing the auction to completion. 
         [0023]    The auction database  130  retains records that identify asset pools that are to be auctioned, and/or asset pools which are undergoing or have completed an auction. Furthermore, the auction database  130  can retain records of auctions in various states, including pre-auction, in-auction (auction initiated) and post-auction (auction completed). In some examples, the auction database  130  includes an asset pool database  134  and an asset database  132 . The asset pool database  134  stores asset pool records (AP records)  121  that are used to identify the asset pools to be auctioned. The asset database  132  stores asset records  131  which identify the individual assets belonging to a particular asset pool. In addition, the asset database  132  can also store asset documents  133  that are associated with the asset records  131 . Asset documents  133  may include, for example, certificates of authenticity, financial records, contractual agreements, and/or other documents which may be of interest to a potential buyer of the corresponding asset (or asset pool). For some embodiments, each AP record  121  is associated with (e.g., points to) one or more asset records  131  stored in the asset database  132 , including any corresponding asset documents  133 . 
         [0024]    The bidder interface  110  includes functionality for enabling bidders to view and participate in an in-progress auction. The bidder interface  110  can be provided as, for example, a webpage that includes functional elements for enabling the users to provide input (e.g., bids  111 ) and to view real-time updates for the auction while it is in progress. In variations, the bidder interface  110  can be provided as application content, such as through a display or panel of a network-enabled application. The bidder interface  110  can include functionality for enabling a bidder to specify a bid  111 , and to monitor real-time information about the auction. For example, the bidder interface  110  can display information about the asset pool being auctioned (e.g., description, images, etc.), information about individual assets contained in the asset pool, information about the seller, and/or a full or partial bid history (e.g., the bidder or bidder identity and a corresponding bid amount, the number of bids received in a given duration etc.). In addition, the bidder interface  110  can display timing information associated with a particular auction. Timing information may include, for example, the time remaining for a due diligence period associated with the auction and/or the time remaining before the auction is closed. For some embodiments, the bidder interface  110  may also display asset documents  131  associated with the asset pool being auctioned, and updates the asset documents  131  that can be displayed (e.g., in real-time) as individual assets are dynamically added to and/or removed from an asset pool. 
         [0025]    The transaction component  120  can implement operations for progressing the auction towards completion. The transaction component  120  may retrieve AP records  121 , and associated asset documents  131 , from the auction database  130 . Furthermore, the transaction component  120  may include functionality to (i) initiate an auction, (ii) advance the auction towards completion, and/or (iii) end or complete the auction when certain conditions are satisfied (e.g., after completion of time and/or satisfaction of completion rules). In addition to receiving and processing bids  111 , the transaction component  120  provides auction updates  113  to the bidders that are viewing or participating in a particular auction. The auction update  113  can include information such as, a current price for the asset pool being auctioned, an amount of time remaining in the auction or due diligence period, and/or updates to an asset pool being auctioned (e.g., addition/removal of assets included in the asset pool, updated asset pool parameters, and/or new documents that are associated with the asset pool). Other information that can be updated by the transaction logic  120  and published through the bidder interface  110  include identifiers for active bidders, recent bid amounts, current bid increment, comments from other users, and information from other auctions that may be in various states (e.g., pre-auction versus in-progress). The auction update  113  can be published through the bidder interface  110  to the population of users. 
         [0026]    The seller interface  150  enables individual sellers to create records that identify an asset pool for auction. For example, the seller interface  150  can enable sellers to specify information (e.g., one or more asset pool parameters) that identifies the asset pool being auctioned, the terms of sale, and other parameters such as a reserve price (which can be hidden from prospective bidders). The seller interface  150  may also enable the sellers to create and/or modify asset pools. For example, the seller interface  150  may enable sellers to input, select, or otherwise indicate (e.g., via AP instructions  141 ) one or more assets records  131  to be included with an AP record  121 . Additionally, the seller interface  150  may enable the seller to specify one or more asset pool parameters (e.g., which may identify a number, type, value, and/or location of the individual assets associated with an asset pool) that can be used by the pool configuration logic  140  to programmatically add and/or remove individual assets from a particular asset pool. 
         [0027]    As described by various examples, the pool configuration logic  140  can dynamically modify AP records  121  stored in the auction database  130 . For example, as shown with respect to  FIGS. 2A-2B , the pool configuration logic  140  may associate (e.g., reference) and/or disassociate (e.g., de-reference) one or more asset records  133  (e.g., stored in the asset database  132 ) with an asset pool  121  (e.g., stored in the asset pool database  134 ). For some embodiments, the associations between AP records  121  and asset records  131  (and asset documents  133 ) may be implemented using pointers. Accordingly, the pool configuration logic  140  can “create” an association by referencing a pointer, stored with an AP record  121 , to point to the memory location (e.g., in asset database  132 ) where a corresponding asset record  131  is stored. Similarly, the pool control logic  140  can “delete” an association by de-referencing the pointer. 
         [0028]    With reference to  FIG. 2A , the pool configuration logic  140  may associate asset records  131 (A) and  131 (B), and accompanying asset documents  133 (A) and  133 (B), with AP record  121 ( 1 ), for example, by storing a set of pointers (e.g., pointer_A and pointer_B) with the AP record  121 ( 1 ) which points to memory locations in the asset database  132  that store the corresponding asset records  131 (A) and  131 (B) and asset documents  133 (A) and  133 (B). The pool configuration logic  140  can further modify the AP record  121 ( 1 ) by referencing and/or dereferencing pointer_A and pointer_B. With reference to  FIG. 2B , the pool configuration logic  140  may dynamically modify the asset pool associated with AP record  121 ( 1 ) by “moving” pointer_B from the memory location(s), in asset database  132 , that stores asset record  131 (B) and asset documents  133 (B) to the memory location(s) that stores asset record  131 (C) and asset documents  133 (C). This effectively removes an old asset (e.g., asset record  131 (B)) from the asset pool and adds a new asset (e.g., asset record  131 (C)) to take the place of the old asset. 
         [0029]    The pool configuration logic  140  may include an asset pool parameter (AP parameter) modifier  142  and an asset pool update (AP update) manager  144 . The AP update manager  144  may detect changes to one or more assets included with an asset pool being auctioned. The AP parameter modifier  142  may update or modify one or more AP parameters associated with an asset pool being auctioned. 
         [0030]    In some examples, the AP update manager  144  may detect changes in the form of asset pool instructions (AP instructions)  141  received from a seller via the seller interface  150 . The AP instructions  141  may include instructions to add and/or remove one or more assets in an asset pool. Furthermore, the AP instructions  141  may include instructions to move one or more assets between asset pools (i.e., from one asset pool to another). 
         [0031]    In other examples, the AP update manager  144  may detect changes to one or more assets included with an asset pool based on the availability of such assets. For example, as described above, the availability of certain assets up for auction may be subject to change contrary to the seller&#39;s intention (and in some instances, without the seller&#39;s knowledge). Thus, for some embodiments, the AP update manager  144  may “monitor” (e.g., periodically check) the asset database  132  for changes to the asset records  131  stored therein. 
         [0032]    In some examples, the AP parameter modifier  142  may update one or more AP parameters to reflect the changes to one or more assets included with an asset pool being auctioned. The AP parameters may be presented to a bidder via the bidder interface  110  to provide the bidder with information regarding the asset pool being auctioned. Examples of AP parameters may include (i) the number of assets in the asset pool, (ii) the types of assets in the asset pool, (iii) the total value of the asset pool, (iv) the value of individual assets in the asset pool, and/or (v) the geographical locations of assets in the asset pool. One or more of these parameters are likely to change whenever new assets are added to and/or removed from an asset pool. Accordingly, the AP parameter modifier  142  may update these AP parameters to keep the bidder apprised of any changes to a particular asset pool. The AP parameters may be included as part of (e.g., stored with) a corresponding AP record  121 . 
         [0033]    In other examples, the AP parameter modifier  142  may receive a set of AP parameter configuration instructions (e.g., in the form of AP instructions  141 ) from the seller via the seller interface  150 . For example, the configuration instructions may define a set of fixed AP parameters which the AP parameter modifier  142  may use to programmatically modify asset pools. For example, by preconfiguring an asset pool to have a total value (e.g., of at least $1M), the AP parameter modifier  142  may programmatically generate the asset pool by including individual assets that total in value to at least $1M. If an asset (e.g., valued at $100k) becomes unavailable before completion of the auction, the AP parameter modifier  142  may add one or more new assets (e.g., totaling in value to $100k) to the asset pool. 
         [0034]    Defining a set of fixed AP parameters for an asset pool may provide bidders and/or sellers with peace of mind. For example, bidders can bid with confidence knowing that, should any of the assets included with an asset pool become unavailable before an auction is completed, a new asset which satisfies the predefined AP parameters may be added in its place. Moreover, having “flexible” AP records  121  allows auctions to be completed on schedule, while also allowing the asset pools in a particular auction to be dynamically modified. More specifically, dynamically adding asset documents  133  for new assets that are added to an asset pool negates the need to restart a clock or timer for a due diligence period associated with the auction. It is to be noted that the due diligence period may occur before, and/or concurrently with, the overall auction period. 
         [0035]    Methodology 
         [0036]      FIG. 3  illustrates an exemplary method of implementing a flexible asset pool.  FIG. 4  illustrates an exemplary method of implementing an online auction using a flexible asset pool. Methods such as described by examples of  FIG. 3  and  FIG. 4  can be implemented using, for example, a system such as described with respect to  FIG. 1 . Accordingly, reference may be made to elements of  FIG. 1  for purposes of illustrating suitable components for performing a step or sub-step being described. 
         [0037]    In  FIG. 3 , a status change is detected for an asset pool ( 310 ). In some embodiments, the change in status may be detected based on instructions from a seller of the asset pool ( 312 ). For example, the AP update manager  144  may receive AP instructions  141  from the seller via the seller interface  150 . In some examples, the AP instructions  141  may include instructions to add, remove, and/or swap one or more assets in an asset pool. The AP instructions  141  may also include instructions to create an asset pool. In some examples, the AP instructions  141  may specify a set of asset records  131  to be included with an AP record  121 . In other examples, the AP instructions  141  may define a set of fixed AP parameters which may be used by the AP parameter modifier  142  to programmatically create and/or modify an asset pool. In some embodiments, the change in status may be detected based on a change in availability of a particular asset in the asset pool ( 314 ). For example, the AP update manager  144  may monitor the asset database  132  for changes to the asset records  131  stored therein. 
         [0038]    Once a change in status has been detected for a particular asset pool, a corresponding AP record may be created and/or modified for that asset pool ( 320 ). In some examples, the AP record may be created and/or modified by associating asset records with the AP record ( 322 ) or disassociating asset records with the AP record ( 324 ). The pool configuration logic  140  may dynamically create an association between an AP record  121  and one or more asset records  131 , for example, by referencing a pointer, stored with the AP record  121 , to point to one or more memory locations (e.g., in asset database  132 ) where the corresponding asset record(s)  131  are stored. The pool configuration logic  140  may subsequently delete the association by dereferencing the pointer. 
         [0039]    In the examples described with respect to  FIGS. 2A and 2B , asset documents  133  may be stored in the same, or consecutive, memory locations as their corresponding asset records  131 . In such implementations, only one pointer is needed to associate the AP record  121  with both the asset record  131  and the corresponding asset documents  133 . However, in some implementations, the asset documents  133  may be stored separately (e.g., in a separate asset record database). Thus, in some examples, one or more asset documents  133  may be associated with the AP record  121 , apart from the asset records  131 . The pool configuration logic  140  may dynamically create and/or delete an association between an AP record  121  and one or more asset documents  133 , for example, by referencing and/or dereferencing a pointer, stored with the AP record  121 , which points to one or more memory locations where the corresponding asset documents  133  are stored. 
         [0040]    After an asset pool is created and/or modified, one or more AP parameters associated with the asset pool may be determined ( 330 ). Examples of AP parameters may include the number of assets in the asset pool ( 332 ), the types of assets in the asset pool ( 332 ), the value of assets in the asset pool ( 336 ), and/or the geographical locations of assets in the asset pool ( 338 ). In some examples, the AP parameter modifier  142  may update one or more AP parameters to reflect one or more corresponding changes to an AP record  121 . The AP parameters may be presented to a bidder via the bidder interface  110 , to provide the bidder with information regarding the asset pool being auctioned. 
         [0041]      FIG. 4  shows an exemplary auction process, which is herein described with reference to the system  100  of  FIG. 1 . The pool configuration logic  140  initially receives a list of assets to be included with an asset pool ( 410 ). For example, the pool configuration logic  140  may receive AP instructions  141  from the seller, via the seller interface  150 , which may include instructions to create an asset pool. In some examples, the AP instructions  141  may specify a set of asset records  131  to be included with an AP record  121 . In other examples, the AP instructions  141  may define a set of fixed AP parameters which may be used by the AP parameter modifier  142  to programmatically create and/or modify an asset pool. 
         [0042]    The pool configuration logic  140  then creates a flexible AP record  121  based on the AP instructions  141  ( 420 ). For example, as described above, the pool configuration logic  140  may dynamically create an association between the AP record  121  and one or more asset records  131  (e.g., using pointers which can be referenced and/or dereferenced). In some examples, the pool configuration logic  140  may associate the AP record  121  with a number of seller-specified asset records  131  provided with the AP instructions  141 . The pool configuration logic  140  may then determine a set of AP parameters for the asset pool, based on the assets associated with the asset pool, to be included with the AP record  121 . In other examples, the pool configuration logic  140  may programmatically select one or more asset records  131  to be associated with the AP record  121 , according to a set of predefined AP parameters specified in the AP instructions  141 . 
         [0043]    Once the AP record  121  has been created, the transaction component  120  may start a timer on an auction and/or due diligence period ( 430 ). For some examples, the transaction component  120  may provide the time remaining for the auction and/or due diligence period to the bidder interface  110  through a series of auction updates  113 . 
         [0044]    As long as the timer has not expired ( 440 ), the pool configuration logic  140  may continuously (or periodically) check the status of the assets in the asset pool ( 450 ). In some examples, the pool configuration logic  140  may check the status of the assets by listening for AP instructions  141  from a seller ( 452 ). In other examples, the pool configuration logic  140  may check the status of the assets by monitoring the availability of asset records  131  in the asset database  132  ( 454 ). If no status change is detected ( 460 ), and the timer has not expired ( 440 ), the pool configuration logic  140  continues to check the status of the assets in the asset pool ( 450 ). 
         [0045]    If a status change is detected ( 460 ), the pool configuration logic  140  updates the asset pool based on the detected changes ( 470 ). Specifically, the AP update manager  144  may add or remove one or more assets in the asset pool ( 472 ). For example, the AP update manager  144  may add or remove the assets by associating (e.g., referencing) or disassociating (e.g., dereferencing) asset records  131  with a corresponding AP record  121 . The AP parameter modifier  142  may then update the set of AP parameters associated with the AP record  121  ( 474 ). Examples of AP parameters may include: (i) the number of assets in the asset pool, (ii) the types of assets in the asset pool, (iii) the value of assets in the asset pool, and/or (iv) the geographical locations of assets in the asset pool. 
         [0046]    Once the timer expires ( 440 ), the transaction is completed ( 480 ). In some examples, the transaction may correspond with a due diligence period wherein potential buyers/bidders are able to review asset documents  133  associated with an asset pool prior to the auction. In other examples, the transaction may correspond to the actual auction itself. It should be noted that, once the timer is started on the auction and/or due diligence period ( 430 ), the timer may continue to run, uninterrupted, until the transaction is complete ( 480 ). During this period, however, assets may be dynamically added to and/or removed from the asset pool ( 450 - 470 ). 
       EXAMPLES 
       [0047]      FIG. 5  illustrates an example bidder interface in which a flexible asset pool record  510  is displayed. In the example provided, the bidder interface may correspond to a web page, or set of web pages, where items can be auctioned. In the example provided, the items correspond to asset pools. Descriptive information may accompany the AP record  510  for the asset pool being auctioned. For example, descriptive information may include a set of AP parameters  512 - 518  that describe the pool of assets, as a whole. The displayed AP parameters include the type of assets in the asset pool  512  (e.g., “Non-Performing Loans”), the total number of assets in the asset pool  514  (e.g., “5”), the total value of the asset pool  516  (e.g., “$10,000,000”), and the location of the assets in the asset pool  518  (e.g., “San Jose, Calif.”). The bidder interface also displays links to asset documents  520  associated with each of the assets listed in the AP record  510 . 
         [0048]    For some examples, when an asset is added to or removed from the asset pool, the AP parameters  512 - 518  may be updated to reflect the change. In other examples, the AP parameters  512 - 518  may correspond to seller-defined fixed parameters for the asset pool. The links to asset documents  520  may similarly be updated to reflect such changes to the asset pool. For example, if NPL# 1  is removed from the asset pool, the link to the associated asset documents for NPL# 1  may be deleted accordingly. If NPL# 1  is replaced by a new NPL# 6 , the link to the associated asset documents for NPL# 1  may be modified to link to the asset documents for NPL# 6 . 
         [0049]    Computer System 
         [0050]      FIG. 6  is a block diagram that illustrates a computer system upon which embodiments described herein may be implemented. For example, in the context of  FIG. 1 , system  100  may be implemented using one or more servers such as described by  FIG. 6 . 
         [0051]    In an embodiment, computer system  600  includes processor  604 , memory  606  (including non-transitory memory), storage device  610 , and communication interface  618 . Computer system  600  includes at least one processor  604  for processing information. Computer system  600  also includes the main memory  606 , such as a random access memory (RAM) or other dynamic storage device, for storing information and instructions to be executed by processor  604 . Main memory  606  also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor  604 . Computer system  600  may also include a read only memory (ROM) or other static storage device for storing static information and instructions for processor  604 . The storage device  610 , such as a magnetic disk or optical disk, is provided for storing information and instructions. The communication interface  618  may enable the computer system  600  to communicate with one or more networks through use of the network link  620  (wireless or wireline). The communication interface  618  may communicate with bidders and auction participants using, for example, the Internet. 
         [0052]    Embodiments described herein are related to the use of computer system  600  for implementing the techniques described herein. According to one embodiment, those techniques are performed by computer system  600  in response to processor  604  executing one or more sequences of one or more instructions contained in main memory  606 . Such instructions may be read into main memory  606  from another machine-readable medium, such as storage device  610 . Execution of the sequences of instructions contained in main memory  606  causes processor  604  to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement embodiments described herein. Thus, embodiments described are not limited to any specific combination of hardware circuitry and software. 
         [0053]    Although illustrative embodiments have been described in detail herein with reference to the accompanying drawings, variations to specific embodiments and details are encompassed by this disclosure. It is intended that the scope of embodiments described herein be defined by claims and their equivalents. Furthermore, it is contemplated that a particular feature described, either individually or as part of an embodiment, can be combined with other individually described features, or parts of other embodiments. Thus, absence of describing combinations should not preclude the inventor(s) from claiming rights to such combinations.