System and method for unified dispute resolution

[0001] This application is related to U.S. patent application Ser. No. 11/195,578, filed Aug. 2, 2005, and entitled Method and System to Design a Dispute Resolution Process. The content of the aforementioned application is incorporated herein by reference.

[0002] The present application relates generally to the technical field of automated dispute resolution and, in one example, to a system and method to provide a unified interface to aggregate a plurality of disputes from two or more payment processing systems.

[0003] Commercial entities, such as buyers and sellers that enter into transactions involving goods and services in a network-based commerce system, sometimes disagree about the transactions. To resolve these disputes, one or more of the commercial entities may request the services of an online dispute resolution provider. Indeed, the party that requests the services, the complainant, may be unaware of the plurality of entities that may be involved in the ultimate settlement of such a dispute. As a result, the settlement of such disputes is very time consuming for all the parties involved.

[0022] A system and method for a unified dispute resolution process 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 disclosure. It will be evident, however, to one skilled in the art, that the present disclosure may be practiced without these specific details.

[0023] According to an aspect of the present disclosure, there is provided a system and method to provide an aggregation of disputes in a network-based commerce system. A network-based resolution module is configured to receive a plurality of disputes relating to transactions involving a common entity. The common entity may be a seller, a buyer, or some other commercial entity. The disputes may be associated with two or more payment processing systems. The system and method further provides a unified interface associated with the resolution module. The unified interface is configured to provide information relating to disputes associated with at least one of the two or more payment processing systems. The system and method may be implemented via instructions on a machine readable medium.

[0024] Such a dispute resolution system in a network-based commerce environment provides several benefits to participants in the network-based commerce environment. For example, for sellers and other merchants who have relationships with several merchant banks or other payment processing systems, the seller will not have to access a separate system, with different processes and interfaces, to settle disputes for each payment processing system. Rather, the present disclosure provides a system in which the seller can address all disputes in a single interface. Additionally, the present disclosure permits a seller to create dispute resolution rules, such as having the system automatically settle all disputes that relate to transactions that are less than a certain dollar amount. In this manner, the seller does not have to spend his time working on such disputes.

[0025] FIG. 1 is a network diagram depicting a system 10, according to an example embodiment of the present disclosure, having a client-server architecture. A commerce platform, in the example form of a network-based marketplace 12, provides server-side functionality, via a network 14 (e.g., the Internet) to one or more clients. FIG. 1 illustrates, for example, a web client 16 (e.g., a browser, such as the Internet Explorer browser developed by Microsoft Corporation of Redmond, Wash. State), and a programmatic client 18 executing on respective client machines 20 and 22.

[0026] Turning specifically to the network-based marketplace 12, an Application Program Interface (API) server 24 and a web server 26 are coupled to, and provide programmatic and web interfaces respectively to, one or more application servers 28. The application servers 28 host one or more marketplace applications 30 and payment applications 32. The application servers 28 are, in turn, shown to be coupled to one or more databases servers 34 that facilitate access to one or more databases 36.

[0027] The marketplace applications 30 provide a number of marketplace functions and services to users that access the marketplace 12. The payment applications 32 likewise provide a number of payment services and functions to users. The payment applications 30 may allow users to quantify for, and accumulate, value (e.g., in a commercial currency, such as the U.S. dollar, or a proprietary currency, such as “points”) in accounts, and then later to redeem the accumulated value for products (e.g., goods or services) that are made available via the marketplace applications 30. In addition, the payment applications may include component processes that may be utilized to settle disputes between users (e.g., auction winners/buyers and sellers) that have transacted items (e.g., goods and services). While the marketplace and payment applications 30 and 32 are shown in FIG. 1 to both form part of the network-based marketplace 12, it will be appreciated that, in alternative embodiments of the present disclosure, the payment applications 32 may form part of a payment service that is separate and distinct from the marketplace 12.

[0028] Further, while the system 10 shown in FIG. 1 employs a client-server architecture, the present disclosure is of course not limited to such an architecture, and could equally well find application in a distributed, or peer-to-peer, architecture system. The various marketplace and payment applications 30 and 32 could also be implemented as standalone software programs, which do not necessarily have networking capabilities.

[0029] The web client 16, it will be appreciated, accesses the various marketplace and payment applications 30 and 32 via the web interface supported by the web server 26. Similarly, the programmatic client 18 accesses the various services and functions provided by the marketplace and payment applications 30 and 32 via the programmatic interface provided by the API server 24. The programmatic client 18 may, for example, be a seller application (e.g., the TurboLister application developed by eBay Inc., of San Jose, Calif.) to enable sellers to author and manage listings on the marketplace 12 in an off-line manner, and to perform batch-mode communications between the programmatic client 18 and the network-based marketplace 12.

[0030] FIG. 1 also illustrates a third party application 38, executing on a third party server machine 40, as having programmatic access to the network-based marketplace 12 via the programmatic interface provided by the API server 24. For example, the third party application 38 may, utilizing information retrieved from the network-based marketplace 12, support one or more features or functions on a website hosted by the third party. The third party website may, for example, provide one or more promotional, marketplace or payment functions that are supported by the relevant applications of the network-based marketplace 12 or component processes that may be utilized to settle disputes between users (e.g., auction winners/buyers and sellers) that have transacted items on the network based marketplace 12.

[0031] FIG. 2 is a block diagram illustrating multiple marketplace and payment applications 30 that, in an example embodiment of the present disclosure, are provided as part of the network-based marketplace 12. The marketplace 12 may provide a number of listing and price-setting mechanisms whereby a seller may list goods or services for sale, a buyer can express interest in or indicate a desire to purchase such goods or services, and a price can be set for a transaction pertaining to the goods or services. To this end, the marketplace and payment applications 30 are shown to include one or more auction applications 44 which support auction-format listing and price setting mechanisms (e.g., English, Dutch, Vickrey, Chinese, Double, Reverse auctions etc.). The various auction applications 44 may also provide a number of features in support of such auction-format listings, such as a reserve price feature whereby a seller may specify a reserve price in connection with a listing and a proxy-bidding feature whereby a bidder may invoke automated proxy bidding.

[0032] A number of fixed-price applications 46 support fixed-price listing formats (e.g., the traditional classified advertisement-type listing or a catalogue listing) and buyout-type listings. Specifically, buyout-type listings (e.g., including the Buy-It-Now (BIN) technology developed by eBay Inc., of San Jose, Calif.) may be offered in conjunction with an auction-format listing, and allow a buyer to purchase goods or services, which are also being offered for sale via an auction, for a fixed-price that is typically higher than the starting price of the auction.

[0033] Store applications 48 allow sellers to group their listings within a “virtual” store, which may be branded and otherwise personalized by and for the sellers. Such a virtual store may also offer promotions, incentives and features that are specific and personalized to a relevant seller.

[0034] Reputation applications 50 allow parties that transact business utilizing the network-based marketplace 12 to establish, build and maintain reputations, which may be made available and published to potential trading partners. Consider that where, for example, the network-based marketplace 12 supports person-to-person trading, users may have no history or other reference information whereby the trustworthiness and credibility of potential trading partners may be assessed. The reputation applications 50 allow a user, for example through feedback provided by other transaction partners, to establish a reputation within the network-based marketplace 12 over time. Other potential trading partners may then reference such a reputation for the purposes of assessing credibility and trustworthiness. In an example embodiment a single feedback may include comment and a score (e.g., −1 to register negative feedback, 0 to register neutral feedback, and +1 to register positive feedback). Further, scores may be analyzed to generate a feedback rating that is associated with a user. Other users in the network-based marketplace may access the feedback rating to assess the reputation of the user.

[0035] Personalization applications 52 allow users of the marketplace 12 to personalize various aspects of their interactions with the marketplace 12. For example a user may, utilizing an appropriate personalization application 52, create a personalized reference page at which information regarding transactions to which the user is (or has been) a party may be viewed. Further, a personalization application 52 may enable a user to personalize listings and other aspects of their interactions with the marketplace 12 and other parties.

[0036] In an example embodiment, internationalization applications 54 may support a number of marketplaces that are customized, for example, for specific geographic regions. A version of the marketplace 12 may be customized for the United Kingdom, whereas another version of the marketplace 12 may be customized for the United States. Each of these versions may operate as an independent marketplace, or may be customized (or internationalized) presentations of a common underlying marketplace.

[0037] Navigation of the network-based marketplace 12 may be facilitated by one or more navigation applications 56. For example, a search application enables key word searches of listings published via the marketplace 12. A browse application allows users to browse various category, catalogue, or inventory data structures according to which listings may be classified within the marketplace 12. Various other navigation applications may be provided to supplement the search and browsing applications.

[0038] In order to make listings, available via the network-based marketplace 12, as visually informing and attractive as possible, the marketplace applications 30 may include one or more imaging applications 58 utilizing which users may upload images for inclusion within listings. An imaging application 58 also operates to incorporate images within viewed listings. The imaging applications 58 may also support one or more promotional features, such as image galleries that are presented to potential buyers. For example, sellers may pay an additional fee to have an image included within a gallery of images for promoted items.

[0039] Listing creation applications 60 allow sellers conveniently to author listings pertaining to goods or services that they wish to transact via the marketplace 12, and listing management applications 62 allow sellers to manage such listings. Specifically, where a particular seller has authored and/or published a large number of listings, the management of such listings may present a challenge. The listing management applications 62 provide a number of features (e.g., auto-relisting, inventory level monitors, etc.) to assist the seller in managing such listings. One or more post-listing management applications 64 also assist sellers with a number of activities that typically occur post-listing. For example, upon completion of an auction facilitated by one or more auction applications 44, a seller may wish to leave feedback regarding a particular buyer. To this end, a post-listing management application 64 may provide an interface to one or more reputation applications 50, so as to allow the seller conveniently to provide feedback regarding multiple buyers to the reputation applications 50.

[0040] Dispute resolution applications 66 provide mechanisms whereby disputes arising between transacting parties may be resolved. For example, the dispute resolution applications 66 may provide processes (e.g., dispute resolution wizard, component processes, a document management application, etc.) whereby the parties are automatically guided through a number of steps in an attempt to settle a dispute. The dispute may be settled by a third party provider. As disclosed in further detail later on in the disclosure, a third party may also provide a means to aggregate disputes from a plurality of payment processing systems into a unified interface.

[0041] A number of fraud prevention applications 68 implement various fraud detection and prevention mechanisms to reduce the occurrence of fraud within the marketplace 12.

[0042] Messaging applications 70 are responsible for the generation and delivery of messages to users of the network-based marketplace 12, such messages for example advising users regarding the status of listings at the marketplace 12 (e.g., providing “outbid” notices to bidders during an auction process or to provide promotional and merchandising information to users).

[0043] Merchandising applications 72 support various merchandising functions that are made available to sellers to enable sellers to increase sales via the marketplace 12. The merchandising applications 80 also operate the various merchandising features that may be invoked by sellers, and may monitor and track the success of merchandising strategies employed by sellers.

[0044] The network-based marketplace 12 itself, or one or more parties that transact via the marketplace 12, may operate loyalty programs that are supported by one or more loyalty/promotions applications 74. For example, a buyer may earn loyalty or promotions points for each transaction established and/or concluded with a particular seller, and be offered a reward for which accumulated loyalty points can be redeemed.

[0045] FIG. 3 is a high-level entity-relationship diagram, illustrating various tables 90 that may be maintained within the databases 36, and that are utilized by and support the marketplace and payment applications 30 and 32. A user table 92 contains a record for each registered user of the network-based marketplace 12, and may include identifier, address and financial instrument information pertaining to each such registered user. A user may, it will be appreciated, operate as a seller, a buyer, or both, within the network-based marketplace 12. In an example embodiment of the present disclosure, a buyer may be a user that has accumulated value (e.g., commercial or proprietary currency), and is then able to exchange the accumulated value for items that are offered for sale by the network-based marketplace 12.

[0046] The tables 90 also include an items table 94 in which are maintained item records for goods and services that are available to be, or have been, transacted via the marketplace 12. Each item record within the items table 94 may furthermore be linked to one or more user records within the user table 92, so as to associate a seller and one or more actual or potential buyers with each item record.

[0047] A transaction table 96 contains a record for each transaction (e.g., a purchase transaction) pertaining to items for which records exist within the items table 94.

[0048] An order table 98 is populated with order records, each order record being associated with an order. Each order, in turn, may be with respect to one or more transactions for which records exist within the transactions table 96.

[0049] Bid records within a bids table 100 each relate to a bid received at the network-based marketplace 12 in connection with an auction-format listing supported by an auction application 44. A feedback table 102 is utilized by one or more reputation applications 50, in an example embodiment, to construct and maintain reputation information concerning users. A history table 104 maintains a history of transactions to which a user has been a party. One or more attributes tables 106 record attribute information pertaining to items for which records exist within the items table 94. Considering only a single example of such an attribute, the attributes tables 106 may indicate a currency attribute associated with a particular item, the currency attribute table 108 identifying the currency of a price for the relevant item as specified in by a seller. A dispute resolution table 110 may store dispute information that may be utilized to characterize disputes along with various other information regarding disputes.

[0050] FIG. 4 is a block diagram illustrating the dispute resolution table 110, according to an example embodiment. The dispute resolution table 110 is shown to include multiple entries identified as dispute information 112. Each dispute information 112 may be associated to a dispute that is tracked by the network based marketplace 12. The dispute information 112 includes characterization information 114 that is utilized to characterize the dispute. The characterization information 114 includes an item number 116, a transaction number 118, a complainant user identification 120, a respondent user identification 122, an item defect (e.g., description of defected item) 124, a complaint description 126, a settlement amount 128, and a dispute type 130. In addition, the characterization information 114 is shown to include information that the user may have corrected including a corrected transaction date 132, a corrected amount paid 134, a corrected buyer paid 135, a corrected means of payment 136, and a corrected complainant 133. Finally, the characterization information 114 includes component process information 138. The item number 116 identifies an item that is associated with the dispute. The item number 116 may be utilized to access additional item information in the items table 94. The transaction number 118 identifies a transaction that is associated with the dispute. The transaction number 118 may be utilized to access additional transaction information in the transaction table 96. The complainant user identification 120 may be utilized to identify the complainant (e.g., that party that initially submits a complaint or dispute) which may be a user (e.g., buyer, seller, etc.) in the network-based marketplace 12. The complainant user identification 120 may be utilized to access additional user information in the user table 92. The respondent user identification 122 may be utilized to uniquely identify the respondent (e.g., responds to complaint) and to access additional user information in the user table 92. The item defect 124 may be a description of a defect of an item (e.g., text, slides, graph, photo, etc.). The complaint description 126 may be a description of the complaint entered by the complainant. The settlement amount 128 may be an amount of currency for which the complainant is willing to settle the dispute. The corrected transaction date 132 may be entered by the user to correct a transaction date retrieved by the network-based marketplace 12. The corrected amount paid 134 may be entered by the user to correct an amount paid retrieved by the network-based marketplace 12. The corrected buyer paid 135 may be entered by the buyer to correct a buyer paid flag (e.g., asserted if buyer has already paid) retrieved by the network-based marketplace 12. The corrected means of payment 136 may be entered by the buyer to correct a means of payment indication (e.g., visa credit card, check, etc.) retrieved by the network-based marketplace 12. The component process information 138 included information regarding component processes such as component processes 192 in FIG. 8.

[0051] FIG. 5 is a block diagram illustrating a transaction table 96, according to an example embodiment. The transaction table 96 includes multiple entries of transaction information 140. Each transaction information 140 entry is associated with a transaction in the network-based marketplace 12 and may include an item number 116, as previously described, seller user identification 142, buyer user identification 144, a transaction date 146, a transaction amount 148, buyer paid 150, and a means of payment 152. The seller user identification 142 may be utilized to identify the seller associated with the transaction. The seller user identification 142 may be utilized to access additional user information in the user table 92. The buyer user identification 144 may be utilized to identify the buyer associated with the transaction which may be a user in the network-based marketplace 12. The buyer user identification 144 may be utilized to access additional user information in the user table 92. The transaction date 146 may be the date the transaction was completed (e.g., date buyer agrees to pay or date an auction closes or date the buyer or bidder has placed the winning bid, etc.). The transaction amount 148 may be the amount of currency (e.g., US Dollars, English pounds, proprietary currency, etc.) agreed to be exchanged for the associated item (e.g., good or service) identified by the item number 116. The buyer paid 150 may be a buyer provided indication of whether the buyer has paid. The means of payment 152 may indicate the means of payment by the buyer (e.g., cash, check, visa credit card, payment service, etc.).

[0052] FIG. 6 is a block diagram illustrating a user table 92, according to an example embodiment. The user table 92 is shown to include multiple user information 154 entries. Each user information 154 entry is associated with a user (e.g., buyer/bidder, seller) that utilizes the network-based marketplace 12. The user information 154 entry is shown to include one or more transaction numbers 118, previously described, and automated settlement information 156. The automated settlement information 156 may be seller provided settlement information (e.g., monetary amounts) that may be automatically utilized by a monetary settlement component process to settle disputes. For example, a seller that transacts high volumes of a particular item may not be interested in becoming personally involved with a dispute that may be settled below a certain monetary value. In such instances, the seller may automatically provide offers in the form of monetary amounts that may be utilized by a monetary component process that compares demands (e.g. from the seller) with offers (e.g., from the buyer), typically in three rounds, to arrive at a settlement.

[0053] FIG. 7 is a block diagram illustrating an items table 94, according to an example embodiment. The items table 94 is shown to include multiple item information 157 entries. Each item information 157 entry is associated with an item listing (e.g., describing goods or services) that is utilized to present the item on the network-based marketplace 12. The item information 157 entry is shown to include an item title 158, an item description 160, an item category 162, an item number 116, as previously described, and a transaction number 118, as previously described. The item title 158, item description 160, and item category 162 are entered by the seller. In some embodiments more than a single item category 162 may be entered (e.g., snorkeling gear, swimming, recreation, sporting goods, etc.) for the same item. The item description may include text, graphics, and photographs.

[0054] FIG. 8 is a block diagram illustrating a dispute resolution system 169, according to an example embodiment. The dispute resolution system 169 is shown to include dispute resolution applications 66, a third party server 40 and marketplace and payment applications 30. The dispute resolution applications 66 include dispute resolution core applications 170, a third party provider interface 172, and a site application interface 174. The dispute resolution applications 66 are shown to communicate via the third party provider interface 172 with the 3^rd party server 40 that may execute component processes 192 and via the site applications interface 174 with marketplace and payment applications 30. The dispute resolution core applications 170 include a document management application 176, a workflow engine 178, a reporting and analytics application 180, an alerts and notifications application 182, a status management application 184, and a dispute resolution wizard 186. The document management application 176 may provide services to enable users and processes to upload or send in documents and other types of electronic assets (e.g., any type of digital media that is stored electronically) to support resolution processes. The workflow engine 178 represents disputes and executes component processes 192 in response to events (e.g., system timeouts, user actions including filing a complaint and other actions, etc.). Component process 192 may be discrete mechanisms to settle a dispute and may be completely or partially automated. Multiple component processes 192 may be selected by a complainant to settle a single dispute and a single component process 192 is usually associated with published procedures and time tables for completing tasks that contribute towards the resolution of a dispute. A completed component process 192 may or may not result in the settlement of a dispute. The component processes 192 may be provided by an internal provider (e.g., executing on the network-based marketplace 12, payment service, etc.) or an external provider (e.g., executing on the third party server 40 including a dispute resolution provider, payment service, etc.). The reporting and analytics application 180 provides users and administrators with reports including analysis pertaining to the processing of disputes, categories of disputes, status of disputes, and other dispute related processing. The reporting and analytics application 180 may also trigger alerts to external systems via the third party provider interface 172 and the site applications interface 174. The alerts and notifications application 182 communicate events and rules bases status notifications (e.g., emails, action alerts, pop ups, etc.) to the users (e.g., buyers/bidders, sellers). The status management application 184 may be used to provide users with a single area online for filing, checking on, and resolving all types of disputes and/or issues.

[0055] The dispute resolution wizard 186 enables a complainant to design a dispute resolution process from multiple component processes 192. The dispute resolution wizard 186 is shown to include a communicating module 188 and a processing module 190. The communicating module 188 receives information from a complainant that may be used to characterize the dispute and to access information in a database 36 that may be used to characterize the dispute. The processing module 190 may be used to determine if the characterized dispute is appropriate to settle with component processes 192, identify one or more component processes 192 to settle the dispute, and communicate user interfaces to the complainant that enable the complainant to select component processes 192 and their order of execution thereby designing a dispute resolution process.

[0056] FIG. 9 is a block diagram illustrating component processes 192, according to an example embodiment. The component processes 192 include a bid retraction component process 200, an unpaid item component process 202, a non-selling seller component process 204, an item not received component process 206, an item received not as described component process 208, an item received significantly not as described component process 210, a return policy disputes component process 212, a solution matching component process 214, a monetary settlement component process 216, a mediation component process 218, a non-binding arbitration component process 220, an arbitration component process 222, a feedback review component process 224, a mutual feedback withdrawal component process 226, an escrow related disputes component process, an expert evaluation component process 230, a negotiation component process 232, and a dispute aggregation process 234.

[0057] The bid retraction component process 200 is an automated dispute resolution process that may be initiated by a seller complainant in response to a bidder that enters a bid into an auction and retracts the bid just prior to the close of the auction. Indeed, the bidder may be a competitor that is attempting to keep other bidders out by entering a high bid that discourages other bidding.

[0058] The unpaid item component process 201 is an automated dispute resolution process that may be initiated by a seller complainant in response to a buyer that has agreed to the terms of a transaction (e.g., auction, sale, etc.) but may not have, subsequent to close of the transaction, sent payment, responded to e-mail or responded to telephone correspondence initiated by the seller.

[0059] The non-selling seller component process 204 is an automated dispute resolution process that may be initiated by a buyer complainant in response to a seller that refuses deliver an item (e.g., good or service) after the buyer and seller have completed the transaction.

[0060] The item not received component process 206 is an automated dispute resolution process that may be initiated by a buyer in response to not receiving an item (e.g., good or service) for a significant time after the buyer and seller have completed a transaction.

[0061] The item received not as described component process 208 is an automated dispute resolution process that may be initiated by a buyer complainant in response to receiving an item not as described in the listing. Similarly, the item received significantly not as described component process 210 is an automated dispute resolution processes that may be initiated by a buyer in response to receiving an item significantly not as described in the listing.

[0062] The return policy dispute component process 212 is an automated dispute resolution process that may be initiated by a buyer complainant in response to a seller that violates their own published return policy (e.g., a seller advertises a 30 day money back guarantee but later declines the accept a return of an item during this time frame).

[0063] The solution matching component process 214 is an automated dispute resolution process that may be initiated by a seller or buyer complainant to resolve a dispute. The solution matching component process 214 suggests solutions that may be implemented responsive to the consent of the complainant and respondent. For example, a buyer complainant and a seller respondent may agree to immediately settle a dispute regarding a damaged item by the seller refunding the purchase price and the buyer returning the item. In other words the solution matching component process 214 may ensure that the obvious and straightforward solutions to the dispute have been explored. The solution matching component process 214 may present multiple solutions to the complainant who may elect one or more of the proposed solutions. The respondent may agree to any one of the proposed solutions to settle the dispute.

[0064] The monetary settlement component process 216 is an automated dispute resolution process that may be initiated by a buyer or a seller complainant to settle a dispute for money (e.g., the Cybersettle application developed by Cybersettle, of White Plains, N.Y.). In an example embodiment, the complainant and respondent may enter offers and demands that are received by the monetary settlement component process 216. The party seeking money in exchange for settlement of the dispute typically enters three demands (e.g., monetary amount) that decrease in value. The party paying money in exchange for settlement of the dispute typically enters three offers that increase in value. The monetary settlement component process 216 automatically compares the offers and demands round by round. If the offer and demand associated with a round are within a published range of settlement then the dispute settles. Otherwise the monetary settlement component process 216 proceeds to the next round. If all of the offers and demands are not within a range of settlement, then the monetary settlement component process 216 keeps the offer and demand amounts confidential, allowing the participants to utilize another component process 192 to settle the dispute without having prejudiced their positions

[0065] The mediation component process 218 may be a fully automated dispute resolution process that may be initiated by a buyer or seller complainant to settle a dispute with mediation services. The mediation component process 218 may be utilized to resolve any number of different types of disputes and uses a mediator that interacts with the disputants (e.g., email, videoconference, instant messaging, etc., combinations thereof) to resolve the dispute. The mediator may be a human being or an automated process. The mediator seeks to elicit from the disputants a mutually acceptable resolution to the dispute but has no power to impose a resolution on the parties.

[0066] The non-binding arbitration component process 220 may be a fully automated dispute resolution process that may be utilized by a buyer or seller complainant to settle a dispute with arbitration services. The non-binding arbitration component process 220 uses an arbitrator that interacts with the disputants to settle the dispute. The arbitrator may be a human being or an automated process. The arbitrator interacts with the disputants (e.g., email, videoconference, instant messaging, etc., combinations thereof) who present their respective cases including arguments, documents, testimony, and other persuasive evidence. The arbitrator deliberates on the proffered evidence and arguments to render a non-binding decision on the parties. In other words the complainant and respondent are not obliged to follow the decision of the arbitrator.

[0067] The arbitration component process 222 may be a fully automated dispute resolution process that may be initiated by a buyer or seller complainant to resolve a dispute with arbitration services. The arbitration component process 222 may execute in the same manner as the non-binding arbitration component process 220; however, the arbitrator may render a binding decision on the complainant and respondent.

[0068] The feedback review component process 224 may be a fully automated dispute resolution process that may be initiated by a buyer or seller complainant to request an independent third party to review of feedback. The independent third party may be a human being or an automated process. The complainant may initiate the request because the complainant believes that the feedback is unfair or unwarranted and wants to protect their reputation. In an example embodiment, a feedback score may be removed based on the decision of the third party. In another embodiment, the feedback score and comment may be removed.

[0069] The mutual feedback withdrawal component process 226 may be a fully automated dispute resolution process that may be initiated by a buyer or seller complainant to remove mutual feedback (e.g., complainant authored feedback on the respondent and respondent authored feedback on the complainant). In an example embodiment, a feedback score may be withdrawn (e.g., not available for public inspection) based on consent of the complainant and respondent. In another embodiment, the feedback score and comment may be withdrawn.

[0070] The escrow related disputes component process 228 is an automated dispute resolution process that may be initiated by a buyer or seller complainant to resolve a dispute involving the use of an escrow service. An escrow service may be a licensed and regulated company that collects, holds, and sends a buyer's money to a seller according to instructions agreed on by both the buyer and seller. For example, the buyer may receive and approve the item from the seller within an agreed time frame and the escrow service may then send the payment to the seller.

[0071] The expert evaluation component process 230 is an automated dispute resolution process that may be initiated by a buyer or seller complainant to resolve a dispute with the aid of a third party who provides their personal, expert opinion as to a fair outcome to the dispute. The negotiation component process 232 is an automated dispute resolution process that may be utilized by a buyer or seller complainant to facilitate an exchange of messages between the parties with the intent of settling a dispute between them. The dispute aggregation process 234 provides a unified interface that aggregates the disputes, relating to a common entity, from two or more payment processing systems.

[0072] FIG. 10 is a block diagram of an example embodiment of a system 1000 to aggregate information relating to disputes from two or more payment processing systems. The system 1000 may be one of the component processes 192 of FIG. 8, as either part of the workflow engine 178 of the dispute resolution applications, or associated with a third party server 40.

[0073] The system 1000 of the example embodiment of FIG. 10 includes a resolution module 1025. The resolution module 1025 has associated with it a unified interface 1020. The resolution module 1025 is coupled to a plurality of payment processing systems 1030 through a network 1040. In one embodiment, the network 1040 is the Internet. In an embodiment, these payment processing systems 1030 may be a credit card or charge card processor such as Visa, Mastercard, Discover, and/or American Express. The payment processing systems may also be a third party, such as a merchant bank, that handles the processing of the credit or charge card for Visa, Mastercard, Discover, and/or American Express. The payment processing system 1030 may further be a web-based processing system that handles the payments of transactions in an electronic marketplace and/or for a web-based commerce site. An example of such a web-based processing system is PayPal®. FIG. 10 further illustrates that a common entity 1010 may have access to the resolution module 1025 via the unified interface 1020. Examples of common entities that may have access to the resolution module 1020 include an individual seller in an electronic marketplace, a seller with its own commercial website, a buyer in an electronic marketplace, a customer of a commercial website, a payment processing system, and an operator of the resolution module, just to name a few.

[0074] In an embodiment, the system 1000 of FIG. 10 is configured such that the resolution module receives information about a plurality of disputes relating to transactions involving a common entity such as a buyer, seller, operator, etc. The information regarding these disputes received by the resolution module 1025 originate from any one of a number of payment processing systems 1030. The payment processing system 1030 that handles a particular transaction depends on several factors including the type of credit card used in the transaction and the merchant bank associated with a commercial entity involved in the transaction. For example, for a web-based commercial site, a buyer may use one of several types of credit cards, and the owner of the web-based commercial site may have a separate merchant bank for each of those different types of credit cards. Moreover, a seller may have several different web sites offering for sale many different products. Each one of these web sites may have a different payment processing system for each different credit card or other means of payment. Therefore, when disputes arise relating to the many transactions associated with a common entity in a network-based commerce system, these disputes may be associated with a plurality of payment processing systems. To resolve these disputes, the seller, owner of a website, or other common entity has to work with each and every payment processing system to resolve these disputes. This is a very time consuming process for a merchant.

[0075] In an embodiment, the unified interface 1020 is configured to provide information relating to the disputes that are associated with the plurality of payment processing systems 1030. This information is provided to an owner of a web-based commercial site or other seller in a network-based commerce system. In another embodiment, this information is provided to a customer of a web-based commercial site or buyer in a network-based commerce system. In yet another embodiment, a third party operator of the resolution module 1025 has access to this information. The information provided to a customer or buyer may be limited to information relating to the customer or buyer's own transactions. In an embodiment, this information can be handled by the system by determining from the user table in FIG. 6, the transactions that are associated with a user. The transaction numbers from the user table can then be used to key into the dispute resolution table (FIG. 4). In a particular embodiment, a customer or buyer has access to the information relating to the dispute if the customer or buyer has a user account (FIG. 6, No. 154) or other association with the resolution module. Whether the customer or buyer has a user account or other association with the resolution module may be determined by the resolution module.

[0076] As disclosed above, these disputes may relate to a chargeback of a transaction in the network-based commerce system. Chargebacks may be caused by one or more of several factors, including, but not limited to the factors addressed by some of the modules in FIG. 9, for example, the item was not received (204) or the item received was not as described (208).

[0077] The resolution module 1025 may be configured to provide to the common entity, through the unified interface 1020, an ability to resolve a dispute. This ability to resolve the dispute may be invoked by any of the common entities involved in the transaction such as the buyer or the seller. In an embodiment, if the common entity indicates through the unified interface 1020 that it would like to resolve one or more disputes, the common entity is presented a user interface 1200A as that illustrated in FIG. 12A. The interface 1200A illustrates a list of disputed open chargebacks. The information provided by the interface includes the chargeback details 1210A, the payment date of the disputed transaction 1220A, the payment processing system 1230A that processed the disputed transaction, and a resolve field 1240A that contains a button at which the common entity can indicate that it would like to select the associated disputed transaction to resolve.

[0078] When the common entity selects a disputed transaction to resolve, the dispute resolution module 1025 displays on the unified interface 1020 an interface 1100 such as illustrated in FIG. 11. In the example of FIG. 11, the common entity is given the choice of four options to resolve the dispute. At 1110, the common entity can provide tracking information. This would include any information that proves that a seller sent the ordered goods or provided the ordered services to the buyer. At 1120, the common entity can provide evidence that the common entity refunded the buyer's purchase price. At 1130, the common entity can provide evidence other than tracking information which will help to resolve the dispute. At 1140, the common entity can choose to accept liability for the disputed transaction, which results in the funds being returned to the buyer.

[0079] In an embodiment, the resolution module 1025 may also display on the unified interface 1020 information relating to all of the resolved (closed) chargebacks. An example of such an interface 1200B is illustrated in FIG. 12B. The interface 1200B includes the chargeback details 1210B, the payment date 1220B of the transaction, the payment processing system 1230B that handled the transaction, and the outcome 1240B of the resolved dispute. For example, referring to FIG. 12B, transaction 1250B was automatically refunded to the buyer. So, in this instance, the merchant created a rule which caused this dispute to be handled automatically. Transaction 1255B remains disputed, so this dispute will then continue to work its way through the proper dispute channels. Transaction 1260B has been refunded to the buyer, and for transaction 1265B, the seller has accepted liability and the outcome will be changed to refunded when the funds are credited to the buyer.

[0080] In one example, the dispute resolution module permits the common entity to create dispute resolution rules. These rules may require participation by the parties of the transaction, and/or the rules may resolve certain disputes automatically without further participation by any party. FIG. 13 illustrates an example interface 1300 from which a user can create dispute resolution rules. For example, by selecting checkbox 1310 in FIG. 13, a seller or other merchant may create a rule that any chargeback whose amount is less than a certain dollar amount is to be automatically approved. If this checkbox is selected, the common entity also enters into the text field 1320 the threshold dollar amount under which a disputed transaction will be automatically refunded without any input needed on the part of the commercial entity. Such a rule cuts back on the number of disputes to which a seller must devote time, thereby saving the seller time and other resources. As another example, a seller may select the check box 1330 to set up the resolution module to automatically notify the seller via an email or other electronic communication when a chargeback is recorded against a prior transaction of the seller. One advantage of this set up is that a seller is notified in a real time manner of chargebacks. The seller can then address the chargebacks in a timely manner, and the chargebacks do not accumulate and are not reported to the seller only on a periodic basis.

[0081] FIG. 14 illustrates an example embodiment of a process 1400 for aggregating disputes involving a common entity, and that are associated with a plurality of payment processing systems. The process 1400, at operation 1410, receives into a resolution module 1025 a plurality of disputes relating to transactions involving a common entity. The plurality of disputes at 1410 are associated with two or more payment processing systems 1030. At operation 1420, information is provided, in the unified interface 1020, relating to disputes that are associated with at least one of the two or more payment processing systems 1030. Information may be provided that is associated with several of the payment processing systems, and information may be provided that relates to all of the payment processing systems with which a merchant or other common entity has transactions.

[0082] FIG. 15 illustrates another example embodiment of a process 1500 for aggregating disputes involving a common entity and that are associated with a plurality of payment processing systems 1030. The process 1500 includes the steps 1410 and 1420 from the process 1400 of FIG. 14, and includes several additional operations. At 1510, the common entity of operation 1410 includes a seller and/or a buyer. At operation 1515, information relating to the disputes that are associated with at least one of the plurality of payment processing systems is provided to a seller via the unified interface, and at operation 1520, information relating to the disputes that are associated with at least one of the plurality of payment processing systems are provided to a buyer. The information provided to such a buyer relates only to the buyer's own transactions.

[0083] At operation 1525, the unified interface is configured to determine whether a buyer has a user account with the resolution module. Then, at operation 1530, the unified interface provides the buyer access to the unified interface based on the user having a user account. At operation 1535, the disputes that are associated with at least one of the two or more payment processing systems relate to a chargeback.

[0084] At operation 1540, the unified interface provides to the common entity an ability to resolve the disputes associated with at least one of the two or more payment processing systems. At 1545, the dispute resolution module provides the ability to the common entity to resolve the disputes associated with at least one of the two or more payment processing systems by permitting the common entity to create dispute resolution rules. At 1550, the dispute resolution rules may include the ability to automatically accept a chargeback. A common entity may also configure, at 1555, the dispute resolution module to send a notification of a pending chargeback via an electronic communication. At 1560, the automatic acceptance of a chargeback relates to an approval of chargebacks that comprise an amount less than a threshold. At 1565, the unified interface provides to the common entity information relating to disputes that have been resolved.

[0085] FIG. 16 shows a diagrammatic representation of machine in the exemplary form of a computer system 1600 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0086] The exemplary computer system 1600 includes a processor 1602 (e.g., a central processing unit (CPU) a graphics processing unit (GPU) or both), a main memory 1604 and a static memory 1606, which communicate with each other via a bus 1608. The computer system 1600 may further include a video display unit 1610 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 1600 also includes an alphanumeric input device 1612 (e.g., a keyboard), a cursor control device 1614 (e.g., a mouse), a disk drive unit 1616, a signal generation device 1618 (e.g., a speaker) and a network interface device 1620.

[0087] The disk drive unit 1616 includes a machine-readable medium 1622 on which is stored one or more sets of instructions (e.g., software 1624) embodying any one or more of the methodologies or functions described herein. The software 1624 may also reside, completely or at least partially, within the main memory 1604 and/or within the processor 1602 during execution thereof by the computer system 1600, the main memory 1604 and the processor 1602 also constituting machine-readable media.

[0088] The software 1624 may further be transmitted or received over a network 1626 via the network interface device 1620.

[0089] While the machine-readable medium 1622 is shown in an exemplary embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.

[0090] In the foregoing detailed description, various features are grouped together in one or more examples or examples for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed examples of the invention require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed example. Thus the following claims are hereby incorporated into the detailed description of examples of the invention, with each claim standing on its own as a separate example. It is understood that the above description is intended to be illustrative, and not restrictive. It is intended to cover all alternatives, modifications and equivalents as may be included within the scope of the invention as defined in the appended claims. Many other examples will be apparent to those of skill in the art upon reviewing the above description. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein,” respectively. Moreover, the terms “first,” “second,” and “third,” etc., are used merely as labels, and are not intended to impose numerical requirements on their objects.

[0091] The Abstract is provided to comply with 37 C.F.R. §1.72(b) to allow the reader to quickly ascertain the nature and gist of the technical disclosure. The Abstract is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.