COMBINED AUCTION AND FIXED PRICE CHECKOUT SYSTEM
FIELD OF THE INVENTION
[001] The field of the invention relates to online electronic commerce. More specifically, the invention relates to a checkout system for multiple price-setting process within an electronic commerce environment.
BACKGROUND OF THE INVENTION
[002] A number of methods for establishing a price for the sale of goods or services are employed by electronic commerce (e-commerce) systems. One method is for the seller to preset a price at which he is willing to part with an offering, such as Amazon one- click. Another method is for an online auction, or competitive bidding, purchase process to produce a sale price, such as eBay. In fixed price purchase processes, once a price is established, the purchaser is typically directed through a final checkout system for the goods or service. This allows method of payment, method of delivery, and other important information to be entered, edited or confirmed.
SUMMARY OF THE INVENTION
[003] A system and method, comprising a first user interface to facilitate a first type of process to a purchase a first offering that allows a purchaser to select the first offering, a second user interface to facilitate a second type of process that allows the purchaser to bid on a second offering, and a third user interface that allows the purchaser to complete a transaction for both the first and second offerings, are disclosed.
BRIEF DESCRIPTION OF THE DRAWINGS
[004] The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which
[005] Figure 1 is block diagram illustrating an exemplary network-based commerce facility in the form of an Internet-based auction and sale facility.
[006] Figure 2 is a database diagram illustrating an exemplary database, which implements and supports the auction and sale facility.
[007] Figure 3 is a representation of a virtual shopping cart, according to an exemplary embodiment of the present invention.
[008] Figure 4 is a flowchart illustrating an exemplary method for purchasing both fixed price and auction offerings online.
[009] Figure 5 is an interface according to an exemplary embodiment of the present invention, to facilitate purchasing a fixed price offering.
[010] Figure 6 is an interface according to an exemplary embodiment of the present invention, to facilitate bidding on an auction offering.
[011] Figure 7 is a flowchart illustrating an exemplary method for a buyer to complete an online transaction for fixed priced or auction offerings.
[012] Figure 8 is an interface according to an exemplary embodiment of the present invention, to facilitate a purchase.
[013] Figure 9 is an interface according to an exemplary embodiment of the present invention, to facilitate choosing an alternate payment method.
[014] Figure 10 is an interface according to an exemplary embodiment of the present invention, to facilitate reviewing the purchase.
[015] Figure 11 is an interface according to an exemplary embodiment of the present invention, to facilitate a confirmation.
[016] Figure 12 is a flowchart illustrating an exemplary method for a system to complete an online transaction for fixed price offerings.
[017] Figure 13 is a diagrammatic representation of a computer system within which a set of instructions maybe executed.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
[018] A network-based system and method for at least partially completing transactions established using more than one price setting process are disclosed. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one of ordinary skill in the art that these specific details need not be used to practice the present invention, h other circumstances, well-known structures, devices, processes and interfaces have not been shown or described in detail in order not to unnecessarily obscure the present invention.
[019] Performing a checkout process for both fixed price and auction offerings, for example, as a single process can increase the speed and efficiency of online transactions. By combining checkout systems (and the user interface screens) for the checkout offerings sold via multiple price setting processes (e.g. fixed price and auction offerings), the purchaser of these offerings no longer has to contend with using two separate checkout systems. The combined checkout system allows for the separation of transactions so that different offerings can be paid for by different methods and can use different shipping methods.
[020] Figure 1 is block diagram illustrating an exemplary network-based commerce facility in the form of an Internet-based auction and fixed-price facility 10. While an exemplary embodiment of the present invention is described within the context of an auction and fixed-price facility, the invention will find application in many different types of computer-based, and network-based, commerce facilities. [021] The auction and fixed-price facility 10 includes one or more of a number of types of front-end servers, namely page servers 12 that deliver web pages (e.g., markup language documents), picture servers 14 that dynamically deliver images to be displayed within Web pages, listing servers 16, Internet server application program interface (IS API) or common gateway interface (CGI) servers 18 that provide an intelligent interface to the back-end of facility 10, and search servers 20 that handle search requests to the facility 10. E-mail servers 21 provide, mter alia, automated e-mail communications to users of the facility 10. The page servers 12, picture servers 14, CGI
servers 18, search service 20, e-mail servers 21 and database engine server 22 may individually, or in combination, act as a communication engine to facilitate communications between, for example, the client machine 32 and the network-based auction facility 10.
[022] The back-end servers include a database engine server 22, a search index server 24 and a credit card database server 26, each of which maintains and facilitates access to a respective database.
[023] The Internet-based auction and sale facility 10 may be accessed by a client program 30, such as a browser (e.g., the Internet Explorer distributed by Microsoft Corp. of Redmond, Washington) that executes on a client machine 32 and accesses the facility 10 via a network such as, for example, the Internet 34. Other examples of networks that a client may utilize to access the auction facility 10 include a wide area network (WAN), a local area network (LAN), a wireless network (e.g., a cellular network), or the Public Switched Telephone Network (PSTN) network.
[024] Figure 2 is a database diagram illustrating an exemplary database 23, maintained by and accessed via the database engine server 22, which at least partially implements and supports the auction and sale facility 10. The database 23 may, in one embodiment, be implemented as a relational database, and includes a number of tables having entries, or records, that are linked by indices and keys. In an alternative embodiment, the database 23 maybe implemented as collection of objects in an object-oriented database. [025] Central to the database 23 is a user table 40, which contains a record for each user of the facility 10. A user may operate as a seller, buyer, bidder, or all three within the facility 10. The database 23 also includes offerings tables 42 that may be linked to the user table 40. The offerings tables 42 may include a seller offerings table 44, a fixed- price buyer offerings table 45, and a bidder offerings table 46. A user record in the user table 40 may be linked to multiple offerings that are being, or have been, auctioned or otherwise offered for sale via the facility 10. A link indicates whether the user is a seller, a bidder, or a buyer with respect to offerings for which records exist within the offerings tables 42.
[026] The database 23 also includes one or more category tables 47. Each record within the category table 47 describes a respective category. In one embodiment, a
specific category table 47 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 table 47 may describe a number of real, or actual, categories to which offering records, within the offerings tables 42, may be linked. [027] The database 23 also includes a note table 48 populated with note records that may be linked to one or more offering records within the offerings tables 42 and/or to one or more user records within the user table 40. Each note record within the table 48 may include, ter alia, a comment, description, history or other information pertaining to an offering being auction via the auction facility 10, or to a user of the auction facility 10.
[028] A number of other tables are also shown to be linked to the user table 40, namely a user past aliases table 50, a feedback table 52, a feedback details table 53, a bids table 54, an accounts table 56, an account balances table 58 and a transaction record table. The transactions record table contains a record of the items purchased by the buyer, acting as a virtual shopping cart 60. The virtual shopping cart 60 tracks the item subject to the transaction, the seller, the buyer, the price of the item, the method of purchase (e.g. fixed price, buy-it-now, or auction), the date of the purchase, and the current status of the transfer (e.g. processing or item delivered).
[029] One embodiment of the virtual shopping cart 60 is illustrated in Fig. 3. The virtual shopping cart defines a number of fields for each record to track a transaction associated with a user. These fields can include an ID field 300 for the item transacted, an item description field 310, an ID field 320 for the seller of the item, an ID field 330 for the buyer of the item or bidder on the item, a field 340 to store a description of the price setting process (e.g. fixed price, buy-it-now, or auction), a field 350 to store a flag indicating if the price setting process has been completed, a field 360 to store the date on which the price setting process is completed, a field 370 to store the date that the item was listed for sale, a field 380 to store a flag indicating if the transaction has been completed, and a field 390 to store a flag indicating whether a payment reminder has automatically been sent by the auction facility 10 to a successful buyer, hi an embodiment where only two price setting processes are available, the price setting
process description field 340 is a flag. The presence of this field allows the virtual shopping cart to contain a first type of record for one type of price setting process and a second type of record for a second type of price setting process. [030] A user, desiring to buy or bid on an offering, accesses the facility 10 and the databases within to find a desired offering. An offering can be a good or service to be sold. A method 400 for choosing offerings to purchase, according to an exemplary embodiment of the present method, is illustrated by the flowchart in Figure 4. At block 410, a purchaser initiates a purchase procedure by accessing the sales site. At block 420, once the purchaser is viewing an interface to a sales site, the purchaser has the option of viewing interfaces to an auction site or a fixed-price (FP) site. At block 430, having selected the type of offering to be reviewed, the facility 10 then displays a selection of offerings to purchase.
[031] For fixed price offerings, a purchaser selects an offering that meets the purchaser's needs and price requirements 500. The facility 10 then displays a screen describing an offering for sale, as shown in Figure 5. hi one embodiment, the screen displays a brief description of the offerings for sale 510. In a further embodiment, the screen displays a price for the offering 520 and a mechanism for signaling intent to purchase 530. In an additional embodiment, a location 540 and contact information 550 for the seller is made available to the purchaser.
[032] In auctions, the user places a bid on an offering 600 by stating a maximum amount that the user is willing to pay 440. If the price of the item exceeds that maximum, the user has the option of increasing that maximum until the time for the bid expires, hi bidding, the system displays a screen describing an auction offering for sale, as shown in Figure 6. Like the fixed price screen in one embodiment, the auction screen contains a brief description of the offering being offered 610. In a further embodiment, the screen contains a bid-making component 620. The bid-making component 620 comprises a listing of the current bid 622, a listing of the minimum acceptable bid increment 624, and an entry field for the purchaser's maximum acceptable bid 626. hi an additional embodiment, further information about the seller is made available, such as location 630 and seller contact information 632. Information about the bidding, such as bid history 640 and amount of time left on the bid 642, is also made available on the
screen, hi an alternate embodiment, selection of fixed price offerings 650 and bidding on auction offerings are on the same screen.
[033] At block 450, for both fixed price offerings and auction offerings, the purchaser, if not finished shopping, can go back to block 420 and choose whether to look at an auction list or fixed price list. If finished shopping, the purchaser will proceed to the checkout site at block 460.
[034] One embodiment of the procedure for presenting a checkout interface 700 is illustrated in the flowchart of Figure 7. The purchaser begins at the purchase item screen at block 800. The user enters the quantity desired and clicks "purchase now." At block 710, the purchaser proceeds to the checkout screen. At block 720, the purchaser selects a method of payment for the offerings. Payment methods include Internet transaction payments at block 730, credit cards at block 740, and other arrangements made between the seller and the purchaser at block 900. After a payment method has been chosen, the purchaser reviews the order at block 1000. Finally, if the purchaser wishes to proceed with the order, the order is confirmed at block 1100. At block 750, the order is submitted, providing the user with a complete list of the transaction, including the final total value, item information for ordered item, specific information about the seller and the store.
[035] In one embodiment, a purchase item screen is configured in the manner shown in Figure 8. The purchase item screen lists the items that are being purchased by the purchaser 810. Information about the purchase items is listed, such as quantity 812, per item price 814, incidental costs such as tax and shipping and handling 816, and a total cost of the item 818. In an additional embodiment, entry fields 820 allow the purchaser to be identified 822 and security features, such as a password, to be implemented 824. hi a further embodiment, the purchaser can select a method of purchase 830. A meter 840 is displayed in one embodiment, showing the purchaser progress along in the checkout process. While the screen in the present embodiment shows items being purchased, an alternate embodiment could show an offering of services or a combination of items and services.
[036] If the purchaser wishes to arrange an alternate method of payment, in one embodiment, the purchaser would be shown a payment option screen, as illustrated in
Figure 9. The screen displays the offering being purchased 910 and the amount to be paid for the offering 920. hi a further embodiment, the address to which the offering will be shipped or at which the service is performed is listed 930. The purchaser is offered a checkpoint list allowing the purchaser to choose among methods of payment 940. These options include cashier's check 942, money order 944, or pick up at the seller's home 946.
[037] Before completing the transaction, the purchaser is shown a review screen, an example of which is shown in Figure 10, that allows the purchaser to review the terms of the purchase. In one embodiment, the offering being purchased is listed 1010, along with the price for that offering 1020. The purchaser is also shown the shipping address 1030 and the method of payment selected 1040. In an additional embodiment, a meter is displayed showing the purchaser progress in the confirmation process 1050. In a further embodiment, the screen displays a hyperlink that will allow the purchaser to arrange separate payment methods for separate offerings 1060. The purchaser can arrange separate payment methods for auction offerings and for fixed price offerings, or arrange separate payment methods for two offerings of the same pricing type. In one embodiment, the purchaser chooses an insurance option. Additionally, the purchaser can arrange for different shipping methods for different offerings, hi an alternative embodiment, this hyperlink could be placed on earlier or later screens. [038] Once the transaction is completed, the purchaser is shown a confirmation screen, an example of which is shown in Figure 11. h one embodiment, the screen displays the seller 1110 and the seller's contact information 1112. The screen allows the purchaser to double check the shipping address 1120, the billing address 1122, and the payment method 1024. Additionally, the offerings purchased 1130, the number of offerings purchased 1132, and the purchase price 1134 are listed.
[039] One embodiment of the checkout procedure 1200 is illustrated in the flowchart of Figure 12. At block 1205, the buyer chooses an item. At block 1210, the price of the item is estimated, including shipping and taxes. At decision block 1215, the buyer chooses a preferred payment method. These include credit card at block 1220, Internet transaction payment at block 1225, or other method of payment at block 1230. At block 1235, the shipping information is obtained from the seller. At block 1240, the buyer
chooses the buyer's own shipping and insurance options. At block 1245, the total price is calculated. At decision block 1250, the availability of the chosen item is checked. If the item is not available, the transaction is denied at block 1255. At block 1260, notification of denial of the transaction is sent. If the item is available, the inventory containing the item is decremented in block 1265. At block 1270, the buyer and seller are charged. At block 1275, the transaction is created, and the buyer and seller are notified in block 1260.
[040] h one embodiment, the checkout is performed by adding a software checkout function for fixed price items to the software used to checkout auction items, as hosted by an ISAPI server 18. The checkout function generates multiple Internet Server Application Program Interface (ISAPI) pages in the process. A result object is created at the ISAPI level and passed on to the checkout function for use. The ISAPI caller populates a checkout result class with the post information on that page. The checkout function validates this new information and completes the purchase. Each validation, as well as the final purchase, changes the state of the checkout result object. This new state will be returned to the ISAPI caller method to process and determine the next steps. [041] The public functions of the checkout function class include a class destructor, review result retrieval, and shipping address review result retrieval. The class destructor deletes all the memory created by the object. The review result retrieval function validates item, quantity, insurance, payment option and user. The validation errors and results are copied into the result object that the function returns. The review result retrieval function also calls a purchase ID function to generate a purchase identification number. The purchase identification number is generated during this function in order to guarantee that each checkout is unique and avoid users from duplicating the same transaction by double clicking on the confirm button. A constraint within the bids table disregards any second thread generated by double clicking. The shipping address review result retrieval function validates the shipping address for the user and ensures that the seller allows for international shipping when the buyer or buyers choose an international address. The shipping address review result retrieval function returns a result object containing at least copies of validation errors and results.
[042] The protected functions of the checkout function include functions to validate item and quantity, validate payment option, validate insurance, validate user, validate shipping address, and purchase. The validate item and quantity function validates that the item exists, is a fixed price item, that the auction is not over, and that the quantity requested is available in the database. The availability of the item is a preliminary check to be repeated during the purchase function. On validation, the item specific data members are populated in the result object for later use. The validate payment option function checks for the payment options made available by the seller and checks if the buyer has already chosen one of these options. This function is enacted after the insurance is chosen and the buyer is validated, so that the payment can be redirected if needed. The validate insurance function checks whether the seller offers insurance and whether the buyer has chosen that insurance. The validate user function checks the user ID and password for the buyer and adds appropriate error signals if necessary. The validate shipping address checks to see that all the needed fields like street address, name, zip code and others are filled in by the user. This function also validates international shipping requests against the seller's selling preferences. [043] The purchase function contains all the logic to validate availability and adjust the item quantity on a successful purchase. Checkout transactions will confirm their purchase at the final confirmation page with this purchase process wrapper. Transactions with direct credit card billing will use this wrapper to do quantity validation and inventory reduction using an API call, just before the buyer's card is charged to ensure that the buyer's credit card is billed only if the desired quantity is available. In an alternative embodiment, the items are reserved for a time once checkout has begun. If the desired quantity of the item is available, the inventory of the item is decremented and the transaction record is created. The decrement of the quantity in the database is atomic and no two threads will be able to decrement that quantity at the same time. Additionally, the purchase process wrapper will send out the end of transaction e-mail to both the buyer and the seller, enable feedback on the transaction, and charge the final value fee. The end of transaction e-mail includes the shipping address of the buyer, the payment option chosen, the quantity the buyer wanted, and the time stamp of the transaction.
[044] Figure 13 shows a diagrammatic representation of a machine in the exemplary form of a computer system 1300 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.
[045] The computer system 1300 includes a processor 1302, a main memory 1304 and a static memory 1306, which communicate with each other via a bus 1308. The computer system 1300 may further include a video display unit 1310 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 1300 also includes an alpha-numeric input device 1312 (e.g., a keyboard), a cursor control device 1314 (e.g., a mouse), a disk drive unit 1316, a signal generation device 1320 (e.g., a speaker) and a network interface device 1322.
[046] The disk drive unit 1316 includes a machine-readable medium 1324 on which is stored a set of instructions (i.e., software) 1326 embodying any one, or all, of the methodologies described above. The software 1326 is also shown to reside, completely or at least partially, within the main memory 1304 and/or within the processor 1302. The software 1326 may further be transmitted or received via the network interface device 1322 from the network 1328. 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 invention. The term "machine-readable medium" shall accordingly be taken to included, but not be limited to, solid-state memories, optical and magnetic disks, and carrier wave signals. [047] Thus, a network-based system and method for at least partially completing transactions established using more than one price setting process are disclosed. Although the present invention is described herein with reference to a specific preferred embodiment, many modifications and variations therein will readily occur to those with ordinary skill in the art. Accordingly, all such variations and modifications are included within the intended scope of the present invention as defined by the following claims.