RELATED APPLICATIONSThis application is a continuation of U.S. patent application Ser. No. 09/827,132, entitled “METHOD AND SYSTEM AUTOMATICALLY TO REMIND PARTIES TO A NETWORK-BASED TRANSACTION TO COMPLY WITH OBLIGATIONS ESTABLISHED UNDER A TRANSACTION AGREEMENT” filed on Apr. 3, 2001, and which is incorporated herein in its entirety.
FIELDThe present subject matter relates generally to the field of electronic commerce and, more specifically, to reminding a party to a network-based commerce transaction to comply with obligations established in terms of a transaction agreement.
BRIEF DESCRIPTION OF THE DRAWINGSThe present subject matter 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-basedauction facility10.
FIG. 2 is a database diagram illustrating an exemplary database, maintained and accessed via a database engine server, which at least partially implements and supports the auction facility.
FIG. 3 is a representation of an item table, according to an exemplary embodiment of the present subject matter.
FIG. 4 is a flowchart illustrating a method, according to exemplary embodiment of the present subject matter, of automatically presented a remind option to party to commerce transaction, the party being able to exercise the remind option to remind a for the party to comply with obligations imposed in terms of the commerce transaction.
FIG. 5 is a flowchart illustrating a method, according to exemplary embodiment of the present subject matter, of issuing a reminder to a party to a commerce transaction to comply with obligations imposed in terms of the transaction agreement.
FIG. 6 illustrates an exemplary user interface that contains a listing of offerings that are the subjects of commerce transactions, and illustrates the display of reminder icons, in various states and associated with each of the entries of the listing.
FIG. 7 illustrating an exemplary confirmation page that is presented to a seller to confirm the content of a payment reminder communication to be sent to a buyer.
FIG. 8 illustrates an exemplary reminder e-mail that may be communicated to a buyer that has participated in a successful Chinese auction facilitated by an auction facility.
FIG. 9 is a diagrammatic representation of a machine in the exemplary for the computer system within which a set of instructions for causing machine to perform any one of the methodologies of the subject matter may be executed.
DETAILED DESCRIPTIONSystems and methods for providing a reminder option associated with an obligation are described herein. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present subject matter. It will be evident, however, to one skilled in the art that the present subject matter may be practiced without these specific details.
Commerce interactions conducted over an electronic communication network (e.g., the Internet), which may be referred to as electronic commerce (e-commerce), may conclude with the establishment of a commercial transaction between a buyer and a seller for the purchase and exchange of goods and/or services in return for value. Electronic commerce, in which the example embodiments of present subject matter may be practiced, may include a number of markets, including the so-called consumer-to-consumer (C2C), business-to-consumer (B2C) and business-to-business (B2B) markets.
Within the consumer-to-consumer and business-to-business markets, network-based commerce marketplaces may operate example auctions described herein. Example market operators may further facilitate example fixed-price transaction mechanisms for the establishment of commerce transactions between buyers and sellers (e.g., the Buy-It-Now feature offered by eBay, Inc.).
Interactions between the buyer and seller may be limited to interactions within the constraints of a transaction mechanism (e.g., an auction process or fixed price purchase process) provided by the electronic marketplace. Example marketplaces may provide parties to a transaction with the option of maintaining a degree of anonymity with respect to another party. For example, e-mail and address information concerning a potential party to a transaction may not be revealed to other parties.
According to example embodiments described herein, there is provided a method to facilitate a network-based commerce transaction. The establishment of a commerce transaction agreement between parties for the purchase of an offering may impose an obligation on the parties. In various example embodiments, during a predetermined time interval following an establishment of an agreement, a reminder display element may be presented to one or more parties in a first state to indicate that a reminder option is unavailable. Following expiration of the predetermined time interval, the reminder display element may be presented to the one or more parties, in a second state, to indicate that the reminder option is available. For some example embodiments, the reminder display element may be presented to the one or more parties in the first state based on the reminder option being exercised more than a predetermined number of times.
Other features of the present subject matter will be apparent from the accompanying drawings and from the remaining detailed description below.
TerminologyFor 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 commercial transactions including sale and purchase transactions, auctions and the like.
Transaction FacilityFIG. 1 is block diagram illustrating an exemplary network-based commerce facility in the form of an Internet-basedauction facility10. While an exemplary embodiment of the present subject matter is described within the context of an auction facility, the subject matter will find application in many different types of computer-based, and network-based, commerce facilities.
Theauction facility10 includes one or more of a number of types of front-end servers, namelypage servers12 that deliver web pages (e.g., markup language documents),picture servers14 that dynamically deliver images to be displayed within Web pages, listingservers16,CGI servers18 that provide an intelligent interface to the back-end offacility10, andsearch servers20 that handle search requests to thefacility10.E-mail servers21 provide, inter alia, automated e-mail communications to users of thefacility10. Thepage servers12,picture servers14,CGI servers18,search service20,e-mail servers21 anddatabase engine server22 may individually, or in combination, act as a communication engine to facilitate communications between, for example, theclient machine32 and the network-basedauction facility10.
The back-end servers include adatabase engine server22, asearch index server24 and a creditcard database server26, each of which maintains and facilitates access to a respective database.
The Internet-basedauction facility10 may be accessed by aclient program30, such as a browser (e.g., the Internet Explorer distributed by Microsoft Corp. of Redmond, Wash.) that executes on aclient machine32 and accesses thefacility10 via a network such as, for example, the Internet34. Other examples of networks that a client may utilize to access theauction facility10 include a wide area network (WAN), a local area network (LAN), a wireless network (e.g., a cellular network), or the Public Switched Telephone Network (PSTN) network.
Database StructureFIG. 2 is a database diagram illustrating anexemplary database23, maintain by and accessed via thedatabase engine server22, which at least partially implements and supports theauction facility10. Thedatabase23 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, thedatabase23 may be implemented as a collection of objects in an object-oriented database.
Central to thedatabase23 is a user table40, which contains a record for each user of theauction facility10. A user may operate as a seller, buyer, or both, within theauction facility10. Thedatabase23 also includes items tables42 that may be linked to the user table40. The items tables42 may include a seller items table44 and a bidder items table46. A user record in the user table40 may be linked to multiple items that are being, or have been, auctioned or otherwise offered for sale via thefacility10. A link indicates whether the user is a seller or a bidder (or buyer) with respect to items for which records exist within the items tables42.
Thedatabase23 also includes one or more category tables47. Each record within the category table47 describes a respective category. In one embodiment, a specific category table47 describes multiple, hierarchical category structures, and includes multiple category records, each of which describes the context of a particular category within the one of the multiple hierarchical category structures. For example, the category table47 may describe a number of real, or actual, categories to which item records, within the items tables42, may be linked.
Thedatabase23 also includes a note table48 populated with note records that may be linked to one or more item records within the items tables42 and/or to one or more user records within the user table40. Each note record within the table48 may include, inter alia, a comment, description, history or other information pertaining to an item being auction via theauction facility10, or to a user of theauction facility10.
A number of other tables are also shown to be linked to the user table40, namely a user past aliases table50, a feedback table52, a feedback details table53, a bids table54, an accounts table56, an account balances table58 and a transaction record table60.
FIG. 3 is a diagrammatic representation of an items table42, according to an exemplary embodiment of the present subject matter. The items table42 is shown to define a number of fields for each record that describes an item being offered for sale via theauction facility10. Aclose date field62 records the date and time for which an auction for the relevant item will end and at which a successful bidder may be identified. A reminder sentfield64 within each record, in one embodiment, stores a flag indicating whether a payment reminder has automatically been sent by theauction facility10 to a successful bidder (or buyer). The mechanism for the communication of such a reminder is described in further detail below.
In addition to the close date and reminder sentfields62 and64, the items table42 includes an item identifier, description, category identifier, price, reserve price, seller identifier, one or more bidder identifiers and list date information for a particular item.
FIG. 4 is a flow chart illustrating amethod70, according to an exemplary embodiment of the present subject matter, of automatically presenting a reminder option to a party to a commerce transaction, the party being able to exercise the reminder option to remind a further party to comply with obligations establish in terms of a commerce transaction agreement. In theexemplary method70, the presentation of the reminder option is the display of a reminder button on a user graphical interface. The reminder button is selectable by the party to invoke a process at theauction facility10 whereby an e-mail is sent to a further party to the transaction (e.g., a buyer) to remind the buyer to provide a monetary payment to satisfy obligations imposed by an concluded purchase and sale transaction (or agreement).
Returning now specifically to the flow chart, at block72 a user (e.g., a seller) may issue a request to theauction facility10 for a list of offerings (e.g., items) that the user has made available for purchase via theauction facility10. This list may specify items for which an auction process is ongoing (i.e., a close date not yet been reached), and items for which the auction process has completed.
FIG. 6 illustrates an exemplary user interface that includes an “items I am selling”portion102 and “items I have sold”portion104. The “items I am selling”portion102 contains a listing of items for which the auction process is ongoing. The “items I have sold”portion104 contains a listing of items for which the auction process is completed, and for which a successful bidder (or buyer) has been identified.
Returning to themethod70, upon receipt of the user request at theauction facility10, a loop variable N is set to 0, the loop variable N indicating the first of N offerings (e.g., items) that the user may be selling or have sold.
Atdecision box76, a determination is made as to whether a particular offering N is the subject of a successful and completed transaction and whether a reminder e-mail has been issued from theauction facility10 to the buyer of the offering. A successfully completed transaction, within the context of theauction facility10, may be an offering for which the auction process has completed and a particular bidder has been identified as a highest, and therefore successful, bidder. Alternatively, theauction facility10 may offer a “fixed price” option whereby a transaction may be concluded when a buyer agrees to purchase the offering at a fixed, predetermined price. In one embodiment, the exercise of the “fixed price” option may automatically terminate any auction process to which the offering is subject, and successfully establish a transaction agreement. In either case, whether by an auction process or a fixed price purchase process, a transaction agreement may be concluded.
The determination of whether an e-mail reminder has been sent for a particular offering is determined by performing a look-up on the items table42 to determine whether the reminder sentfield64 for the relevant record indicates that a reminder e-mail has been sent. This look-up on the items table42 is performed by thedatabase engine server22 responsive to a query from theCGI servers18.
Following a positive determination atdecision box76, themethod70 proceeds to block78, where areminder button106, to be incorporated within a user interface generated by theauction facility10 and displayed to the user, is generated in an “off” or disabled state. The “off” state from thereminder button106 is included within the user interface to be displayed in association with descriptive information regarding the offering.FIG. 6 illustrates anexemplary reminder button106 in the “off” state.
On the other hand, following a negative determination atdecision box76, at decision block80 a further determination is made as to whether a transaction with respect to the offering N has been successfully concluded and whether a close date (i.e., a date and time at which a transaction process terminates) less the current date (e.g., a current date and time) is less than a predetermined period (e.g., three days). The close date for a transaction process may, in one exemplary embodiment, be determined by performing a look-up on the items table42 to extract the pertinent information from theclose date field62.
If it is determined that less than the predetermined time period (or interval) has passed since the close date, at block82 areminder button108 is generated and incorporated into the user interface in a “greyed out” state, which indicates that the reminder option has been temporarily disabled pending expiration of the predetermined time period. The temporary disablement of the reminder button pending expiration of the predetermined time period is advantageous in that it prevents a seller from issuing a reminder email to a buyer until after a reasonable time period has passed for the buyer to make payment to the seller.
FIG. 6 illustrates a “greyed out”reminder button108 for an item that has recently been sold. It will be noted that an indication is provided below the “greyed out”reminder button108 that indicates the reminder option will be available to the seller within three days after establishment of the transaction.
Following a negative determination atdecision block80, a determination is made atdecision block84 as to whether a successful transaction has been completed. Because of the conditions imposed at decision blocks76 and80, a positive determination atdecision block84 indicates that a transaction has been successfully concluded, a reminder e-mail has as not as yet been sent, and the predetermined period after establishment of the transaction has passed. Accordingly, following a positive determination atdecision block84, atblock86 an “on” or enabledreminder button110 is identified for incorporation within the user interface. The “on”reminder button110 is again located to be displayed in conjunction with descriptive information concerning the relevant offering N.FIG. 6 illustrates an exemplary “on”reminder button110 which, in addition to being visually differentiated from the “off”reminder button106 or the “greyed out”reminder button108, has a Uniform Resource Locator (URL) associated therewith that is communicated back to theauction facility10 upon user selection thereof. This URL, in one embodiment, invokes a process whereby theCGI server18 and thee-mail server21 of theauction facility10 generate and transmit an e-mail message to a buyer concluded under a transaction pertaining to the offering.
Following a negative determination at decision block84 (e.g., if the auction process for offering N has not yet completed or has been terminated for another reason), or upon completion of operations performed at any one ofblocks78,82,86, themethod70 proceeds todecision block88 where a determination is made as to whether there are any further offerings, currently for sale, or for which transactions have been completed, for the relevant user (seller). If so, atblock90, the variable N is incremented, and themethod70 loops back todecision block76 and the above described criteria are again applied to a next offering to determine the state of a reminder button to be displayed in association with descriptive information concerning the next offering. Alternatively, if there are no further offerings for the relevant user, themethod70 then ends atblock92 with the completion of the generation of the user interface to be presented to the user (e.g., the seller) listing offerings by that particular seller. In one embodiment, the generateduser interface100 constitutes a markup language document, which then may be communicated from thepage servers12 of theauction facility10, via theInternet34, for display by a client program30 (e.g., a browser) executing on theclient machine32.
The determination at any of the decision blocks76,80 and84 as to whether a transaction process has been successfully concluded depends on the relevant transaction process. For example, the transaction process may be a fixed price process whereby a buyer established a transaction by accepting the offer of the offering at a fixed price. Alternatively, the transaction process may be an auction process. Exemplary auction processes may be a conventional auction process, a Dutch auction process, a Chinese auction process or any other auction process whereby a transaction agreement is established between one or more buyers and one or more sellers for the sale and purchase of one or more offerings (e.g., items or services).
FIG. 5 is a flow chart illustrating amethod120, according to an exemplary embodiment of the present subject matter, of issuing a reminder to a party to a transaction agreement to comply with obligations imposed by the transaction agreement. Themethod120 shall be described within the context of theexemplary user interface100 shown inFIG. 6 as generated by themethod70 described above with reference toFIG. 4.
Atblock122, theauction facility10 detects user (e.g., seller) selection of an enabled or “on”reminder button110 as presented to the user within theinterface100. As described above, theenabled reminder button110 may have a URL associated therewith, this URL being communicated to theauction facility10 responsive to user selection of thebutton110. The URL identifies a process (e.g., a CGI process to be executed by the CGI server18) that implements a number of the below described operations.
Atblock124, responsive to the user selection of the enabledreminder button110, a look-up is performed within thedatabase23, and specifically on the user table40, to obtain an e-mail address and other details (e.g., name, physical address) regarding one or more buyers that are parties to a transaction agreement associated with the selectedreminder button110.
Atblock126, a further look-up is similarly performed in thedatabase23, and specifically an items table42, to retrieve details regarding the transaction agreement associated with the selected reminder button. The offering details may, for example, be derived from a record for the relevant transaction within the items table42, as illustrated inFIG. 3.
Atblock128, apage server12 populates a reminder e-mail template with the offering details retrieved atblock126, and addresses the e-mail utilizing the buyer e-mail address retrieved atblock124.
Atblock130, theauction facility10, and specifically thepage server12, delivers a confirmation (or “preview”) page (e.g., in the form of an HTML document). Following receipt of confirmation from the seller atblock132, the e-mail generated and addressed atblock128 is transmitted to the relevant buyer by ane-mail server21.
Atblock134, a flag is set within the reminder sentfield64 of the record for the relevant transaction as maintained in the items table42. Themethod120 then ends atblock136.
The content of the reminder e-mail template that is populated atblock128, and also the number of buyers to which the reminder e-mail is sent, are dependent upon the nature of the commerce transaction. For example, where the commerce transaction was concluded under a “Dutch auction” process, a single auction process may have imposed obligations on multiple buyers to each buy one or more offerings of a batch of offerings presented for sale.FIG. 7 illustrates anexemplary confirmation page150, according to an exemplary embodiment of the present subject matter, that constitutes an HTML document that may be communicated to a seller atblock130 of themethod120 described above with reference toFIG. 5. Theconfirmation page150 pertains to a Dutch auction, and accordingly provides a list of buyers, indicated at152, to which the reminder e-mail may be communicated. Theconfirmation page150 also provides a listing, at154, of buyers who have already received an e-mail reminder pertaining to the relevant commerce transaction. The confirmation page also includestext156 to be included within the e-mail reminder,seller contact information158 that may optionally been included within the e-mail reminder, accepted payment methods160, apayment address option162, a “copy e-mail to seller”option164 and a “send reminder”option166.
With respect to thetext156, this is retrieved from a database table (not shown) that stores default reminder text for the relevant seller. In one embodiment, the seller is also able to edit thetext156 within theconfirmation page150.
With respect to theseller contact information158, it will be noted that a checkbox is provided adjacent each of the seller contact information items. In this way, the seller can selectively identify personal information (e.g., contact information) to be included within an e-mail reminder to a buyer. Theseller contact information158 is retrieved from the user table40 by aCGI server18, responsive to a request to generate theconfirmation page150.
FIG. 8 shows an exemplary reminder e-mail that may be communicated to a buyer, atblock132 ofFIG. 5, that participated in a successful Chinese auction facilitated by theauction facility10.
The above-described embodiment of the present subject matter assumes a central network-basedauction facility10 that maintains acentral database23 of users and offerings. It will however be appreciated that the present subject matter may also be applied to a peer-to-peer trading system implemented as applications executing on distributed computer systems that communicate via a network. In this case, themethods70 and120 discussed above with reference toFIGS. 4 and 5 may be executed, for example, by an application program residing on a computer system of a seller.
The reminder that is communicated to one or more buyers atblock132 inFIG. 5 is also described, in the above exemplary embodiment, as being an e-mail message. However, in alternative embodiments, the reminder may be any electronic communication including a page message, a Wireless Access Protocol (WAP) message, a Short Message Service (SMS) message, or a display on a mark-up language document (e.g., a reminder on a web-based calendar or the like).
In the above described exemplary embodiment, the communication of a reminder to a buyer to comply with an obligation to make a payment to a seller has been described. In alternative exemplary embodiment, a reminder may be communicated to a seller to comply with an obligation to ship or supply an offering to a buyer.
Further, while the exemplary embodiment of the present subject matter has been discussed within the context of the network-basedauction facility10, the teachings of the present subject matter may be implemented within any network-based transaction system whereby transactions for the purchase and/or sale of an offering are concluded between two or more parties.
SoftwareFIG. 9 shows a diagrammatic representation of a machine in the exemplary form of acomputer system300 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.
Thecomputer system300 includes aprocessor302, amain memory304 and astatic memory306, which communicate with each other via abus308. Thecomputer system300 may further include a video display unit310 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). Thecomputer system300 also includes an alpha-numeric input device312 (e.g., a keyboard), a cursor control device314 (e.g., a mouse), adisk drive unit316, a signal generation device320 (e.g., a speaker) and anetwork interface device322
Thedisk drive unit316 includes a machine-readable medium324 on which is stored a set of instructions (i.e., software)326 embodying any one, or all, of the methodologies described above. Thesoftware326 is also shown to reside, completely or at least partially, within themain memory304 and/or within theprocessor302. Thesoftware326 may further be transmitted or received via thenetwork interface device322. 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 subject matter. The term “machine-readable medium” shall accordingly be taken to included, but not be limited to, solid-state memories, optical and magnetic disks, and carrier wave signals.
Thus, a method and system automatically to remind parties to a network-based transaction to comply with obligations established under a transaction agreement have been described. Although the present subject matter has been described with reference to specific exemplary embodiments, various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the subject matter. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.