Abstract:
Some embodiments provide a method and a system for receiving selection of a plurality of entities in the network-based facility from an administrator, receiving selection of an action from the administrator, and applying the selected action to each entity in the plurality of entities.

Description:
RELATED APPLICATIONS 
       [0001]    The present application is a continuation of U.S. patent application Ser. No. 11/581,893 filed Oct. 17, 2006, which claims priority from U.S. patent application Ser. No. 09/747,204 filed Dec. 21, 2000, which claims priority from U.S. Provisional Application Ser. No. 60/171,821 filed Dec. 21, 1999 and from U.S. Provisional Application Ser. No. 60/178,122 filed Jan. 26, 2000, which applications are herein incorporated by reference. 
     
    
     FIELD OF THE INVENTION 
       [0002]    The present invention relates generally to the field of database administration and, more specifically, to a method of creating and communicating notes concerning an auction participant or item within a network-based auction facility. 
       BACKGROUND OF THE INVENTION 
       [0003]    The administration of a Web site, and specifically a commerce Web site, often demands that information concerning a user of tools and facilities provided by the Web site be communicated between various administrative personnel. It is important that the delivery mechanism for such information be reliable and up-to-date, as the failure to communicate information, or the miscommunication of information, may have very serious consequences for a commerce Web site. 
         [0004]    While e-mail provides one mechanism commonly used for communications between administrative personnel, e-mail may not be a desirable solution due to the variety of the e-mail clients that may be employed by administrative personnel and problems with e-mail delivery. 
         [0005]    Further, e-mail does not provide persistent or “sticky” information concerning an event concerning a user or item transacted via a commerce Web site. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0006]    The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which: 
           [0007]      FIG. 1  is a block diagram of an exemplary web-based facility in the form of a network-based auction facility. 
           [0008]      FIG. 2  is a database diagram illustrating an exemplary database, maintained by and accessed via a database engine server, that at least partially implements and supports the auction facility. 
           [0009]      FIG. 3  is a diagrammatic representation of exemplary links between a note record in a note table and user records and item records in respective user and item tables. 
           [0010]      FIG. 4  is a diagrammatic representation of an architecture of exemplary applications and functions within an auction facility that facilitate the creation and display of notes represented by a note record. 
           [0011]      FIG. 5  is a flow chart illustrating an exemplary method, according to one embodiment of the present invention, of communicating information via a network-based commerce facility. 
           [0012]      FIG. 6  illustrates an exemplary embodiment of an HTML page generated by a note search UI. 
           [0013]      FIG. 7  illustrates an exemplary embodiment of an HTML page generated by the note search UI that provides certain information regarding a participant located by a search string (e.g., a user). 
           [0014]      FIG. 8  illustrates an exemplary embodiment of an HTML page generated by a creation UI that allows a user, or administrator, to reinstate a user of an auction facility following a suspension. 
           [0015]      FIG. 9  illustrates a further exemplary embodiment of an HTML page generated by a note search UI that allows a user to perform a search specifically for notes regarding a participant or item of the auction facility. 
           [0016]      FIG. 10  is a flow chart illustrating an exemplary method of creating a note, represented by a note record, within a note table. 
           [0017]      FIGS. 11A-11E  show various exemplary UI&#39;s, in the form of HTML or other mark-up language pages, that may be presented to an administrator in the performance of an administrative function. 
           [0018]      FIG. 12  is a diagrammatic representation of a machine in the exemplary form of a computer system within which a set of instructions, for causing the machine to perform any of the methodologies discussed herein, may be executed. 
       
    
    
     DETAILED DESCRIPTION 
       [0019]    A method and system for communicating information within a network-based auction facility are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details. 
         [0020]    For the purposes of the present specification, the term “note” shall be taken to refer to any textual or graphic description, comment or communication. The term “participant” shall be taken to refer to any entity, human or automated, that contributes to, or participates in, a transaction, communication or process. 
         [0021]      FIG. 1  is a block diagram illustrating an exemplary Web-based commerce facility in the form of a network-based auction facility  10 . While an exemplary embodiment of the present invention is described within the context of an auction facility, it will be appreciated by those skilled in the art that the invention will find application in many different types of computer-based, and network-based, commerce facilities. 
         [0022]    The auction facility  10  includes one or more of a number of types of front-end servers, namely page servers  12  that deliver web pages (e.g., markup language documents), picture servers  14  that dynamically deliver images to be displayed within Web pages, listing servers  16 , CGI servers  18  that provide an intelligent interface to the back-end of facility  10 , and search servers  20  that handle search requests to the facility  10 . E-mail servers  21  provide, inter alia, automated e-mail communications to users of the facility  10 . 
         [0023]    The back-end services include a database engine server  22 , a search index server  24  and a credit card database server  26 , each of which maintains and facilitates access to a respective database. The back-end is also shown to include a number of administrative applications or functions  28  that are described in further detail below. 
         [0024]    The network-based auction facility  10  may be accessed by a client program  30 , such as a browser (e.g., the Internet Explorer distributed by Microsoft Corp. of Redmond, Wash.) that executes on a client machine  32  and accesses the facility  10  via a network such as, for example, the Internet  34 . 
         [0025]      FIG. 2  is a database diagram illustrating an exemplary database  23 , maintained by and accessed via the database engine server  22 , that at least partially implements and supports the auction facility  10 . The database  23  is a relational database, and includes a number of tables having entries, or records, that are linked by indices and keys. Central to the database  23  is a user table  40 , which contains a record for each user of the auction facility  10 . A user may operate as a seller, buyer, or both, within the auction facility  10 . The database  23  also includes item tables  42  that may be linked to the user table  40 . Specifically, the item tables  42  include a seller items table  44  and data items table  46 . A user record in the user table  40  may be linked to multiple items that are being, or have been, auctioned via the facility  10 , a link indicating whether the user is a seller or a bidder (or buyer) with respect to items for which records exist within in the item tables  42 . The database  23  also includes a note table  48  populated with note records that may be linked to one or more item records within the item tables  42  and/or to one or more user records within the user table  40 . Each note record within the table  48  may include, inter alia, a comment, description, history or other information pertaining to an item being auctioned via the auction facility  10 , or to a user of the auction facility  10 . 
         [0026]    A number of other tables are also shown to be linked to the user table  40 , namely a user past aliases table  50 , a feedback table  52 , a bids table  54 , an accounts table  56 , and an account balances table  58 . 
         [0027]      FIG. 3  is a diagrammatic representation of exemplary links between a note record  60  in the note table  48 , and user records  62  and item records  64  in the respective user table  40  and item tables  42 .  FIG. 3  also illustrates an exemplary structure, or fields, of the note record  60 . 
         [0028]    As described above with reference to  FIG. 2 , user records  62  may be linked to one or more item records, the links indicating whether the relevant user is a bidder or seller with respect to the relevant item or items. For example, in  FIG. 3 , the user  4  is shown to be a seller of item 4, while user  1  is shown to be the seller of items 1 and 2, and a bidder for item 3. Accordingly, a one-to-many mapping, or linkage, may occur between user records and item records, and the links may either be bidder or seller links. 
         [0029]    The note record  60  is shown to include a number of fields, each of which is briefly discussed below:
       1. An identification field  66 : this field contains a numeric identification number for note record  60 .   2. A type field  68 : this field contains textual type information, which is selected from a predetermined set of message types that provides an indication of the reason for the creation of the note record  60 . The predetermined set of message types may be presented, for example, to an administrator of the auction facility  10  for selection in the form of a drop-down menu of a user interface. The type information may furthermore constitute both primary and secondary type information, with the primary type information providing a broad type indication and the secondary type information providing a lower granularity of type information. As such, type information may be viewed as a “meta title” for a note record  60  that corresponds to common topics for notes. Examples of message types that may be included within the predetermined set of message types include: user suspended, user received temporary clearance, user received procedural warning, item ended because copyright/trademark violation, item ended because offensive material, etc.   3. A visibility field  70 : this field contains alphanumeric visibility information indicating which, for example, administrators or level of administrator of the auction facility  10  have access to the relevant note record  60 .   4. A “user_from” field  72 : this field contains alphanumeric address information (or a key to such address information stored in the user table  40 ), indicating, for example, an address, or multiple addresses, of an administrator(s) that created the note record  60 .   5. A “user_to” field  74 : this field contains alphanumeric address information (or a key to such address information stored in the user table  40 ), indicating, for example, an address, or multiple addresses, of an administrator(s) to which the note record  60  is addressed or targeted.   6. A “user_about” field  76 : this field contains alphanumeric address information (or a key to such address information stored in the user table  40 ) indicating the address of, for example, a user or participant of the auction facility  10  to which the relevant note record  60  may pertain. Such a participant may, it will be appreciated, be or have been either a bidder or a seller of items on the auction facility  10 .  FIG. 3  according illustrates this field as being linked, or keyed, to a user record  62  within the user table  40 .   7. An “item_about” field  78 : this field contains a key to an item record(s)  64  within the item tables  42 , and accordingly identifies a particular item to which the note record  60  may pertain. In the exemplary embodiment, such items may include both physical products and services. The physical products may comprise a specialized category of products where the auction facility  10  is focused on such a specialized categories (e.g., www.art.com) or a broad range of products where the auction facility  10  provides a more general marketplace (e.g., www.ebay.com).   8. A “when” field  80 : this field contains data information indicating a date on which the relevant note record  60  was created.   9. An “expiration” field  82 : this field contains date information indicating an expiration date on which the relevant note record  60  expires. The expiration data may, for example, be inputted by an administrator when creating the note record, and may specify a predetermined time period (e.g., one year) from the creation date at which the note record  60  is to expire.   10. A “subject” field  84 : this structure field contains textual information that is selected from a dynamic list of well-known subjects by a creator of the note record  60 . For example, the list of subjects may include: suspension, warning, billing warning, billing authorization, etc.   11. A “text” field  86 : this field contains free-form text inputted the creator of the note record  60  that may provide further information regarding the relevant note.       
 
         [0041]      FIG. 4  is a diagrammatic representation of the architecture of exemplary applications and functions within the auction facility  10  that facilitate the creation and display of notes represented by the note record  60 . The auction facility  10  includes a number of administrative applications  28  that may be invoked by administrators of the auction facility  10  to facilitate convenient and user-friendly administration through the use of notes. Examples of the administrative applications include an “add_note_about_user” administrative application  90  that an administrator may invoke to generate a note concerning a participant and an “add_note_about_item” administrative application  92  that may be invoked to generate a note concerning an auction item. Further administrative applications  28  enable an administrator to create notes concerning, for example, the suspension of a user or item, the removal of an item that is up for auction on the auction facility  10 , and the early ending of auction. 
         [0042]    Each of the administrative applications  28  may call a note Application Program Interface (API)  100  that embodies a note creation function  102 , a note search function  104 , and a note display function  105 . The note creation function  102  facilitates the storage of notes as note records  60  including the data elements, or fields, described above. The note creation function  102  also allows note records  60  to be removed individually, or in a batch utilizing other criteria. The note creation function  102  also, in turn, calls one or more note creation User Interfaces (UI&#39;s)  106  that each present a number of input fields, for example corresponding to the fields of a note record  60 , via which a user (e.g., an administrator) can input information to populate the fields of a note record  60 . As mentioned above, respective sets of type information and subject information may be presented by a creation UI  106  as drop-down menus. A creation UI  106  may also perform a validation, or authentication, function by requiring an administrator to input a user ID and password that are validated before creation of a note record  60  utilizing information supplied via the relevant creation UI  106 . In one embodiment, a creation UI  106  may (1) display an HTML form (e.g., add note.HTML) that presents a number input fields, (2) perform a further validation operation of the user ID and password, as well as of other information that is being submitted (e.g., administrator or participant address information, subject information and type information), and (3) if the submitted information is all valid, communicate this information to the API  100  for storage as a note record  60  and display a confirmation screen to the relevant administrator. If the validation operation identifies any inputted information as being invalid or incorrect, this is communicated by the note creation UI  106  to the administrator. 
         [0043]    The note search function  104  facilitates the searching of note records  60 , within the note table  48 , based on any one of a number of fields (e.g., administrator address or identifier, participant address or identifier, item number, type information, subject information, etc.). The note search function  104 , in turn, may call one or more note search User Interfaces (UI&#39;s)  108  that present a number of input fields for specifying search criteria. As with the note creation UI&#39;s  106 , the note search UI&#39;s  108  may perform a validation function by requiring an administrator to input a user ID and password that are validated before permitting a search operation. If the validation operation identifies any input information as being invalid or incorrect, this is communicated by the note search URI  108  to the searcher. 
         [0044]      FIG. 5  is a flowchart illustrating an exemplary method  110  of communicating information within a network-based commerce facility, such as the auction facility  10 . The method  110  commences at block  112  where a person or process (e.g., administrator) performs a search of the user table  40 , or the item tables  42 , for example utilizing the note search function  104 . The administrator may conduct such a search with a view to suspending a participant for a violation of rules by which the auction facility  10  operates or to removing an item from auction, or simply to investigate a user or item. The search may be conducted on any one of the fields discussed above. 
         [0045]    At block  114 , the note search function  104 , via the search UI  108 , displays textual information concerning a participant or item located by the search. At block  116 , the note search function  104 , again via the search UI  108 , displays a note icon adjacent the displayed textual information to indicate that at least one note, embodied within a note record  60 , is associated with the located participant or item. In one embodiment, where the search URI  108  displays the results of the search as an HTML document, the note icon may have a Uniform Resource Locator (URL) associated therewith that specifies a web or directory path to a script (e.g., a CGI script) that invokes a note display function  105  embodied within the API  100 . 
         [0046]    The note icon may further be a static or dynamic image, graphic or text that is visually associated the displayed information. 
         [0047]    At decision box  118 , the note search UI  108  determines whether, for example, an administrator has selected the displayed note icon for the participant or item. For example, the search UI  108  may register a “click” or “double-click” operation performed by the administrator utilizing a cursor control device (e.g., a mouse). If so, at block  120 , the method  110  displays a list of notes (or messages) for the located participant or item. As described above, user selection of the note icon, embedded in HTML document, may in one embodiment invoke a note display function  105  that retrieves all note records  60  for the located participant or item, and populates a note display UI  109  (e.g., HTML page) utilizing the retrieved note records  60 . 
         [0048]    The display of a note icon by the note search function  104  ensures that an administrator is presented with the option of retrieving notes, or messages, that administrators may have created with respect to a participant or item regardless of an original addressee of the note. As the note is associated with the subject thereof, as opposed to the addressor or addressee, it is ensured that any administrator accessing information concerning the subject (e.g., a participant or item) will be made aware of the existence of the note. Further, as the UI&#39;s may, in one embodiment, comprise markup language documents (e.g., HTML documents) that are viewable by a browser, traditional e-mail channels for communicating administrative notes may be avoided. 
         [0049]      FIG. 6  illustrates an exemplary embodiment of an HTML page generated by the note search UI  108 , and is shown to prompt a searcher (e.g., an administrator) for a search string in field  122 , the search string for example comprising the user ID of a participant. The searcher is further prompted to select either an exact user ID (or e-mail) match or an account ID search. 
         [0050]      FIG. 7  illustrates an exemplary embodiment of an HTML page generated by the note search UI  108  that provides certain information regarding a participant located by the search string into the field  122  of the search UI  108  shown in  FIG. 6 . An exemplary note icon  124 , which is associated with a URL, is displayed adjacent the user ID of the located participant. The search UI  108  also displays an account balance (outstanding), and hypertext links to past and present auctions in which the participant participated as either a buyer or seller, to bids that the participant may have placed for items and to an alias history. The UI  108  also provides an indication whether the participant is a “top seller” within the auction facility  10 . Finally, the UI  108  provides a number of user-selectable actions (e.g., reinstate) that invoke an administrative application  28 , such as any of those discussed above with reference to  FIG. 4 . 
         [0051]      FIG. 8  illustrates an exemplary embodiment of an HTML page generated by a creation UI  106  that allows a user, or an administrator, to reinstate a user of the auction facility  10 , following a suspension. The UI  106  may, in one embodiment, interact with a reinstate function (not shown) that records the reinstating of a user and that interacts with a note creation function  102  to automatically create a note concerning the reinstatement within the note table  48 . The UI  106  shown in  FIG. 8  may be generated responsive to user selection of a “reinstate” hypertext link  126  shown in  FIG. 7 . The UI  106  presents a user ID field  130  into which the administrator enters an identifier or e-mail address, a password field  132  into which the administrator enters a password, a user field  134  into which the administrator enters a user ID or e-mail address concerning the user to be reinstated, a “warning reason” drop-down menu  136  that contains a predetermined set of reasons why a user of the auction facility  10  may be warned (e.g., a list of common infractions), and a text field  140  into which the administrator can input further information regarding the reinstatement. For example, the administrator may indicate that a case of mistaken identity caused the relevant user to be blocked or removed from the auction facility  10 . The UI  106  also includes a “reinstate” button  142  that is user selectable to invoke a reinstate function, and a “clear form” button  144  that is user selectable to reset the contents of the fields  130 - 140 . 
         [0052]      FIG. 9  illustrates a further exemplary embodiment of an HTML page generated by the note search UI  108  that allows, for example, a user to perform a search specifically for notes regarding a participant or item of the auction facility  10 . To this end, the exemplary UI  108  includes an “about” field  150  into which an administrator may enter a user ID, an e-mail address or an item number to identify either a participant or item number to identify either a participant or an item. Alternatively, the administrator may leave the field  150  blank so that the search results are not filtered according to participant or item. 
         [0053]    A “note category” field  152  provides a drop-down menu of note categories that are user selectable to locate notes pertaining only to a specific category. For example, the drop-down menu presented within the field  152  may specify a “reinstate” category that is user selectable to identify notes pertaining to reinstatement actions formed by administrators. It will be appreciated that categories into which notes may be organized is dependent on the type of facility being administered, and also upon the design of the auction facility  10 . Accordingly, a wide variety of categories could be presented for selection as input to the “note category” field  152 . 
         [0054]      FIG. 10  is a flow chart illustrating an exemplary method  160  of creating a note, represented by a note record  60 , within the note table  48 . The method  160  commences with the invoking of the note creation function  102 . The note creation function  102  may be invoked by a user via any one of a number of administrative interfaces (e.g., interfaces to end an auction, suspend the seller, reinstate a seller, etc.). Alternatively, the note creation function  102  may be invoked automatically by an automated administrative function that, merely for example, performs a housekeeping function with respect to the database  23 . The note creation function  102  may also be invoked by a batch function that performs certain batch functions with respect to the database  23  (e.g., the pruning of inactive accounts, etc.). Examples of administrative applications that may invoke the note creation function  102  are provided in  FIG. 4 . 
         [0055]    At block  164 , the administrator inputs a user ID, or e-mail address. At block  166 , the administrator inputs a password, and at block  168  the administrator specifies a user, item or auction to which the relevant note pertains. The information inputted at blocks  164 ,  166  and  168  is subject to a validation operation by the note creation function  102 . 
         [0056]    At block  170 , the administrator may then input specific information relevant to the note. Merely for example, the administrator may specify whether a user is to be suspended, fees are to be credited to the seller, bidders on the auction are to be e-mailed regarding an auction, and what the message type is. The administrator may also input pertinent text information, and select further participants, items or auctions to which the note applies. 
         [0057]    At block  172 , the administrator then submits the note content via the API  100 . 
         [0058]    At decision block  176 , a determination is made as to whether the note is valid by, for example, performing validation checks on the information inputted at blocks  164 - 172 . If not, a rejection report is generated at block  178 . Alternatively, at block  180 , the API  100 , and specifically the note creation function  102 , creates a record in the database  23 , and specifically within the note table  48 , associated with the specified participant item or auction. At block  182 , an administrative function that invoked the note creation function  102  may perform other function specific operations (e.g., marking a user record as being suspended or removing an item from the auction facility  10  to update the database  23 ). The method  160  then ends at block  184 . 
         [0059]      FIGS. 11A-11E  show various exemplary UI&#39;s, in the form of HTML or other mark-up language pages, that may be presented to an administrator in the performance of the method  160 .  FIG. 11A  shows an administrative application interface  190 , utilizing which an administrator can select an administrative function to be performed. For example, via the interface  190 , an administrator may select to end an auction, end all auctions for a seller, reinstate a blocked auction after review, deny appeal on a blocked item, remove an item, request a temporary password for a user, or rebalance a user account. These applications may be invoked by user selection of appropriate hypertext  192 - 204 . 
         [0060]      FIG. 11B  illustrates an exemplary “end auction” UI  205 , in the form of an HTML document, via which an administrator may be prompt for information regarding an auction, or multiple auction, to be ended. The UI  205  may be presented in response to user selection of the hypertext  192  illustrated in  FIG. 11A . 
         [0061]    The UI  205  includes a user ID field  206 , a password field  208  and an “auctions to end” field  210 . An administrator may enter the identification numbers or codes for auctions to be entered into the field  210 . The administrator is further given the option to suspend a user, credit fees to a seller, and e-mail bidders on an auction by selection of the appropriate radio buttons in the fields  212 ,  214  and  216 . 
         [0062]    A “reason” field  218  includes a drop-down menu that presents a predetermined and authorized list of reasons for ending an auction for selection by the administrator. Finally, in the “text” field  220 , an administrator may enter additional text or description regarding the ending of the relevant auction or auctions. 
         [0063]      FIG. 11C  illustrates an exemplary embodiment of an “end member&#39;s auctions” user interface  224 , in the form of an HTML document, using which an administrator may end all auctions of a particular participant, member or user of the auction facility  10 . The UI  224  is similar to the UI  205  shown in  FIG. 11B , but differs in that an administrator may, via a “user ID” field  230  specifies the user ID, or e-mail address, of the user for which all auctions are to be ended. The UI  224  may, for example, be invoked by user selection of the hypertext  194  illustrated in  FIG. 11A . 
         [0064]      FIG. 11D  illustrates an exemplary “reinstate auction” UI  240 , in the form of an HTML document, utilizing which an administrator may specify that an auction be reinstated. The UI  240  includes an “auction to reinstate” file  242  into which an administrator may input the item number of the subject auction, or other identifying information. A “reason” field  244  presents a drop-down menu of a predetermined list of common or authorized reasons for reinstatement of an auction. The UI  240  may, merely for example, be invoked by user selection of the hypertext  196  illustrated in FIG.  11 AB 
         [0065]      FIG. 11E  illustrates an exemplary embodiment of an “appeal denied” UI  250 , in the form of an HTML document, utilizing which an administrator can create a note as to why an appeal against the ending of an auction, or suspension of a user, was denied by the relevant administrator or by an appeal mechanism of the auction facility  10 . The UI  250  represents a “blocked item” field  252 , into which the administrator inputs an item number, or other identifier, to specify an auction. A “reason” field  254  presents a button on a menu of common, or authorized, reasons for the denial of an appeal. 
         [0066]    Any of the UI&#39;s, or interfaces, discussed above may further include an “expiration” field, into which an administrator may input a time period within which, or date by which, a relevant note will expire. This information may then populate the expiration field  82  of a note record  60 . In a further embodiment, the expiration field  82  may be automatically populated by a housekeeping function. 
         [0067]      FIG. 12  shows a diagrammatic representation of machine in the exemplary form of a computer system  300  within which a set of instructions, for causing the machine to perform any one of the methodologies discussed above, may be executed. In alternative embodiments, the machine may comprise a network router, a network switch, a network bridge, Personal Digital Assistant (PDA), a cellular telephone, a web appliance or any machine capable of executing a sequence of instructions that specify actions to be taken by that machine. 
         [0068]    The computer system  300  includes a processor  302 , a main memory  304  and a static memory  306 , which communicate with each other via a bus  308 . The computer system  300  may further include a video display unit  310  (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system  300  also includes an alpha-numeric input device  312  (e.g. a keyboard), a cursor control device  314  (e.g. a mouse), a disk drive unit  316 , a signal generation device  318  (e.g. a speaker) and a network interface device  320 . 
         [0069]    The disk drive unit  316  includes a machine-readable medium  322  on which is stored a set of instructions (i.e., software)  324  embodying any one, or all, of the methodologies described above. The software  324  is also shown to reside, completely or at least partially, within the main memory  304  and/or within the processor  302 . The software  324  may further be transmitted or received via the network interface device  320 . For the purposes of this specification, the term “machine-readable medium” shall be taken to include any medium which is capable of storing or encoding a sequence of instructions for execution by the machine and that cause the machine to perform any one of the methodologies of the present invention. The term “machine-readable medium” shall accordingly be taken to included, but not be limited to, solid-state memories, optical and magnetic disks, and carrier wave signals. 
         [0070]    Thus, a method and system for communicating information within a network-based auction facility have been described. Although the present invention has been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.