Note: Descriptions are shown in the official language in which they were submitted.
CA 02474642 2004-07-28
WO 03/065151 PCT/US03/02209
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.
CA 02474642 2004-07-28
WO 03/065151 PCT/US03/02209
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 S 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 may be executed.
CA 02474642 2004-07-28
WO 03/065151 PCT/US03/02209
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. In 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
(ISAPI) 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, inter alias automated e-mail
communications to users of the facility 10. The page servers 12, picture
servers 14, CGI
CA 02474642 2004-07-28
WO 03/065151 PCT/US03/02209
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
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 may be 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
4
CA 02474642 2004-07-28
WO 03/065151 PCT/US03/02209
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, i~te~ 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 m field 300 for the item
transacted,
an item description field 310, an m 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. In
an
embodiment where only two price setting processes are available, the price
setting
CA 02474642 2004-07-28
WO 03/065151 PCT/US03/02209
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. In 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. In 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. In
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
CA 02474642 2004-07-28
WO 03/065151 PCT/US03/02209
screen. In 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. In
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
CA 02474642 2004-07-28
WO 03/065151 PCT/US03/02209
Figure 9. The screen displays the offering being purchased 910 and the amount
to be
paid for the offering 920. In 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. In 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 wluch is shown in Figure 11. In 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
CA 02474642 2004-07-28
WO 03/065151 PCT/US03/02209
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] In 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.
CA 02474642 2004-07-28
WO 03/065151 PCT/US03/02209
[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 ftinction 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.
CA 02474642 2004-07-28
WO 03/065151 PCT/US03/02209
[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.
11
