RELATED APPLICATIONSThis application is a continuation of U.S. application Ser. No. 09/717,433, filed Nov. 20, 2000, entitled “Method and System for Dealing with Non-Paying Bidders Related to Network-Based Transactions,” which is incorporated by reference herein in its entirety.
FIELD OF THE INVENTIONThe present invention relates generally to the field of e-commerce. More particularly, the present invention relates to a method and system for dealing with non-paying bidders related to network-based transactions.
BACKGROUND OF THE INVENTIONA common type of network-based transaction is purchasing goods or services via a network-based transaction facility, e.g., a website on the Internet. One type of network-based transaction is an online-auction transaction. In an online-auction transaction, a seller offers an item for sale via an auction website in which a number of bidders access the website and bid for the item. A transaction is completed after the winning bidder pays for the item and the seller delivers the item to the winning bidder.
A typical problem associated with such a transaction is a winning bidder failing to follow through with the transaction. For example, the winning bidder may fail to pay for the auctioned item or provide a fraudulent check to purchase the item. In such a case, the bidder is referred to as a “non-paying bidder.” As a result of a failed transaction, the seller may request a refund for a fee that may have been charged by the network-based transaction facility to facilitate the transaction. Another problem that may occur is a seller falsely claiming that a transaction did not go through to obtain a refund when in fact a valid sale occurred.
Thus, there is a need to minimize the number of non-paying bidders and to minimize seller abuse in falsely claiming refunds. Furthermore, there is a need to track non-paying bidders and to minimize network-based transaction facility resources in tracking non-paying bidders.
SUMMARY OF THE INVENTIONA method and system for dealing with non-paying bidders related to network-based transactions are disclosed. For one embodiment, a submission of a complaint is submitted to a network-based facility. The complaint is related to a party in a failed a transaction. A resolution of the complaint is facilitated. A record associated with the party is updated if the complaint is not resolved. The record indicates a count of failed transactions related to the party. A refund request can also be facilitated if the complaint is not resolved.
Other features of the present invention will be apparent from the accompanying drawings and from the detailed description that follows.
BRIEF DESCRIPTION OF THE DRAWINGSThe present invention is illustrated by way of example and not intended to be limited by 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 non-paying bidder items table of the database illustrated inFIG. 2;
FIG. 4 is a diagrammatic representation of an exemplary non-paying bidders table of the database illustrated inFIG. 2;
FIG. 5 is a diagrammatic representation of an exemplary sellers complaint table of the database illustrated inFIG. 2;
FIG. 6 is a diagrammatic representation of an exemplary sellers final value fee request table of the database illustrated inFIG. 2;
FIG. 7 is a diagrammatic representation of an exemplary non-paying bidder appeal table of the database illustrated inFIG. 2;
FIGS. 8A through 8D are flow charts illustrating an exemplary operation for a network-based facility to handle non-paying bidders and to handle final value fee refund requests;
FIGS. 9A and 9B illustrate exemplary interfaces providing information about a non-paying bidder program;
FIGS. 10A and 10B illustrate exemplary interfaces for entering a non-paying bidder alert or complaint form;
FIG. 10C illustrates an exemplary interface indicating that a non-paying bidder alert or complaint form has been filed;
FIGS. 11A through 11C illustrate exemplary interfaces for entering a final value fee credit request form;
FIG. 12 illustrates an exemplary interface for entering a non-paying bidder appeal;
FIG. 13 illustrates an exemplary interface for providing a non-paying bidder appeal confirmation;
FIG. 14 illustrates an exemplary interface for providing a transaction backout profile; and
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 invention may be executed.
DETAILED DESCRIPTIONA method and system for dealing with non-paying bidders related to network-based transactions are described. For one embodiment, a submission of a complaint is submitted to a network-based facility. The complaint is related to a party in a failed a transaction. A resolution of the complaint is facilitated. A record associated with the party is updated if the complaint is not resolved. The record indicates a count of failed transactions related to the party. A refund request can also be facilitated if the complaint is not resolved.
The method and system described herein can reduce abuse by users filing false refund requests for failed transactions by allowing a user who fails to follow through in a transaction an opportunity to resolve or complete the transaction. Furthermore, the number of users failing to complete a transaction can be reduced by maintaining a record indicating a count of failed transactions related to the user. If the count exceeds a threshold, the user is suspended from participating in transactions on the network-based facility.
In the following embodiments, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details.
TerminologyIn the following embodiments, the term “transaction” or “transactions” refers to any communications between two or more entities and is to be construed to include, but limited to, commercial transactions including sale and purchase transactions, online-auction transactions and other like transactions.
Transaction FacilityFIG. 1 is a block diagram illustration of an exemplary network-basedtransaction facility100 in the form of an “Internet” network-basedauction facility110. While an exemplary embodiment of the present invention is described within the context of an auction facility, it will be appreciated by those skilled in the art that the invention will find application in many different types of computer-based, network-based, or e-commerce based facilities.
Theauction facility110 includes one or more of a number of types of front-end servers, namely pagesservers112 that deliver web pages (e.g., markup language documents), picturesservers114 that dynamically deliver images to be displayed within Web pages, listing servers116,CGI servers118 that provide an intelligent interface to the back-end offacility110, andsearch servers120 that handle search requests to thefacility110. Email servers121 provide, inter alia, automated email communications to users of thefacility110.Auction facility110 also includes administrative application(s) functions128 for providing functions for applications runningauction facility110.
The back-end servers include a database engine server122, asearch index server124 and a credit card data server126, each of which maintains and facilitates access torespective databases123,125,127, respectively.
The Internet-basedauction facility110 may be accessed by aclient program130, such as a browser (e.g., the Internet Explorer® distributed by Microsoft Corp. of Redmond, Wash.) that executes on aclient machine132 and accesses thefacility110 via a network such as, for example, theInternet134. Other examples of networks that a client may utilize to access theauction facility110 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 StructureFIG. 2 is a database diagram illustration of anexemplary database200, maintained by and accessed via the database engine server122, which at least partially implements and supports the network-basedauction facility110.Database123 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,database123 may be implemented as a collection of objects in an object-oriented database.
Central to thedatabase123 is a user table240, which contains a record for each user of theauction facility110. A user may operate as a seller, buyer, or both, within theauction facility110.Database123 also includes item tables242 that may be linked to the user table240. Specifically, tables242 include a seller item table244 and data items table246. A user record in user table240 may be linked to multiple items that are being, or have been, auctioned viaauction facility110. 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 tables242.Database123 also includes a note table248 populated with note records that may be linked to one or more item records within the item tables242 and/or to one or more user records with the user table240. Each note record within the note table248 may include, inter alia, a comment, description, history of other information pertaining to an item being auction viaauction facility100, or to a user ofauction facility110.
A number of other tables are also shown to be linked to the user table240, namely a user past aliases table250, a feedback table252, a feedback details table253, a transaction record table260, account balances table258, accounts table256, bids table254, seller final value fee request table270, seller final value fee request details table272, non-paying bidder complaints table262, and non-paying bidder complaint details table264.
Non-Paying Bidder Complaint/Final Value Fee Request Record TablesFIGS. 3-8 are diagrammatic representations of exemplary embodiments of transaction record tables that are populated with records or entries for non-paying bidder complaints and final value fee requests relating to failed transactions (e.g., failed Internet based auction transactions) that have been facilitated byauction facility110. Such transaction record tables may be stored in non-paying bidder complaints table262, non-paying bidder complaint details table264, seller final value fee request table270, seller final value fee request details272.
FIG. 3 is a diagrammatic representation of an exemplary non-paying bidder items table300 of the database illustrated inFIG. 2. Referring toFIG. 3, non-paying bidder (NPB) items table300 includes aitem no. column302, selleruser ID column304, NPBuser ID column306, reason for failedtransaction column308,notice date column310, andnotice reason column312.
Item no. column302 stores item identifiers of items involved in failed transactions. Selleruser ID column304 stores user IDs of sellers who auctioned an item initem no. column302. NPBuser ID column306 stores user IDs of buyers who did not follow through on a transaction related to the items identified initem no. column302. Reasons for failedtransaction column308 stores reasons why the transaction failed that may be given by a seller. For example, reasons may include a buyer failing to purchase an item or providing a fraudulent check to pay for the item.
Notice date column310 stores the date a notice was sent to the respective buyer identified in the NPBuser ID column306 that he/she has not completed the transaction for the item identified in the respectiveitem no. column302.Notice reason column312 stores the reasons why the notice was sent. For example, the notice can be sent because a seller filed a final value fee refund request or the seller filed a NPB alert against the buyer.
FIG. 4 is a diagrammatic representation of an exemplary non-paying bidders table400 of the database illustrated inFIG. 2. Referring toFIG. 4, non-paying bidders table400 includes a NPBuser ID column402,item no. column404,valid warning count406,NPB tick column408, reason forNPB tick column410, and suspendedstatus column412.
NPBuser ID column402 stores the user IDs of buyers in which a complaint has been filed. The buyers listed in NPBuser ID column402 are buyers involved in failed transactions.Item no. column404 stores identifiers of items involved in transactions in which the buyer listed in NPBuser ID column402 was the winning bidder and failed to complete the transaction for the item.
Validwarning count column406 stores a count value on the number of times the NPB received a warning for being a “non-paying bidder” or for failing to complete a transaction.NPB tick column408 stores the number of times the NPB has been involved in a failed transaction in which the NPB was at fault. Reason forNPB tick column410 stores the reasons for the NPB tick.Suspended status column412 stores the status of the NPB to participate on the network-facility. For example, after a certain number of NPB ticks, the NPB can be suspended from participating in an on-line auction on the network-based facility.
FIG. 5 is a diagrammatic representation of an exemplary sellers complaint table500 of the database illustrated inFIG. 2. Referring toFIG. 5, sellers complaint table500 includes a selleruser ID column502, NPBuser ID column504, date ofcomplaint column506, reason forcomplaint column508, and status ofcomplaint column510.
Selleruser ID column502 stores the user IDs of sellers filing NPB complaints. NPBuser ID column504 stores user IDs of buyers in which a NPB complaint has been filed against. Date ofcomplaint column506 stores the date in which the NPB complaint was filed. Reason forcomplaint column508 stores the reasons why the seller filed the NPB complaint. Status ofcomplaint column510 stores the status of the complaint. For example, the status can indicate that the complaint has been resolved or if it is pending.
FIG. 6 is a diagrammatic representation of an exemplary sellers final value fee (FVF) request table600 of the database illustrated inFIG. 2. Referring toFIG. 6, sellers FVF request table600 includes sellersuser ID column602, NPBuser ID column604,item no. column606, action desiredcolumn608, reason forFVF credit column610,credit date column612, andcredit amount column614.
Sellersuser ID column602 stores the user IDs of sellers filing a FVF refund request. NPBuser ID column604 stores the user IDs of the NPB related to the FVF refund request by the seller.Item no. column606 stores an identifier of the item related to the FVF refund request. Action desiredcolumn608 stores the requests of the seller. For the seller may request a refund or a credit for future transactions.
Reason forFVF credit column610 stores the reason for the credit. For one embodiment, the following reasons are not valid reasons for filing a FVF credit, which are: (1) the bidder paid, returned it and seller issued a refund; (2) Seller and Buyer mutually agreed not to complete the transaction; or (3) sale price to high bidder was lower than final high bid.Credit date column612 stores the date in which a refund or a credit for future transactions was given.Credit amount column614 stores the amount of the credit or refund given.
FIG. 7 is a diagrammatic representation of an exemplary non-paying bidder appeal table700 of the database illustrated inFIG. 2. Referring toFIG.7, NPB table700 includes anitem no. column702, selleruser ID column704, NPBuser ID column706, reason for failedtransaction column708, reason forappeal column710, and appealcode column712.
Item no. column702 stores item identifiers related to failed transactions. The failed transaction has caused an NPB to have a “tick” or count against him in which the NPB is considered at fault. Selleruser ID column304 stores user IDs of sellers who auctioned an item initem no. column302 and filed a NPB complaint or alert against the NPB. NPBuser ID column306 stores user IDs of buyers who did not follow through on a transaction related to the items identified initem no. column302.
Reasons for failedtransaction column308 stores reasons why the transaction failed. For example, reasons may include a buyer failing to pay for an item or providing a fraudulent check to pay for the item. Reason forappeal column710 stores reasons why the NPB is appealing a NPB tick. A valid reason for appeal can be that the NPB did pay for the item and the seller is providing a false complaint to obtain a FVF refund or credit. Theappeal code column712 stores codes related to the appeal. For example, the codes can indicate if the appeal is granted and the NPB tick is taken away or if the appeal is denied.
The above record tables are exemplary and additional column entries or tables can be used bynetwork facility110 to provide services such that users ofnetwork facility110 may file complaints for a bidder or buyer (“non-paying bidder”) who has failed to follow through on a transaction (e.g., an online auction sale). Furthermore, thenetwork facility100 can also provide a final value fee (FVF) refund request or credit service for sellers involved in a failed transaction. Thenetwork facility110 can also keep track of NPB and suspend the NPB if involved in more than a certain number of failed transactions.
In the following operations, a seller is able to file a complaint against a bidder (“non-paying bidder”) who has failed to follow through on a transaction (e.g., an auction sale) after a certain period of time from the end of the sale. A notification is provided to the non-paying bidder (“NPB”) so that the seller and a bidder can communicate with each other to resolve the complaint or complete the transaction. If the parties cannot resolve the complaint after a certain period of time, the seller is allowed to file a FVF refund request for the FVF that the seller may have paid to facilitate the sale on the network-based facility. A NPB count or “tick” will be maintained for every failed transaction in which the NPB is involved in.
Filing a Non-Paying Bidder Alert or ComplaintFIGS. 8A through 8D are flow charts illustrating anexemplary operation800 for a network-based facility to handle non-paying bidders and to handle final value fee refund requests. The followingexemplary operation800 can utilize the record tables ofFIGS. 3-7 and other information contained in the database as shown inFIG. 2.
Referring toFIG. 8A, for purposes of explanation,operation800 begins atoperation802 after an end of an auction. Atoperation804, a seller who was involved in a failed transaction with a buyer can file a non-paying bidder (NPB) complaint or alert. For one embodiment, the seller, however, must wait at least 7 calendar days before a complaint can be filed. To learn about the NPB program, the seller can access an interface such asinterface902 shown inFIG. 9A to learn more about the NPB program.
Atoperation806, if the seller does not wish to file a complaint or alert,operation800 ends. If the seller does wish to file a complaint,operation800 can continue tooperation826,862, and808. Atoperation808, a determination is made if the seller has waited at least 7 days and no more than 30 days. The waiting period is to give the bidder an opportunity to complete the transaction before the seller can file a complaint or request a final value fee refund or request.
If the seller has not waited at least 7 days and no more than 30 days,operation800 returns tooperation804. If after the 7 day waiting period, but before 30 days after end of auction, atoperation810, the seller may file a NPB complaint. For example, interfaces such asinterfaces1002 and1010, as shown inFIGS. 10A and 10B, can be presented to the seller. The seller can then enter information such as User ID, Password, and Item Number as shown inwindows1004 and1006. The seller can also enter reasons for the complaint as shown in window1012.
Atoperation812, the information entered by the seller is captured or stored in a database such as that shown inFIG. 2. An interface such asinterface1030 shown inFIG. 10C can be presented to the seller indicating that NPB complaint or alert has been completed.Operation800 then continues tooperation822 inFIG. 8B.
Referring toFIG. 8B, at operation822 a determination is made if the reasons for the complaint are one of the following:
- 1) bidder paid returned item and seller issued a refund;
- 2) the parties mutually agreed not to complete the transaction; or
- 3) sale price to high and bidder bid price was lower than final high bid.
If the reasons for the complaint are one of the above reasons,operation800 continues atoperation842 in FIG. se. If not,operation800 continues tooperation824.
Atoperation824, an email is sent to both bidder/buyer and seller informing the parties reason for complaint, item number, and that bidder will get a NPB tick if the complaint is not resolved. The buyer is informed that the seller has filed a complaint. If the buyer believes the seller has made false statements, the buyer can inform the network facility. For example, the buyer can send an email to a “safeharbor” within the network facility.
Atoperation826, the buyer and seller are asked to resolve differences among themselves. This notification can be a separate email or contained in the email ofoperation824. For one implementation, the email to the NPB can encourage the buyer to leave negative feedback for the seller if the buyer responded during the mediation period and the seller did not respond and is now filing a FVF credit request.
Atoperation828, a determination is made if the buyer and seller have resolved their differences, i.e., completed the transaction. If the parties have not resolved their differences,operation800 continues tooperation862 inFIG. 8D. If the parties do resolve their differences, atoperation830 the process ends. The seller cannot file a FVF refund request because the transaction has been completed and no FVF credit is given. Furthermore, the buyer is not given a NPB tick.
Filing a Final Value Fee Refund RequestReferring toFIG. 8C, if the reason for filing the complaint is one of the reasons stated inoperation822 ofFIG. 8B,operation800 continues tooperation842. Atoperation842, the seller is taken to an FVF online credit form such as that shown ininterfaces1102,1108, or1120 ofFIGS. 11A through 11C. For one implementation, the seller is not allowed to file a FVF credit until at least 10 days have passed since the seller filed the NPB complaint. Furthermore, the FVF credit request cannot be made more than 60 days after the end of auction
At this point, the seller can request a FVF refund or credit because transaction that was not completed for valid reasons. Atoperation844, a determination is made of the seller wants to file a FVF refund or credit request. At operation846, if the seller does not wish to file a FVF credit request, the seller can leaveinterfaces1102,1108, or1120 and the process ends. If, however, the seller does wish to file a FVF credit request,operation800 continues tooperation848.
Atoperation848, the seller's user ID, item number, and reasons for complaint can be auto-populated on the online form. Alternatively, the aforementioned information can be entered by the seller as shown inwindows1104 and1106 inFIG. 11A. The seller can then enter his/her password and how much was paid for the item inwindows1104 and1110,1122, and1124 as shown inFIGS. 11A through 11C.
Atoperation850, the FVF credit is automatically posted to seller's account. Buyer is not given a NPB tick because there was a valid reason on why the transaction was not completed. Atoperation852, an email is sent to the buyer (cc. Seller) that informs the buyer that seller has request FVF credit for reasons given. Ask buyer to email the “safeharbor” if this is not valid. For example, if the buyer did complete the transaction, then the seller is fraudulently request a FVF refund request/credit.
Atoperation854, a determination is made if the buyer has sent an email to the “safeharbor.” If no email is sent, atoperation856, the process ends. If the buyer does send an email to the safeharbor, atoperation858, the seller is not given a FVF credit and the process ends. Here, a further determination can be made by the network facility to inquire about the validity of the buyer's and seller's statements.
Filing a Non-Paying Bidder AppealReferring toFIG. 8D, atoperation862, a determination is made if a NPB complaint has been filed and if 10 days have elapsed since the NPB complaint was filed. If not,operation800 continues tooperation808 if not complaint has been filed and tooperation826 if 10 days have not elapsed.
If a NPB complaint has been field and 10 days or more have elapsed,operation800 continues tooperation864. Atoperation864, a determination is made if less than 60 days have elapsed since the end of the auction. If more than 60 days have elapsed, atoperation866,operation800 ends and no FVF credit request is filed. Here, approximately two months have passed since the auction, which exceeds a maximum time limit to file a FVF credit request.
If less than 60 days have elapsed since the end of the auction, atoperation868, a determination is made if the seller wants to file a FVF credit request. If the seller does not want to file a FVF credit request,operation800 ends atoperation866. If the seller does want to file a FVF credit request, atoperation870, the seller is taken to the FVF online credit form such as that shown ininterfaces1102,1108, or1120 ofFIGS. 11A through 11C. For one embodiment, the user ID, item no., and reason for the complaint are autopopulated on the FVF online form.
Atoperation872, after the seller completes the FVF online form, the FVF credit is automatically posted to the seller's account and a NPB tick is given to the NPB. For example, the seller's account can be credited within 24 hours of FVF credit request. The NPB is notified via email that a tick has been given and is given the opportunity to appeal the tick.
Atoperation874, a determination is made if the NPB wants to appeal the tick. If the NPB does not want to appeal the tick,operation800 continues tooperation830. If the NPB does want to appeal the tick, the NPB is taken to an online NPB appeal form such asinterface1202 shown inFIG. 12.
Atinterface1202, the NPB is given awindow1204 to enter a user ID and password and awindow1206 to enter the item number.Interface1202 also provides awindow1208 for the NPB to enter a message on why the tick should not be given to him. After the NPB completes the NPB appeal form, the network-based facility can give the NPB a confirmation such asinterface1302 shown inFIG. 13. Furthermore, the seller and NPB can access aninterface1402 shown inFIG. 14 to determine number of credit requests and NPB tick scores for users.
For one embodiment, the NPB is given a maximum number of ticks (e.g., 3 ticks) before the NPB is suspended from participating in online auctions. If the NPB tick goes from 3 to 2, the NPB can be reinstated. If the FVF credit for the seller is reversed, the NPB tick can later be reversed and the tick can be removed. For another embodiment, the NPB must receive at least three NPB ticks from three different sellers before that bidder is automatically suspended. If, for example, a bidder receives three NPB ticks from Seller A and one NPB tick from Seller B, the bidder should not be automatically suspended (NPB tick score=2). However, the bidder should be flagged so that customer support may manually review the bidder and have the ability to suspend the bidder.
Exemplary Computing SystemFIG. 15 is a diagrammatic representation of a machine, in an exemplary form of acomputer system1500, in which a set of instructions for causing the machine to perform any of the methodologies of the present invention 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.
Thecomputer system1500 includes aprocess1502, amain memory1504 and astatic memory1506, which communicate with each other via abus1508. Thecomputer system1500 may further include a video display unit1510 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). Thecomputer system1500 also includes an alpha-numeric input device1512 (e.g., a keyboard, a cursor control device1514 (e.g., a mouse), adisk drive unit1516, a signal generation device1520 (e.g., a speaker) and anetwork interface device1522.
Thedisk drive unit1516 includes a machine-readable medium1524 on which is stored a set of instructions (i.e., software)1526 embodying any one, or all, of the methodologies described above. Thesoftware1526 is also shown to reside, completely or at least partially, within themain memory1504 and/or withinprocessor1502. Thesoftware1526 may further be transmitted or received via thenetwork interface device1522. For 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 invention. The term “machine-readable medium” shall accordingly be taken to include, but no limited to, solid-state memories, optical and magnetic disks, and carrier wave signals.
Thus, a method and system for dealing with non-paying bidders related to network-based transactions have been described. In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.