Abstract:
Systems and Methods to determine whether a single input interface includes comment information that is categorized. The system present a single input interface via a communications network. The single input interface includes a plurality of input mechanisms to facilitate user input of comment information and categorization information. The plurality of input mechanisms include a first input mechanism and a second input mechanism. The first input mechanism is to facilitate user input of comment information that pertains to a first event of a plurality of events. The second input mechanism is to facilitate user input of categorization information that categorizes the comment information pertaining to the first event. The plurality of input mechanism further include a third input mechanism and a fourth input mechanism. The third input mechanism is to facilitate user input of comment information that pertains to a second event of the plurality of events. The fourth input mechanism is to facilitate user input of categorization information that categorizes the comment information that pertains to the second event. Finally, the system determines whether the single input interface includes comment information that is categorized.

Description:
RELATED APPLICATIONS 
     This application is a continuation application and claims the priority benefits of U.S. application Ser. No. 11/758,196, filed Jun. 5, 2007, now U.S. Pat. No. 7,587,359 which is a continuation application that claims the priority benefits of U.S. application Ser. No. 09/515,575, filed Feb. 29, 2000, now U.S. Pat. No. 7,428,505 both of which are incorporated herein by reference. 
    
    
     TECHNICAL FIELD 
     The present application relates generally to data processing. 
     BACKGROUND 
     In addition to access convenience, one of the advantages offered by network-based transaction facilities (e.g., business-to-business, business-to-consumer and consumer-to-consumer Internet marketplaces and retailers) and on-line communities is that participants within such facilities or communities may provide feedback to the facility, to other users of the facility and to members of an on-line community regarding any number of topics. 
     For example, an Internet-based retailer may provide a feedback mechanism whereby customers may provide feedback, in the form of comments or opinions, regarding goods or services offered for sale by the retailer. An Internet-based bookstore may, for example, provide a feedback mechanism whereby comments or opinions regarding particular books may be submitted via a web site operated by the book retailer. Such comments are then displayed within a web page, pertaining to the relevant book, generated by the Internet-based book retailer. Such comments and feedback are useful in assisting a purchaser with a buying decision. 
     For users of a network-based transaction facility, such as an Internet-based auction facility, feedback regarding other users is particularly important for enhancing user trust of the transaction facility. Indeed, a history of positive feedback for a trader that routinely uses an Internet-based auction facility may be particularly valuable and useful in providing other traders with a degree of confidence regarding a specific trader. Accordingly, a positive feedback history may establish the credibility and trustworthiness of a particular trader within an on-line trading community. Similarly, a history of negative feedback may discourage other traders from transacting with a specific trader. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present application 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: 
         FIG. 1  is a block diagram illustrating an exemplary network-based transaction facility in the form of an internet-based auction facility. 
         FIG. 2  is a database diagram illustrating an exemplary database for the transaction facility. 
         FIG. 3  is a diagrammatic representation of an exemplary transaction record table of the database illustrated in  FIG. 2 . 
         FIG. 4  is a diagrammatic representation of an exemplary feedback table of the database illustrated in  FIG. 2 . 
         FIG. 5  is a diagrammatic representation of an exemplary feedback details table of the database illustrated in  FIG. 2 . 
         FIG. 6  illustrates an exemplary interface sequence, according to one embodiment, that may be implemented by the transaction facility for the purposes of harvesting feedback, comments, opinions or reviews. 
         FIGS. 7A-7B  are flow charts illustrating an exemplary method of harvesting feedback, comments or reviews pertaining to transactions facilitated by a network-based transaction facility. 
         FIG. 8  illustrates an exemplary logon interface for accessing a feedback mechanism of the transaction facility. 
         FIG. 9  is a flow chart illustrating an exemplary method of displaying a user interface to harvest feedback, comments and opinions pertaining to multiple items. 
         FIG. 10  illustrates an exemplary “exceeds threshold” multiple feedback interface. 
         FIG. 11  illustrates an exemplary filtered multiple feedback interface, that may follow the “exceeds threshold” interface following filtering of transactions. 
         FIG. 12  illustrates an exemplary “does not exceed threshold” feedback interface. 
         FIG. 13  illustrates an exemplary “confirmation” interface. 
         FIG. 14  is an object diagram illustrating exemplary objects of the transaction facility that may be utilized to harvest multiple feedbacks, opinions or comments from users of a transaction facility. 
         FIG. 15  is a diagrammatic representation of a machine, in an exemplary form of a computer system, in which a set of instructions for causing the machine to perform any of the methodologies of the present application may be executed. 
     
    
    
     DETAILED DESCRIPTION 
     A method and system for harvesting feedback information, comments and opinions regarding multiple items from users of a network-based transaction 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 application. It will be evident, however, to one skilled in the art that the present application may be practiced without these specific details. 
     Terminology 
     For the purposes of the present specification, the term “transaction” shall be taken to include any communications between two or more entities and shall be construed to include, but not be limited to, commercial transactions including sale and purchase transactions, auctions and the like. 
     Transaction Facility 
       FIG. 1  is block diagram illustrating an exemplary network-based transaction facility in the form of an Internet-based auction facility  10 . While an exemplary embodiment of the present application is described within the context of an auction facility, it will be appreciated by those skilled in the art that the application will find application in many different types of computer-based, and network-based, commerce facilities. 
     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 . 
     The back-end servers 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 Internet-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 . Other examples of networks that a client may utilize to access the auction facility  10  include a wide area network (WAN), a local area network (LAN), a wireless network (e.g., a cellular network), or the Plain Old Telephone Service (POTS) network. 
     Database Structure 
       FIG. 2  is a database diagram illustrating an exemplary database  23 , maintain by and accessed via the database engine server  22 , which at least partially implements and supports the auction facility  10 . The database  23  may, in one embodiment, be implemented as a relational database, and includes a number of tables having entries, or records, that are linked by indices and keys. In an alternative embodiment, the database  23  may be implemented as collection of objects in an object-oriented database. 
     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 tables  42  include a seller items table  44  and a bidder 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 indicates whether the user is a seller or a bidder (or buyer) with respect to items for which records exist within 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 auction via the auction facility  10 , or to a user of the auction facility  10 . 
     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 feedback details table  53 , a bids table  54 , an accounts table  56 , an account balances table  58  and a transaction record table  60 . 
       FIG. 3  is a diagrammatic representation of an exemplary embodiment of the transaction record table  60  that is populated with records, or entries, for completed, or ended, transactions (e.g., auctions) that have been facilitated by the auction facility  10 . The table  60  includes a transaction identifier column  62  that stores a unique transaction identifier for each entry, and an end date column  64  that stores a date value indicating, for example, a date on which a transaction was established. A bidder column  66  stores a user identifier for a bidder (or a purchaser), the user identifier comprising a pointer to further user information stored in the user table  40 . Similarly, a seller column  68  stores, for each entry, a user identifier for a seller within the relevant transaction. An item number column  70  stores, for each entry, an item number identifying the goods or service being transacted, and a title column  72  stores, for each entry, a descriptive title for the relevant transaction or for the item being transacted. 
     It should be noted that, in one embodiment, an entry is only created in the transaction record table  60  for transactions that have been established, for example, by the conclusion of an auction process, or by some other offer and acceptance mechanism between the purchaser and the seller. 
       FIG. 4  is a diagrammatic representation of an exemplary embodiment of the feedback table  52 . The feedback table  52  stores summary information regarding feedback for users of the auction facility  10 . The table  52  includes a user identifier column  74  that stores, for each entry, a user identifier providing a pointer to the user table  40 . A total score column  76  stores, for each user entry, a total number of feedback comments (e.g., negative, positive and neutral), received for the relevant user. A total negative column  78  stores, for each user entry, the total number of negative feedback comments for the relevant user, and a total positive column  80  similarly stores, for each user entry, the total number of positive feedback comments received for that user. A number of retractions column  82  stores, for each user entry, the number of threads that the relevant user has retracted from auctions. 
       FIG. 5  is a diagrammatic representation of one embodiment of the feedback details table  53 , that is populated with entries reflecting the details of each feedback comment or opinion submitted by a user to the auction facility  10  regarding another user or item involved in a transaction. In one exemplary embodiment, users are only permitted to provide feedback pertaining to a transaction upon conclusion of that transaction. The feedback information may pertain to a further user that participated in the transaction, or to the object (e.g., goods or services) that was the subject of the transaction. In an alternative embodiment, for example, comments or opinions are provided regarding an item or service that is offered for sale or regarding an event. In these cases it will be appreciated that a transaction is necessarily required for feedback to be permitted. 
     The feedback details table  53  includes an item number column  84  including an item identifier that points to a record within the item tables  42 . A comment column  86  stores, for each entry, the actual text of the feedback, comment, or opinion. A type column  88 , in one embodiment, stores indication as to whether the comment is positive, negative or neutral. A date column  90  stores, for each entry, the date on which the feedback, comment or opinion was delivered. A response column  92  stores the text of a response submitted by a user (e.g., a user to which the original comment pertained) in response to the comment text stored in column  86 . Similarly, a rebuttal column  94  stores the text of a rebuttal to such a response. 
     A commentator column  96  stores the user identifier of the user that submitted the original comment, stored in column  86 , for the entry. A commentee column  98  stores the user identifier of the user to which comment may have been directed. 
     It will be appreciated that further dates and other descriptive information may also populate the feedback details table  53 . 
     Multiple Feedback Items 
     In order to facilitate the convenient provision of feedback by users of the auction facility  10  pertaining to a transaction (e.g., an auction transaction) in which a user participated, the present application proposes a method and system whereby a user may conveniently provide feedback pertaining to multiple transactions. By facilitating the harvesting of multiple feedbacks for a multiple transaction via a unified mechanism, the application addresses the inconvenience of tracking down multiple auctions via other indirect channels or mechanisms that may be provided by web site. In one embodiment, the present application facilitates the provision of multiple feedbacks pertaining to respective multiple transactions via a single interface (e.g., a markup language page interface). While the present application is discussed within the context of providing feeding regarding transactions in which a user participated, it will readily be appreciated that the present application may be extended to providing multiple feedbacks, comments or opinions pertaining to respective multiple products, events or other entities. For example, a book reviewer, utilizing the teachings of the present application, may conveniently provide comments, reviews or opinions pertaining to multiple books. 
       FIG. 6  shows an interface sequence  100 , according to an exemplary embodiment of the present application, that may be implemented by the auction facility  10  for the purposes of harvesting feedback (or comments, opinions or reviews) from users of the auction facility  10 . The auction facility  10  may, in one embodiment, only permit a user to provide feedback pertaining to a transaction within which that user was a participant and which has been established or completed. For example, a transaction may be established through the identification of the winner of an auction, which creates the implicit understanding that the established transaction, between the purchaser (i.e., the winning bidder) and the seller, will be completed by performance of the reciprocal obligations underlying the transaction. 
     The sequence  100  of interfaces shown in  FIG. 6  will be described with reference to the flow chart shown in  FIGS. 7A and 7B . Exemplary representations of the various interfaces included with the sequence  100  are shown in  FIGS. 8-12 . 
     On the ending of an auction, and the identification of winning bidder, the auction facility  10 , via the e-mail servers  21 , issues an end-of-auction e-mail  102  to both the winning bidder and the seller advising both parties of the outcome of the auction, and providing respective contact details to allow the parties to contact each others. 
     The interface sequence  100  commences with a logon interface  108  through which a user of the facility  10  provides at least a user identifier and associated password. The logon interface  108  may be accessed, in one embodiment, via three mechanisms, namely an end-of-auction e-mail  102 , a view item (auction ended) interface  104  or a feedback services interface  106 , each of which comprises a markup language document (e.g., HTML document) including a hypertext link to an object (which will be described in further details below) that generates the logon interface  108  as well as further interfaces of the sequence  100 . The end-of-auction e-mail  102 , as noted above, is communicated by the e-mail servers  21  of the auction facility  10  to both a winning bidder and a seller upon the end of the auction process, the e-mail  102  notifying respective parties about the end of the auction and also providing contact details. The view item (auction ended) interface  104  is presented to a user, at conclusion of an auction, when seeking further information regarding the item that was the subject of the auction. For example, upon conclusion of an auction, a textual description of the subject of the auction may be hypertext linked to generate the interface  104 . The feedback services interface  106  may be accessed, for example, through a site navigation menu or toolbar that presents the option to a user of leaving feedback. The feedback services interface  106  is typically used to leave feedback where a user does not know the item number identifying an item or where a user wishes to view feedback concerning multiple auctions within which the user has been a participant within a predetermined period of time (e.g., the past 60 days). 
     The interface  108 , and subsequent interfaces  110 - 116 , are generated by a collection of objects (or methods), exemplary embodiments of which are illustrated in  FIG. 14 . Specifically, a logon interface  108  is generated by a “LeaveFeedbackToMultipleUsersShow” object  118 . The object  118  is also responsible for generating a “threshold exceeded” multiple feedback interface  110 , a filtered multiple feedback interface  112 , a “does not exceed threshold” feedback interface  114  and a confirmation interface  116 , as will be described in further detail below. To this end, the object  118  issues calls to a “LeaveFeedbackToMultipleUsers” object  120  that is responsible for actually recording feedback inputted via the interfaces  108 - 116  to the database  23 , and specifically the feedback and feedback details tables  52  and  53 . The object  118  also issues calls to a “GetSellerListForFeedback” object  122  that retrieves a list of sellers and items from the transaction record table  60 , for a clearing user identified by a specific user identifier. The object  122  includes a “UserItemRecord” vector  126  that is used as a container for the retrieved user and item information, the contents of the vector  126  being released to the object  118 . 
     The object  118  similarly issues a call to a “GetBidderListForFeedback” object  124  that retrieves a list of bidders and items from the transaction record table  60  of the database  23  where the bidders have both items from a specific user identified by an inputted user identifier. The object  124  similarly uses the “UserItemRecord” vector to pass bidder and item information to the object  118 . 
     The interfaces  108 - 116  will now be described within the context of a method  128 , according to one embodiment of the present application, of harvesting feedbacks, comments or opinions regarding multiple items from users of a network-based transaction facility. The method  128  is illustrated by the flow chart indicated in  FIGS. 7A and 7B . 
     The method  128  commences with a logon confirmation operation at block  130  performed utilizing a user identifier and a password. Specifically, the logon interface  108 , an exemplary embodiment of which is illustrated in  FIG. 8 , provides a user identifier field  180  and password field  182  into which a user may enter a user identifier and password to enable the logon confirmation operation at block  130 . The logon interface  108  illustrated in  FIG. 8  also includes a further target user identifier field  184 , into which a commentator user (identified by the user ID entered into fields  180 ) can specify the user identifier of a further user to which the feedback, or comments, are applicable. An item number field  186  also allows a commentator user to specify a specific item number (e.g., identifying an auction) if the feedback that the commentator user wishes to leave is to be directed towards a specific item. Input into the fields  184  and  186  is optional, and may function as filter criteria so that only a limited number of information items are presented in a subsequent multiple feedback interface. 
     Returning to  FIG. 7A , at block  132 , the object  118  issues calls to the “GetSellerListForFeedback” object  122  and the “GetBidderListForFeedback” object  124  to retrieve a list comprising multiple completed transactions for which the commentator user was either a successful bidder or seller. The objects  122  and  124  retrieve the relevant transaction information from the transaction record table  60  of the database  23 , and only retrieve transaction records for which no feedback has been left and which were established within a predetermined time period (e.g., the past 60 days). To this end, the objects  122  and  124  may identify records within the transaction record table  60  for which the feedback column  73  indicates that no feedback has been left, and transaction records for which date information included within the end date column  64  identifies the transaction has been established within the predetermined time period. 
     In one embodiment, the predetermined time period may be a default value that is automatically specified. In an alternative embodiment, a “time frame” input field may be provided within the logon interface  108 , utilizing which a commentator user may specify the predetermined time period. 
     At decision box  134 , the object  118  makes a determination as to whether more than a predetermined number (e.g., 25) transaction records are retrieved from the transaction record table  60  at block  132 . Following a positive determination at decision box  134 , at block  136 , the object  118  retrieves a first template (e.g., an ISAPI page) that provides for pagination and includes a filter field, as will be described in further detail below. Following a negative determination at decision box  134 , the object  118  retrieves a second template (e.g., an ISAPI page) that, while facilitating pagination, does not provide a filter field. 
     At block  138 , the template retrieved at block  136  or  140  is populated by ISAPI code, utilizing the contents of the “UserItemRecord” vectors  126  returned by the objects  122  and/or  124  to generate a feedback interface (e.g., the multiple feedback interface  110  or  114 ). 
     At block  142 , the feedback interface generated at block  138  (e.g., HTML code) is communicated, via the Internet  34 , to the client program  30  (e.g., a browser) for display. 
     At decision box  144 , a determination is made as to whether a filter criterion has been applied to the transaction records by a commentator user. If so, at block  146 , the object  118  may issue fresh calls to the objects  122  and  124  to retrieve a modified list of transaction and user information. In an alternative embodiment, the object  118  may simply discard objects (or vectors) previously returned by the objects  122  and  124  that do not meet the filter criteria. 
     At block  148 , feedback information, comments or opinions are received at the auction facility  10  from the client program  30  and specifically from the relevant interface communicated at block  142 . The feedback information may, in one embodiment, include a number of feedback items, each feedback item including date information specifying a date on which the feedback was provided, comment information providing the actual textual content of the feedback, type information indicating whether the feedback is positive, negative or neutral, user identifier information identifying both the commentator and the target (or commentee) users and any other pertinent information. In exemplary embodiments, which are further described below, the feedback interfaces may comprise markup language documents (e.g., HTML pages) that include radio buttons or check boxes that may be utilized to identify whether a feedback item is provided with respect to an underlying information item (e.g., an auction) and that may also be utilized to identify the type of feedback being provided (e.g., positive, negative or neutral). 
     At block  150 , the object  118  makes a call to the “LeaveFeedbackToMultipleUsers” object  120  to create multiple instances of the object  120 , each object containing the details of each of the feedback items received at block  148 . Accordingly, instances of the object  120  may be viewed as containers for each of the feedback items. 
     Proceeding to  FIG. 7B , at decision box  190 , a determination is made as to whether any of the feedback has been categorized via the commentator user as being of a negative or neutral type. If so, at block  192 , the object  118  generates the confirmation interface  116  (e.g., in the form of an HTML document) that is communicated from the auction facility  10  to the client program  30 . The confirmation interface  116  prompts the commentator user for confirmation regarding any negative or neutral comments. At decision box  194 , a determination is made as to whether all negative or neutral feedback comments have been confirmed. If not, the unconfirmed feedback is deleted at block  196 . Following a positive determination at decision box  194 , or following a negative determination at decision box  190 , or following completion of block  196 , the method proceeds to block  152 , where the object  118  issues an ISAPI call to an error_check function (not illustrated) that comprises a kernel module, and that performs a number of checks with respect to each feedback item, embodied within an instance of the object  120 . For example, the error_check function may determine whether the commentator, or target, user has been suspended from the auction facility  10 , whether feedback has already been submitted for the respective transaction, whether the commentator user has been a member of the auction facility  10  for less than predetermined time (e.g., five days) or whether a reserve price has been met for the relevant item (or transaction) to which the feedback comment pertains. If any of the conditions embodied within the error_check function are not met, the relevant feedback comment is deleted, for example by deleting the instance of the object  120  embodying the feedback comment. 
     At block  154 , ISAPI calls are issued from each of the objects  120  to populate the database  23 , and more specifically the feedback table  52  and the feedback details table  53 , with the information contained in the instances of the objects  120 , which operation is then actually performed at block  156 . The method  128  then ends. 
     Having now described server-side operations with respect to  FIGS. 7A and 7B , a description is now provided of an exemplary method  200  of displaying a user interface to harvest feedback, comments or opinions pertaining to multiple items (e.g., transactions). The method  200  shall be described within the context of the interfaces  110 ,  112  and  114  illustrated in  FIG. 6  and with reference to a flowchart illustrated in  FIG. 9 . 
     As stated above with respect to  FIG. 7A , at block  142 , a server may communicate a feedback interface over the communications network to a client program  30  (e.g., a browser) for display. Accordingly, the method  200  commences at block  202  with the receipt of a feedback interface in the form of a markup language document. The feedback interface may be, depending on the number of transactions, the “exceeds thresholds” multiple feedback interface  110  or the “does not exceed threshold” multiple feedback interface  114 . The feedback interface, in one embodiment, comprises a markup language document (e.g., an HTML document). 
     At block  204 , the client program  30  then proceeds to display transaction identifier information for a plurality of transactions within a single interface.  FIG. 10  provides an exemplary embodiment of the “exceeds threshold” multiple feedback interface  110 , and the transaction identifier information is shown to include user identifier information  230 , identifying the other party (e.g., the winning bidder or the seller) involved in the transaction, an item identifier providing an item number (or code) identifying the subject matter of the transaction, an item description  234  providing an alpha-numeric description of the subject of the transaction, ended date information  236 , indicating the date on which the transaction was established through the ending of the auction process. 
     At block  206 , a feedback input field  238  is displayed to indicate an association between the input field and the transaction identifier information. For example, referring again to the exemplary feedback interface  110  shown in  FIG. 10 , a feedback input field  238  is displayed on the interface  110  adjacent the transaction identifier information. The feedback input field  238  can receive both textual and numeric input. In an alternative embodiment, a drop-down menu may be provided to input one of a selected set of comments into the feedback input field  238 . 
     At block  208 , the interface then receives user-inputted feedback information (e.g., comments or opinions) via the feedback input field  238 . This feedback may be provided by an alpha-numeric input device, such as a keyboard, or by voice recognition software. In an alternative embodiment of the application, the input field  238  may be replaced by a voice recording mechanism that allows the commentator user to leave voice feedback by initiating a recording process. 
     At block  210 , the method  200  displays a type input mechanism adjacent the identifier information for each transaction, the type input mechanism allowing a commentator user to specify type information (e.g., positive, negative or neutral) feedback for the relevant transaction. Referring again to  FIG. 10 , an exemplary feedback type input  240  is shown to include three radio buttons, one of which is selectable to identify the input into the feedback input field  238  as being positive, negative or neutral. Accordingly, at block  212 , the interface  110  receives user-inputted type information via the feedback type input  240 . 
     At block  214 , the method  200  displays a “skip” input  242 , in the exemplary form of a radio button or check box, adjacent the identification information for each transaction displayed within the interface.  FIG. 10  shows an exemplary skip input  242  comprising a radio button that is user-selectable to indicate that the commentator user does not wish to provide feedback regarding the relevant transaction. In an alternative embodiment, a check box may be provided to allow user indication that no feedback is being provided. 
     As is well known in the art, within HTML a check box or radio button is defined by TYPE, NAME and VALUE specifiers, where the TYPE specifier specifies either a check box or a radio button, the NAME specifier specifies a variable where a return value will be stored and the VALUE specifier stores what will be returned in the variable if the check box is checked, or the radio button is selected. Accordingly, feedback type and skip indications may be communicated from the interface  110  in pairs to an ISAPI function implemented by the objects as described above. Each information pair may comprise, for example, a name and a value. 
     At block  216 , the interface  110  receives the user inputted skip information (or identification) via the skip input  242 . 
     At decision box  218 , a determination is made as to whether the user selects a “submit” button, in the form of a leave feedback button  245  as shown on  FIG. 10 , to communicate the information inputted via the interface  110  to the server side. If not, the method  200  loops through blocks  204  -  216 . Alternatively, if the user does select the “submit” button at decision box  218 , then processing continues at operation  220  with the field identifier and field content information (e.g., feedback, type information and skip information) being communicated in pairs from the client program  30  to the server side. The method  200  then ends at block  222 . 
     User Interfaces 
     Further descriptions of exemplary user interfaces will now be described with reference to  FIGS. 10-13 . While the exemplary interfaces are described as comprising markup language documents displayed by a browser, it will be appreciated that the described interfaces could comprise user interfaces presented by any Windows® client application or stand-alone application, and need not necessarily comprise markup language documents. 
       FIG. 10 , as described above, illustrates an exemplary “exceeds threshold” feedback interface  110  that provides a predetermined maximum number (e.g.,  25 ) of discrete feedback windows  244 , each window  244  being dedicated to specific transactions or items. Each feedback window  244  includes transaction (or item) identification information  232  a feedback type input  240 , a feedback skip input  242  and a feedback input field  238 . Accordingly, a collection of feedback windows  244 , all displayed in a single interface  110 , allow a commentator to provide feedback pertaining to multiple transactions or items in a convenient manner without having to advance through a series of distinct interfaces. 
     The number of feedback windows  244  displayed in a single interface is limited (e.g.,  25 ), and accordingly the interface  110  provides retreat and advance buttons  246  and  248  that allow a commentator user to retreat to a previous collection of feedback windows  244 , or advance to a subsequent collection of feedback windows  244 . Further illustrated is a “leave feedback” button  245  to leave feedback for all selected items on the page. 
     The “exceeds threshold” feedback interface  110  furthermore includes a filter criteria input field  250 , into which a commentator user may input a user identifier, or item number, to limit the number of transactions, or items, pertaining to which feedback is to be submitted. For example, where the number of transactions for which the commentator may leave feedback exceeds a predetermined threshold (e.g., 50), the filter allows a commentator user to reduce the number of transactions by specifying only transactions involving a particular user or pertaining to a specific item. In alternative embodiments, the filter criteria may comprise a keyword on which a search is done to locate any transactions for which the descriptions contain relevant keywords. The filter mechanism underlying the filter criteria input field  250  allows a commentator user conveniently to limit the number of feedbacks displayed within an interface, and also conveniently to identify specific transactions for which the commentator user wishes to leave feedback. 
     To this end,  FIG. 11  illustrates an exemplary filtered multiple feedback interface  112  that may follow the “exceeds threshold” feedback interface  110  following filtering of the transactions presented in the interface  110 . 
       FIG. 12  illustrates an exemplary “does not exceed threshold” feedback interface  114 , which is substantially similar to the filtered multiple feedback interface  112 , but does not include the retreat and advance buttons  246  and  248 . It will also be noted that the interface  114  does not provide a filter criteria input field  250 . 
       FIG. 13  illustrates an exemplary embodiment of the confirmation interface  116 , described above with reference to  FIG. 6 . 
     In summary, it will be appreciated that the above described interfaces, and underlying technologies, provide a convenient vehicle for the inputting of feedback, comments or opinions regarding multiple items, or transactions, via a single user interface. 
       FIG. 15  shows a diagrammatic representation of a 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. 
     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  320  (e.g. a speaker) and a network interface device  322   
     The disk drive unit  316  includes a machine-readable medium  324  on which is stored a set of instructions (i.e., software)  326  embodying any one, or all, of the methodologies described above. The software  326  is also shown to reside, completely or at least partially, within the main memory  304  and/or within the processor  302 . The software  326  may farther be transmitted or received via the network interface device  322 . For the purposes of this specification, the term “machine-readable medium” shall be taken to include any medium that 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 application. The term “machine-readable medium” shall accordingly be taken to included, but not be limited to, solid-state memories, and optical and magnetic disks. 
     Thus, a method and system for harvesting feedback information, comments, and opinions regarding multiple items from users of a network-based transaction facility have been described. Although the present application 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 application. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.