U.S. patent application number 17/014635 was filed with the patent office on 2021-02-25 for system and method of safely distributing high demand products.
This patent application is currently assigned to Synchrony Bank. The applicant listed for this patent is Synchrony Bank. Invention is credited to Brad DeWitt, Kimberly Dorn, Thomas Kulesza, Yan Makher, Alex Muller, Travis Watson.
Application Number | 20210056576 17/014635 |
Document ID | / |
Family ID | 1000005207077 |
Filed Date | 2021-02-25 |
![](/patent/app/20210056576/US20210056576A1-20210225-D00000.png)
![](/patent/app/20210056576/US20210056576A1-20210225-D00001.png)
![](/patent/app/20210056576/US20210056576A1-20210225-D00002.png)
![](/patent/app/20210056576/US20210056576A1-20210225-D00003.png)
![](/patent/app/20210056576/US20210056576A1-20210225-D00004.png)
![](/patent/app/20210056576/US20210056576A1-20210225-D00005.png)
![](/patent/app/20210056576/US20210056576A1-20210225-D00006.png)
![](/patent/app/20210056576/US20210056576A1-20210225-D00007.png)
![](/patent/app/20210056576/US20210056576A1-20210225-D00008.png)
United States Patent
Application |
20210056576 |
Kind Code |
A1 |
Muller; Alex ; et
al. |
February 25, 2021 |
SYSTEM AND METHOD OF SAFELY DISTRIBUTING HIGH DEMAND PRODUCTS
Abstract
A system for use with computing devices each associated with one
of a plurality of customers. The system includes a customer
application executing on each of the computing devices and a
computing system that receives requests, from a requesting portion
of the computing devices, to purchase a product not yet available
for purchase. The computing system assigns potential reservations
to selected winning ones of the customers associated with the
requesting portion, receives confirmations from a confirmed portion
of the selected winning customers, converts the potential
reservations to actual reservations for the confirmed portion, and
transmits a code to each of the confirmed portion of the selected
winning customers only after the selected winning customer submits
validation information that the computing system determines
satisfies validation criteria. A merchant transfers the product to
one of the customers at a physical store location only if the
customer provides the code to the merchant.
Inventors: |
Muller; Alex; (Stamford,
CT) ; Makher; Yan; (Stamford, CT) ; Kulesza;
Thomas; (Stamford, CT) ; Dorn; Kimberly;
(Stamford, CT) ; Watson; Travis; (Stamford,
CT) ; DeWitt; Brad; (Stamford, CT) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Synchrony Bank |
Stamford |
CT |
US |
|
|
Assignee: |
Synchrony Bank
Stamford
CT
|
Family ID: |
1000005207077 |
Appl. No.: |
17/014635 |
Filed: |
September 8, 2020 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15882639 |
Jan 29, 2018 |
10796327 |
|
|
17014635 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 30/0633 20130101;
G07C 15/006 20130101; G06Q 30/0212 20130101 |
International
Class: |
G06Q 30/02 20060101
G06Q030/02; G06Q 30/06 20060101 G06Q030/06; G07C 15/00 20060101
G07C015/00 |
Claims
1. (canceled)
2. A method comprising: receiving, by a product reservation
computing system, requests to purchase a product from a merchant
when the product is not yet available for purchase; determining
that the product is available for reservation; processing the
requests to purchase the product using an assignment script
algorithm to assign reservations to select customers that meet a
set of criteria to purchase the product from the merchant;
transmitting a notification of an assigned reservation associated
with a customer; receiving a confirmation associated with the
customer of the select customers, the confirmation including
validation information for the customer; processing the validation
information to confirm that the customer is authorized to purchase
the product from the merchant based on the set of criteria;
generating a unique code associated with the product and the
customer; and transmitting the unique code, wherein when the unique
code is received by a product reservation module of a device
associated with the customer, the unique code facilitates purchase
of the product.
3. The method of claim 2, wherein transmission of the unique code
is triggered by a personal countdown dock associated with the
customer.
4. The method of claim 2, wherein when the unique code is displayed
by the device associated with the customer, a point of sale device
associated with the merchant uses the unique code to verify that
the customer is authorized to purchase the product.
5. The method of claim 2, wherein the unique code is a two
dimensional barcode.
6. The method of claim 2, wherein when the unique code is received
by a merchant system, the merchant system matches the unique code
to a communication associated with the customer to confirm that the
customer is authorized to purchase the product.
7. The method of claim 2, wherein assignment of the reservations is
associated with a default countdown clock indicating a default time
when the product will be available for purchase.
8. The method of claim 2, wherein the notification of the
reservation for the customer is associated with a default countdown
clock and a personal countdown clock that indicates a time when the
product will be available for purchase by the customer.
9. A product reservation computing system comprising: one or more
processors; and one or more non-transitory machine-readable storage
media containing instructions that, when executed on the one or
more processors, cause the one or more processors to perform
operations including: receiving, by the product reservation
computing system, requests to purchase a product from a merchant
when the product is not yet available for purchase; determining
that the product is available for reservation; processing the
requests to purchase the product using an assignment script
algorithm to assign reservations to select customers that meet a
set of criteria to purchase the product from the merchant;
transmitting a notification of an assigned reservation associated
with a customer; receiving a confirmation associated with the
customer of the select customers, the confirmation including
validation information for the customer; processing the validation
information to confirm that the customer is authorized to purchase
the product from the merchant based on the set of criteria;
generating a unique code associated with the product and the
customer; and transmitting the unique code, wherein when the unique
code is received by a product reservation module of a device
associated with the customer, the unique code facilitates purchase
of the product.
10. The system of claim 9, wherein transmission of the unique code
is triggered by a personal countdown clock associated with the
customer.
11. The system of claim 9, wherein when the unique code is
displayed by the device associated with the customer, a point of
sale device associated with the merchant uses the unique code to
verify that the customer is authorized to purchase the product.
12. The system of claim 9, wherein the unique code is a two
dimensional barcode.
13. The system of claim 9, wherein when the unique code is received
by a merchant system, the merchant system matches the unique code
to communication associated with the customer to confirm that the
customer is authorized to purchase the product.
14. The system of claim 9, wherein assignment of the reservations
is associated with a default countdown clock indicating a default
time when the product will be available for purchase.
15. The system of claim 9, wherein the notification of the
reservation for the customer is associated with a default countdown
clock and a personal countdown clock that indicates a time when the
product will be available for purchase by the customer.
16. A non-transitory computer readable medium comprising
instructions that, when executed by one or more processors of a
device, cause the device to perform operations comprising:
receiving requests to purchase a product from a merchant when the
product is not yet available for purchase; determining that the
product is available for reservation; processing the requests to
purchase the product using an assignment script algorithm to assign
reservations to select customers that meet a set of criteria to
purchase the product from the merchant; transmitting a notification
of an assigned reservation associated with a customer; receiving a
confirmation associated with the customer of the select customers,
the confirmation including validation information for the customer;
processing the validation information to confirm that the customer
is authorized to purchase the product from the merchant based on
the set of criteria; generating a unique code associated with the
product and the customer; and transmitting the unique code, wherein
when the unique code is received by a product reservation module of
a device associated with the customer, the unique code facilitates
purchase of the product.
17. The non-transitory computer readable medium of claim 16,
wherein transmission of the unique code is triggered by a personal
countdown clock associated with the customer.
18. The non-transitory computer readable medium of claim 16,
wherein when the unique code is displayed by the device associated
with the customer, a point of sale device associated with the
merchant uses the unique code to verify that the customer is
authorized to purchase the product.
19. The non-transitory computer readable medium of claim 16,
wherein the unique code is a two dimensional barcode.
20. The non-transitory computer readable medium of claim 16,
wherein when the unique code is received by a merchant system, the
merchant system matches the unique code to communication associated
with the customer to confirm that the customer is authorized to
purchase the product.
21. The non-transitory computer readable medium of claim 16,
wherein assignment of the reservations is associated with a default
countdown clock indicating a default time when the product will be
available for purchase.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. patent
application Ser. No. 15/882,639, filed on Jan. 29, 2018, which is
incorporated by reference herein its entirety.
BACKGROUND OF THE INVENTION
Field of the Invention
[0002] The present invention is directed generally to methods of
improving customer safety and particularly to methods of safely
distributing high demand products.
Description of the Related Art
[0003] If a customer wishes to receive an instance of a product
immediately, that customer is typically required to travel to a
physical store location to pick up the instance of the product.
This can create problems when the product is in high demand. High
demand products, such as limited edition sneakers, concert tickets,
iPhones, movie tickets, and limited edition items, can cause lines,
public disturbance, theft, violence, or even death. Therefore, a
need exists for new and improved methods of distributing and/or
obtaining such products. The present application provides these and
other advantages as will be apparent from the following detailed
description and accompanying figures.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)
[0004] FIG. 1 is a block diagram of a system configured to help
distribute high demand products safely.
[0005] FIG. 2 is a flow diagram of a method performed by the system
of FIG. 1.
[0006] FIG. 3 is an illustration of a product launch page displayed
by one of the customer computing devices of the system of FIG.
1.
[0007] FIG. 4 is an illustration of a product page displayed by one
of the customer computing devices of the system of FIG. 1.
[0008] FIG. 5 is an illustration of a store selection page
displayed by one of the customer computing devices of the system of
FIG. 1.
[0009] FIG. 6 is an illustration of a confirmation message
displayed on the product page of FIG. 4.
[0010] FIG. 7 is an illustration of a head start page displayed by
one of the customer computing devices of the system of FIG. 1.
[0011] FIG. 8 is an illustration of a countdown page displayed by
one of the customer computing devices of the system of FIG. 1.
[0012] FIG. 9 is an illustration of a confirmation page displayed
by one of the customer computing devices of the system of FIG.
1.
[0013] FIG. 10 is an illustration of a product pick up page
displayed by one of the customer computing devices of the system of
FIG. 1.
[0014] FIG. 11 is a diagram of a hardware environment and an
operating environment in which the customer computing devices of
FIG. 1 may be implemented.
[0015] FIG. 12 is a diagram of a hardware environment and an
operating environment in which computing devices of the system of
FIG. 1 may be implemented.
[0016] Like reference numerals have been used in the figures to
identify like components.
DETAILED DESCRIPTION OF THE INVENTION
[0017] FIG. 1 is a block diagram of a system 100 that may be used
to mitigate the danger associated with selling high demand products
by eliminating in-store lines and related public disturbances,
theft, and/or violence. The system 100 includes customer computing
devices 110A-110C (e.g., cellular telephones or similar mobile
devices) operated by customers 112A-112C, respectively, merchant
computing systems 120A and 120B operated by merchants 122A and
122B, respectively, and a product reservation computing system 130.
The product reservation computing system 130 may be characterized
as being a remote computing system with respect to the customer
computing devices 110A-110C and/or the merchant computing systems
120A and 120B.
[0018] The system 100 may include any number of customer computing
devices each like the customer computing devices 110A-110C and each
operated by a different customer. However, for ease of
illustration, only the three customer computing devices 110A-110C
have been illustrated and will be described below. Nevertheless,
each of the customer computing devices may include substantially
identical components and be configured to perform the same
functions attributed to the customer computing devices 110A-110C.
Similarly, the system 100 may include any number of merchant
computing systems each like the merchant computing systems 120A and
120B each operated by a different merchant. However, for ease of
illustration, only the merchant computing systems 120A and 120B
have been illustrated and will be described below. Nevertheless,
each of the merchant computing systems may include substantially
identical components and be configured to perform the same
functions attributed to the merchant computing systems 120A and
120B.
[0019] By way of a non-limiting example, each of the customer
computing devices 110A-110C may be implemented as a mobile
communication device 400 (illustrated in FIG. 11 and described). By
way of another non-limiting example, each of the customer computing
devices 110A-110C may be implemented as a computing device 12
(illustrated in FIG. 12 and described below). By way of yet another
non-limiting example, the merchant computing systems 120A and 120B
and the product reservation computing system 130 may each be
implemented using one or more computing devices (e.g., each like
the computing device 12 illustrated in FIG. 12 and described
below).
[0020] Referring to FIG. 1, each of the customer computing devices
110A-110C implements a customer application 152 and, optionally, a
reader application 154. The customer application 152 is configured
to communicate with the product reservation computing system 130
over one or more networks 134 (e.g., a cellular network, the plain
old telephone service ("POTS"), and/or the Internet). Similarly,
each of the merchant computing systems 120A and 120B implements a
merchant application 150 configured to communicate with the product
reservation computing system 130 over the network(s) 134 (e.g., the
Internet, a payment processing network, and the like). Optionally,
the customer computing devices 110A-110C may be configured to
communicate with the merchant computing systems 120A and 120B over
the network(s) 134 (e.g., the cellular network, the POTS, and/or
the Internet).
[0021] Each of the merchants 122A and 122B operates one or more
physical store locations. For example, in FIG. 1, the merchant 122A
operates store locations 160A and 160B. Similarly, the merchant
122B operates a store location 162. Each of the store locations
160A, 160B, and 162 has an inventory 170 of products for sale and
an optional proximity beacon 172. The inventory 170 of the store
locations 160A and 160B includes inventories 180A and 180B,
respectively, of a product "SKU1." The product "SKU1" may be a
particular Stock Keeping Unit ("SKU"). By way of a non-limiting
example, the product "SKU1" may be a white T-shirt.
[0022] Referring to FIG. 10, each of the optional proximity beacons
172 transmits a wireless proximity signal 182. The proximity signal
182 transmitted by each of the proximity beacons 172 may include a
store location code that is unique. Thus, referring to FIG. 1, the
proximity beacons 172 at the store locations 160A, 160B, and 162
may each transmit a different store location code.
[0023] The reader application 154 is configured to detect the
proximity signal 182 (see FIG. 10) and read the store location code
therefrom. The customer application 152 is configured to obtain the
store location code from the reader application 154 and forward the
store location code to the product reservation computing system
130. The product reservation computing system 130 associates each
of the unique store location codes with a different one of the
store locations 160A, 160B, and 162. Thus, the product reservation
computing system 130 may use the unique store location codes to
confirm whether the customer computing device 110A is at a
particular one of the store locations 160A, 160B, and 162.
[0024] The product reservation computing system 130 is configured
to facilitate the sale of high-demand products by collecting
requests for reservations for a particular product (e.g., the
product "SKU1") and selecting (e.g., via a lottery process) those
of the customers 112A-112C who will be allowed to purchase the
particular product. The product reservation computing system 130
implements a product reservation module 140 that includes a
collection of wish lists 142 and an Assignment Script Algorithm
("ASA") 144. The product reservation computing system 130 may also
implement a database 146.
[0025] The product reservation module 140 may be characterized as a
comprehensive Internet-based application for managing and loading
an inventory of products and marketing the products. In particular,
the product reservation module 140 may be used to launch a new high
demand product safely. For example, the merchant 122A may enter
launch information into the product reservation module 140. Then,
the product reservation module 140 may receive requests for the
product from the customers 112A-112C (e.g., via the customer
application 152 executing on the customer computing devices
110A-110C, respectively). Next, the product reservation module 140
determines which of the customers 112A-112C has won (e.g., via a
lottery process) the opportunity to purchase the product and
assigns potential reservations to such winning customers. At this
point, the winning customers must confirm that they are planning on
picking up the product at one of the merchant's store locations.
The product reservation module 140 converts the potential
reservation to an actual reservation for each winning customer who
confirms that the winning customer will pick up the product. Next,
those of the winning customers with actual reservations either pick
up the product at one of the merchant's physical store locations or
fail to pick up the product.
[0026] FIG. 2 is a flow diagram of a method 200 performed by the
system 100 (see FIG. 1). Referring to FIG. 1, for ease of
illustration, the functionality of the system 100 will be described
with respect a product launch of the product "SKU1" by the merchant
122A and the customer 112A who wishes to obtain the product
"SKU1."
[0027] In first block 210 (see FIG. 2), an import merchant data
process is performed by the product reservation computing system
130 and the merchant computing system 120A. During the import
merchant data process, the product reservation module 140 receives
information from the merchant application 150 operated by the
merchant 122A regarding the in-store inventory 170 at one or both
of the store locations 160A and 160B and stores this information
(e.g., in the database 146). For example, in block 210 (see FIG.
2), the product reservation module 140 may receive the inventories
180A and 180B, respectively, of the product "SKU1" and store them
in the database 146. Thus, the product reservation computing system
130 may allow the merchant 122A to load in one or more of the
inventories 180A and 180B of one or more high demand products
(e.g., the product "SKU1") at one or more of the store locations
160A and 160B.
[0028] In next block 212 (see FIG. 2), a product release setup
process is performed by the product reservation computing system
130 and the merchant computing system 120A. During the product
release setup process, the product reservation module 140 receives
an indication from the merchant application 150 executing on the
merchant computing system 120A that the merchant 122A wishes to
make the product "SKU1" available for reservation or wishes to
launch the product "SKU1." For example, if the product "SKU1" has
not been entered into the product reservation module 140, the
merchant 122A may enter the product "SKU1." The merchant 122A may
identify any product options (e.g., size, color, etc.) associated
with the product "SKU1."
[0029] The merchant 122A may also identify those of the store
locations 160A and 160B where the product "SKU1" is or will be
available as well as inventory data related to the product "SKU1."
For example, the merchant 122A may enter an amount of the product
"SKU1" available for each product option (e.g., size, color, etc.)
at each of the store locations 160A and 160B where the product
"SKU1" is or will be available. In addition, the merchant 122A may
enter a name associated with the product "SKU1" as well as a
manufacturer of and/or a brand associated with the product "SKU1."
Thus, the merchant 122A instantiates the availability of the
product "SKU1" using the product reservation module 140. The
merchant 122A may also provide additional launch information, such
as when (e.g., date and time) the product "SKU1" will be available
for purchase (e.g., at one or both of the store locations 160A and
160B).
[0030] The product reservation module 140 may use the date and time
when the product "SKU1" will be available for purchase to generate
a default countdown clock 214 (see FIG. 8). The default countdown
clock 214 (see FIG. 8) indicates a default amount of time until the
product reservation module 140 determines which of the customers
112A-112C will be given an opportunity to purchase the product
"SKU1." However, as will be explained below, the product
reservation module 140 may generate a different personal countdown
clock 216 (see FIG. 8) for each of the customers 112A-112C. When
first generated, the personal countdown clock 216 (see FIG. 8) may
be identical to the default countdown clock 214 (see FIG. 8).
However, the personal countdown clock 216 (see FIG. 8) for at least
a portion of the customers 112A-112C may indicates a modified
amount of time until the product reservation module 140 will
determine whether the portion of the customers 112A-112C will be
given an opportunity to purchase the product "SKU1." For example,
the customer 112A may qualify for a head start, which is applied to
the personal countdown clock 216 (see FIG. 8) for the customer
112A. Thus, the personal countdown clock 216 (see FIG. 8) for the
customer 112A will count down to zero before the default countdown
clock 214 (see FIG. 8) and possibly before the personal countdown
clocks of other customers. This increases the likelihood that the
customer 112A will be assigned a potential reservation by the
product reservation module 140.
[0031] In block 218 (see FIG. 2), the product reservation module
140 communicates via digital means (e.g., an email, a push
notification, a text message, and other digital means) the
availability of the product "SKU1" to the customer application 152
executing on each of the customer computing devices 110A-110C.
Referring to FIG. 3, the customer application 152 may display a
product launch page 220 that includes a list 222 of products
available to the customers 112A-112C (see FIG. 1) for reservation.
In FIG. 3, the list 222 includes the product "SKU1" along with
other products "SKU2" to "SKU5." Optionally, referring to FIG. 1,
the product reservation module 140 may prevent each of the
customers 112A-112C from following or selecting a product, if that
product is not available within a predetermined distance of the
customer.
[0032] In block 224 (see FIG. 2), the product reservation module
140 receives one or more customer submissions from the customer
application 152 executing on each of a requesting portion of the
customer computing devices 110A-110C. The customer submission(s)
received from each of the requesting portion include a selection of
at least one of the products "SKU1" to "SKU5." Referring to FIG. 1,
the product reservation module 140 adds the selection received from
each of the requesting portion to a wish list in the collection of
wish lists 142 that is associated with the customer operating the
customer computing device from which the selection was received.
For example, in FIG. 3, the customer 112A (see FIG. 1) selects
(e.g., using a display device 430 illustrated in FIG. 11) the
product "SKU1" from the list 222. Thus, referring to FIG. 1, the
requesting portion includes the customer computing device 110A
operated by the customer 112A. The product reservation module 140
adds the product "SKU1" to a wish list 226 associated with the
customer 112A.
[0033] Optionally, after the product reservation module 140
receives the customer submission, the product reservation module
140 may send product information related to the product "SKU1" to
the customer application 152. The customer application 152 may
display the product information on a product page 228 (see FIGS. 4
and 6). In the example illustrated in FIG. 4, the product page 228
includes a selectable store option 230A that, when selected, allows
the customer 112A (see FIG. 1) to select a store in which to
request the reservation.
[0034] Referring to FIG. 5, after the customer 112A (see FIG. 1)
selects the store option 230A (see FIG. 4), the customer
application 152 may display a list 231 of store locations on a
store selection page 232. For example, the store selection page 232
may display one or more of the store locations 160A and 160B (see
FIG. 1) whereat the product "SKU1" is available for purchase. Then,
referring to FIG. 1, the customer 112A may choose at least one of
the store locations 160A and 160B in the list 231 (see FIG. 1). In
the example illustrated in FIG. 5, the store selection page 232
allows the customer 112A (see FIG. 1) to choose up to two locations
and the customer 112A has chosen both of the store locations 160A
and 160B (see FIG. 1).
[0035] Alternatively, referring to FIG. 1, the product reservation
module 140 may automatically select one or more of the store
locations 160A and 160B. These automatic selections may be based at
least in part on inventory rules defined in the product reservation
module 140 and/or based at least in part on which of the store
locations 160A and 160B is the closest (e.g., to a home address of
the customer 112A, a current location of the customer 112A, and the
like).
[0036] Optionally, referring to FIG. 4, the product reservation
module 140 (see FIG. 1) may send one or more selectable product
options 230B and 230B (e.g., size, quantity, etc.) to the customer
application 152 that the customer application 152 displays (e.g.,
on the product page 228) to the customer 112A (see FIG. 1). The
customer 112A (see FIG. 1) may select the product options 230B and
230B and provide information for each selected product option that
the customer application 152 sends to the product reservation
module 140 (see FIG. 1). Referring to FIG. 1, the product
reservation module 140 adds this information the wish list 226 so
that the product reservation module 140 might assign a potential
reservation of an appropriate instance of the product "SKU1" to the
customer 112A.
[0037] After the customer 112A has provided the information
necessary to request the reservation, the product reservation
module 140 may send a confirmation to the customer application 152
indicating that the request has been received and the product
"SKU1" has been added to the wish list 226 associated with the
customer 112A. Referring to FIG. 6, the customer application 152
may display a confirmation message 236 (e.g., "moved to countdown
clock") to the customer 112A (see FIG. 1) indicating that the
product "SKU1" has been added to the wish list 226 (see FIG. 1) and
the customer 112A may be selected (e.g., via a lottery or other
contest) by the product reservation module 140 to have the
opportunity to purchase the product "SKU1." Optionally, the
customer application 152 may display a link or button 238 that when
selected causes the customer application 152 to display a countdown
page 240 (see FIG. 8).
[0038] Referring to FIG. 8, the countdown page 240 includes the
default and personal countdown clocks 214 and 216. As mentioned
above, when first generated by the product reservation module 140,
the default and personal countdown clocks 214 and 216 may be
identical. However, the customer 112A may modify the personal
countdown clock 216 (e.g., by subtracting a head start amount of
time from the personal countdown clock 216 before the personal
countdown clock 216 counts down to zero).
[0039] Optionally, in block 224 (see FIG. 2), the customer 112A
(see FIG. 1) may modify the personal countdown clock 216 associated
with the customer 112A. For example, the customer 112A (see FIG. 1)
may apply a head start (e.g., five minutes) to the personal
countdown clock 216 that decreases the amount of time before the
personal countdown clock 216 counts down to zero. However, the
default countdown clock 214 remains unchanged. As mentioned above,
the personal countdown clock 216 applies only to the customer 112A
(see FIG. 1). However, the product reservation module 140 (see FIG.
1) may generate other personal countdown clocks (not shown) that
apply to other customers.
[0040] FIG. 7 illustrates a head start page 246 that the customer
application 152 may display to the customer 112A (see FIG. 1). The
customer 112A (see FIG. 1) may select one or more items 248 each
associated with an amount of time. When the customer 112A (see FIG.
1) selects one or more of these items 248, the associated amount of
time is subtracted from the personal countdown clock 216 (see FIG.
8) but only for the customer 112A. The customer 112A (see FIG. 1)
may earn some of the items 248 illustrated on the head start page
246. By way of a non-limiting example, the customer 112A (see FIG.
1) may earn one or more of the items 248 by having achieved a
certain status (e.g., a VIP Customer, a Platinum Customer, and the
like) with the system 100 (see FIG. 1) or the merchant 122A (see
FIG. 1). By way of another non-limiting example, the customer 112A
(see FIG. 1) may earn one or more of the items 248 by physically
going into one of the store locations 160A and 160B (see FIG. 1)
operated by the merchant 122A (see FIG. 1) and checking in with the
system 100 (see FIG. 1) to provide evidence of the visit to the
store location. For example, referring to FIG. 1, the customer
computing device 110A may detect the proximity signal 182 (see FIG.
10) directly from the proximity beacon 172 and transmit the store
location code to the product reservation module 140 as evidence
that the customer 112A visited the store location. Alternatively,
the customer 112A may enter a predetermined pin (e.g., a four digit
pin) associated only with that store location and the customer
computing device 110A may send the predetermined pin to the product
reservation module 140 as evidence that the customer 112A visited
the store location.
[0041] Referring to FIG. 1, in block 250 (see FIG. 2), the product
reservation module 140 performs a status assignment process for the
product "SKU1" that determines a status for each of the customers
112A-112C who requested to reserve the product "SKU1" in block 224.
In block 250, the product reservation module 140 may run the ASA
144, which may be configured to implement a lottery that is used to
assign a status to each of the customers 112A-112C who requested to
reserve the product "SKU1" in block 224.
[0042] By way of a non-limiting example, the status may include
"won," "waitlisted," and "lost." The status "won" indicates that
the customer 112A has the opportunity to reserve the product
"SKU1." The status "waitlisted" indicates that the customer 112A
might have the opportunity to reserve the product "SKU1" if enough
other customers who were assigned the status "won" decide not to
reserve or purchase the product "SKU1." The status "lost" indicates
that the customer 112A will not be given the opportunity to reserve
the product "SKU1." Thus, the product reservation module 140
determines which of the customers 112A-112C will ultimately have
chance of purchasing the product "SKU1." For example, if the
customers 112A-112C include 5000 customers who have each added the
product "SKU1" for the store location 160A to their wish lists but
the store location 160A has only 500 units of the product "SKU1"
available, the ASA 144 decides which of the 5000 customers are
provided the opportunity to purchase the product "SKU1."
[0043] The product reservation module 140 performs block 250 (see
FIG. 2) with respect to each of the customers 112A-112C when the
personal countdown clock 216 (see FIG. 8) associated with each of
the customers 112A-112C counts down to zero. Thus, the product
reservation module 140 may perform block 250 (see FIG. 2) at
different times for different customers. For example, if there are
only two instances of the product "SKU1," and the personal
countdown clock 216 (see FIG. 8) associated with the customer 112A
counts down to zero before the personal countdown clocks of the
other two customers 112B and 112C, when the personal countdown
clock 216 (see FIG. 8) associated with the customer 112A counts
down to zero, the product reservation module 140 assigns the status
"won" to the customer 112A. If the personal countdown clocks of the
customers 112B and 112C count down to zero at the same time, the
ASA 144 selects (e.g., randomly) one of the customers 112B and 112C
and assigns the status "won" to that customer when the personal
countdown clocks of the customers 112B and 112C count down to zero.
The other unselected customer may be assigned the status
"waitlisted" or the status "lost."
[0044] As mentioned above, the ASA 144 may select winning customers
randomly from those customers whose personal countdown clocks have
reached zero. Alternatively, the ASA 144 may decide which of the
customers 112A-112C whose personal countdown clocks have reached
zero is to be assigned the status "won" based on several factors.
By way of non-limiting examples, these factors may include loyalty
status of each of the customers 112A-112C, number of in-store
visits (as measured by the customer application 152) made by each
of the customers 112A-112C, purchase history of each of the
customers 112A-112C, number of times each of the customers
112A-112C failed to pick up a product after confirming that the
customer would pick up the product, and the like. The ASA 144 may
be designed to be extensible and take inputs from recursive
analysis (e.g., what status has the customer 112A been assigned in
the past) as well as machine learning outputs.
[0045] In block 255 (see FIG. 2), the product reservation module
140 notifies each of the customers 112A-112C as to their respective
status. Thus, the product reservation module 140 sends a
notification to the customer application 152 with the status of the
customer 112A. Referring to FIG. 9, the customer application 152
displays a status notification 256 (e.g., "YOU WON") to the
customer 112A (see FIG. 1).
[0046] Referring to FIG. 2, in decision block 258, the product
reservation module 140 (see FIG. 1) decides how to proceed with
respect to each of the customers 112A-112C (see FIG. 1) based on
their respective statuses. For example, referring to FIG. 1, the
product reservation module 140 decides how to proceed with respect
to the customer 112A based on the status assigned to the customer
112A.
[0047] If the status assigned to the customer 112A is "lost," the
customer 112A has not been awarded the opportunity to reserve the
product "SKU1" for purchase. When this occurs, the method 200 (see
FIG. 2) terminates. Optionally, if the product launch of the
product "SKU1" has not yet ended, the customer 112A may return to
the product launch page 220 and provide another customer submission
(in block 224). For example, the customer 112A may try to reserve a
different instance (e.g., a different size, a different color,
etc.) of the product "SKU1."
[0048] If the status assigned to the customer 112A is "won," the
customer 112A has been awarded the opportunity to reserve the
product "SKU1" for purchase. In block 260 (see FIG. 2), the product
reservation module 140 assigns a potential reservation to the
customer 112A that the customer 112A can turn into an actual
reservation. The potential reservation may specify one of the store
locations 160A and 160B. The product reservation module 140
communicates to the customer application 152 if an action (e.g.,
confirmation) is required by the customer 112A to convert the
potential reservation into an actual reservation. For example,
referring to FIG. 9, the customer application 152 may display a
confirmation page 262 with a confirm button 263 that the customer
112A (see FIG. 1) may select to confirm the reservation.
Optionally, the confirmation page 262 may include a decline button
264 that the customer 112A (see FIG. 1) may select to decline the
reservation. Referring to FIG. 1, the product reservation module
140 may give the customer 112A a limited amount of time to confirm
the reservation after the product reservation module 140 notifies
the customer 112A of the status "won."
[0049] In decision block 265 (see FIG. 2), the product reservation
module 140 determines whether the customer 112A has confirmed the
reservation (e.g., by selecting the confirm button 263 illustrated
in FIG. 9) within the limited amount of time. The decision in
decision block 265 (see FIG. 2) is "YES," when the customer 112A
has confirmed the reservation within the limited amount of time.
Otherwise, the decision in decision block 265 (see FIG. 2) is
"NO."
[0050] When the decision in decision block 265 (see FIG. 2) is
"NO," in block 270, the potential reservation expires. Thus, the
customer 112A has lost the opportunity to reserve the product
"SKU1" for purchase. Then, in block 272, the product reservation
module 140 may reassign the instance of the product "SKU1" to one
of those of the customers who were assigned the status
"waitlisted." After block 272, the method 200 terminates.
[0051] Referring to FIG. 2, when the decision in decision block 265
is "YES," in block 274, the product reservation module 140 (see
FIG. 1) converts the potential reservation into an actual
reservation. The actual reservation may specify one of the store
locations 160A and 160B. For example, referring to FIG. 1, the ASA
144 may assign an instance of the product "SKU1" in the inventory
180A at the store location 160A to the customer 112A. The product
reservation module 140 may provide detailed instructions to the
customer application 152 regarding pick up of the product "SKU1 at
the selected store location. For example, the product reservation
module 140 may send this information to the customer application
152, which may display this information on a product pick up page
275 (see FIG. 10).
[0052] An economic transaction may or may not be required to secure
the actual reservation. For example, the customer 112A may purchase
the product "SKU1" using the customer application 152.
Alternatively, the customer 112A may purchase the product "SKU1" at
the selected store location when the customer 112A picks up the
instance of the product "SKU1" assigned to the customer 112A.
[0053] To pick up the product "SKU1" (e.g., at the store location
160A), the customer 112A and/or the customer computing device 110A
may be required to supply validation information to the product
reservation module 140 (e.g., within a predetermined amount of time
following confirmation). After the product reservation module 140
receives the validation information (e.g., the store location
code), the product reservation module 140 determines whether the
validation information satisfies validation criteria. The
validation criteria may be used to validate the user and/or the
customer computing device 110A. Non-limiting examples of the
validation information may include one or more of the following:
[0054] 1. An indication of proximity to the proximity beacon 172,
which may be implemented as a Bluetooth enabled Beacon, an AKA
Beacon, an iBeacon, or a Bluetooth Low Energy ("BLE") device;
[0055] 2. A physical location of the customer computing device 110A
(e.g., at the store location 160A), which may be identified (e.g.,
a latitude and a longitude) by a location module 488 (see FIG. 11),
such as a conventional geolocation or Global Positioning System
("GPS") module, of the customer computing device 110A; [0056] 3. An
in-store unlock code or pin (e.g., provided manually by an
employee, such as a store associate, of the merchant 122A); [0057]
4. One or more commonly used identifiers, such as a Unique Device
Identifier ("UDID"), a Universally Unique Identifier ("UUID"), an
Android DeviceID, one or more cookies, and any other identifier
defined by the product reservation computing system 130; [0058] 5.
A digital user authentication, which may include authenticating a
user name and password, authenticating a biometric signature,
and/or other commonly used authentication models or methods; [0059]
6. Physical user authentication, which may include an indication
that an employee of the merchant 122A has authenticated a
government issued identification presented by the customer
112A.
[0060] For example, the validation criteria may include evidence
that the customer 112A is physically at the store location 160A.
The product reservation module 140 may determine this validation
criteria is satisfied when the product reservation module 140
receives an indication (e.g., the store location code) from the
customer computing device 110A that the customer computing device
110A has detected (e.g., using the optional reader application 154)
the proximity signal 182 (see FIG. 10) transmitted by the proximity
beacon 172 at the store location 160A. After detecting the
proximity signal 182 (see FIG. 10) directly from the proximity
beacon 172, the customer computing device 110A transmits the
indication (e.g., the store location code) to the product
reservation module 140, which uses this information to determine
whether the validation criteria is satisfied. The customer
computing device 110A may detect the proximity signal 182 (see FIG.
10) directly from the proximity beacon 172 when the customer
computing device 110A is within a transmission distance of the
proximity beacon 172.
[0061] In decision block 276 (see FIG. 2), the product reservation
module 140 determines whether the customer 112A has satisfied the
validation criteria (e.g., within the predetermined amount of time
following confirmation). If the validation criteria is/are
satisfied, the decision in decision block 276 (see FIG. 2) is
"YES." Otherwise, the decision in decision block 276 (see FIG. 2)
is "NO."
[0062] When the decision in decision block 276 (see FIG. 2) is "NO"
and the predetermined amount of time following confirmation has
expired, in block 280 (see FIG. 2), the product reservation module
140 records that the customer 112A failed to pick up the product
"SKU1." This information may be used by the product reservation
module 140 in the future to determine, at least in part, if the
customer 112A will be given the opportunity to request reservations
of other products being launched using the product reservation
module 140. Then, in optional block 282, if the customer 112A did
not pay for the product "SKU1," the product reservation module 140
may release the instance of the product "SKU1" reserved for the
customer 112A and reassign the instance to one of those customers
who were assigned the status "waitlisted." After optional block
282, the method 200 terminates.
[0063] When the decision in decision block 276 (see FIG. 2) is
"YES," in block 285 (see FIG. 2), the product reservation module
140 performs a promotion process. For example, the customer 112A
may travel to the store location 160A and pick up the instance of
the product "SKU1" from the inventory 180A. If the instance of the
product "SKU1" was not purchased in block 274, the customer 112A
purchases the instance of the product "SKU1" at the store location
160A.
[0064] Referring to FIG. 10, the promotion process may include the
product reservation module 140 (see FIG. 1) sending a code 286
(e.g., an alphanumeric code, a one-dimensional barcode, a
two-dimensional barcode, a Quick Response ("QR") code, and the
like) to the customer application 152. In some embodiments, the
product reservation module 140 (see FIG. 1) transmits the code 286
to the customer computing device 110A after the product reservation
module 140 determines the validation criteria has been satisfied.
The code 286 sent to the validated customers may be unique to each
customer. When the customer 112A (see FIG. 1) picks up the product
"SKU1," the customer 112A provides the code 286 to the merchant
122A (see FIG. 1) as proof that the customer 112A has been
authorized to purchase the product "SKU1." The customer application
152 (see FIG. 1) may transmit or display the code 286 to the
merchant 122A (see FIG. 1) using the customer computing device
110A. By way of non-limiting examples, the customer application 152
may transmit the code 286 (e.g., to the merchant computing system
120A illustrated in FIG. 1) using Bluetooth, BLE, any other
near-field communication mode, and the like. Referring to FIG. 1,
the merchant application 150 may confirm the validity of the code
286 (see FIG. 10) and display a message indicating that the
customer 112A is authorized to purchase the product "SKU1" at the
store location 160A.
[0065] Alternatively and/or additionally, the code 286 (see FIG.
10) may be displayed (e.g., via the display device 430 (see FIG.
11) of the customer computing device 110A) to the merchant 122A.
For example, the merchant 122A may scan (e.g., using a conventional
barcode reader, not shown) the code 286 (see FIG. 10) into the
merchant application 150. The merchant application 150 may confirm
the validity of the code 286 (see FIG. 10) and display a message
indicating that the customer 112A is authorized to purchase the
product "SKU1" at the store location 160A.
[0066] Optionally, the customer 112A may inform the customer
application 152 (e.g., click a link or a button 288 (see FIG. 10)
displayed by the customer application 152) that the product "SKU1"
has been picked up. In turn, the customer application 152 may
inform the product reservation module 140 that the product "SKU1"
has been picked up.
[0067] Optionally, the merchant 122A and/or the merchant
application 150 inform the product reservation module 140 that the
customer 112A has picked up the product "SKU1."
[0068] Referring to FIG. 2, the method 200 terminates after block
285.
[0069] Referring to FIG. 1, the ASA 144 may run multiple additional
times (e.g., until all of the instances of the product "SKU1" are
assigned to a customer or the product launch has ended) and/or
change the status of the customers from "waitlisted" to either
"won" or "lost." In decision block 290 (see FIG. 2), the product
reservation module 140 determines whether the status of the
waitlisted customer 112A has been updated to "won." As mentioned
above, if the customer 112A was assigned the status "waitlisted,"
the ASA 144 may assign (e.g., in block 272 or 282 of FIG. 2) the
status "won" to the customer 112A if other customers fail to
confirm their "won" statuses (as determined in decision block 265
of FIG. 2) or fail to validate (as determined in decision block 276
of FIG. 2) and did not pay for the product "SKU1." If the ASA 144
assigns the status "won" to the customer 112A, in block 260 (see
FIG. 2), the ASA 144 also assigns a potential reservation to the
customer 112A that the customer 112A may be able to turn into an
actual reservation in block 274 (see FIG. 2). Referring to FIG. 2,
the decision in decision block 290 is "YES," when the status of the
waitlisted customer 112A (see FIG. 1) has been updated to "won."
Otherwise, the decision in decision block 290 is "NO."
[0070] When the decision in decision block 290 is "YES," the
product reservation module 140 (see FIG. 1) advances to block 260
where the ASA 144 assigns the status "won" to the customer
112A.
[0071] When the decision in decision block 290 is "NO," in block
295, the launch of the product "SKU1" has ended. For example, in
block 295, the instances of the product "SKU1" may have sold out.
Optionally, the status of the customer 112A (see FIG. 1) may be
changed to "lost." After block 295, the method 200 terminates.
Optionally, before block 295, the customer 112A (see FIG. 1) may
optionally return to the product launch page 220 and provide
another customer submission (in block 224). For example, the
customer 112A may try to reserve a different instance (e.g., a
different size, a different color, etc.) of the product "SKU1."
Mobile Communication Device
[0072] FIG. 11 is a functional block diagram illustrating the
mobile communication device 400 that may be used to implement one
or more of the customer computing devices 110A-110C of FIG. 1. By
way of non-limiting examples, referring to FIG. 11, the mobile
communication device 400 may be implemented as a cellular
telephone, a tablet computer, and the like. The mobile
communication device 400 includes a central processing unit (CPU)
410. Those skilled in the art will appreciate that the CPU 410 may
be implemented as a conventional microprocessor, application
specific integrated circuit (ASIC), digital signal processor (DSP),
programmable gate array (PGA), or the like. The mobile
communication device 400 is not limited by the specific form of the
CPU 410.
[0073] The mobile communication device 400 also contains a memory
420. The memory 420 may store instructions and data to control
operation of the CPU 410. The memory 420 may include random access
memory, ready-only memory, programmable memory, flash memory, and
the like. The mobile communication device 400 is not limited by any
specific form of hardware used to implement the memory 420. The
memory 420 may also be integrally formed in whole or in part with
the CPU 410.
[0074] The mobile communication device 400 also includes
conventional components, such as the display device 430 and one or
more user input devices 440 (e.g., buttons, a keypad, a keyboard,
and the like). These are conventional components that operate in a
known manner and need not be described in greater detail. The
display device 430 may be implemented as a touch display or
touchscreen configured to receive user input (e.g., selections from
the list 222, a selection of the store option 230A, selection of
the product options 230B and 230C, selections from the list 231,
selection of the button 238, selection of the item(s) 248,
selection of the confirm button 263 or the decline button 264,
selection of the button 288, and the like). By way of non-limiting
examples, the display device 430 is operable to display the screens
and pages (e.g., the product launch page 220, the product page 228,
the store selection page 232, the head start page 246, the
countdown page 240, a confirmation page 262, and the product pick
up page 275) depicted in FIGS. 3-10, and the like.
[0075] The memory 420 stores computer executable instructions that
when executed by the CPU 410 cause the CPU 410 to generate the
screens and interfaces described above and displayed by the display
device 430. Referring to FIG. 1, the memory 420 (see FIG. 11) also
stores computer executable instructions that when executed by the
CPU 410 implement the customer application 152, and the optional
reader application 154. Such instructions may be stored on one or
more non-transitory computer-readable media. Returning to FIG. 11,
other conventional components found in wireless communication
devices, such as a USB interface, Bluetooth interface, camera/video
device, infrared device, and the like, may also be included in the
mobile communication device 400. For the sake of clarity, these
conventional elements are not illustrated in the functional block
diagram of FIG. 11.
[0076] The mobile communication device 400 also includes a network
transmitter 450 such as may be used by the mobile communication
device 400 for normal network wireless communication with the
network(s) 134 (see FIG. 1), such as with a base station (not
shown) of a cellular network. FIG. 11 also illustrates a network
receiver 460 that operates in conjunction with the network
transmitter 450 to communicate with the network(s) 134 (see FIG.
1), such as with the base station (not shown) of the cellular
network. In a typical embodiment, the network transmitter 450 and
network receiver 460 are implemented as a network transceiver 470.
The network transceiver 470 is connected to an antenna 480.
Operation of the network transceiver 470 and the antenna 480 for
communication with the network(s) 134 (see FIG. 1) is well-known in
the art and need not be described in greater detail herein.
[0077] While not illustrated in FIG. 11, referring to FIG. 10, as
mentioned above, the mobile communication device 400 (see FIG. 11)
includes hardware components (e.g., a transmitter, a receiver, and
an antenna) configured to receive the proximity signal 182 from the
proximity beacon 172. The mobile communication device 400 (see FIG.
11) also includes software components (e.g., the optional reader
application 154 stored in the memory 420 illustrated in FIG. 11)
required to detect the proximity signal 182 transmitted by the
proximity beacon 172 and read the store location code encoded in
the proximity signal 182.
[0078] Referring to FIG. 11, as mentioned above, the mobile
communication device 400 may also include the location module 488
(e.g., a conventional geolocation or GPS module) operable to
determine the current location of the mobile communication device
400.
[0079] The various components illustrated in FIG. 11 are coupled
together by a bus system 490. The bus system 490 may include an
address bus, data bus, power bus, control bus, and the like. For
the sake of convenience, the various busses in FIG. 4 are
illustrated as the bus system 490.
[0080] The memory 420 may store instructions executable by the CPU
410. The instructions may implement portions of the method 200
illustrated in FIG. 2. Such instructions may be stored on one or
more non-transitory computer or processor readable media.
Computing Device
[0081] FIG. 12 is a diagram of hardware and an operating
environment in conjunction with which implementations of the one or
more computing devices of the system 100 may be practiced. The
description of FIG. 12 is intended to provide a brief, general
description of suitable computer hardware and a suitable computing
environment in which implementations may be practiced. Although not
required, implementations are described in the general context of
computer-executable instructions, such as program modules, being
executed by a computer, such as a personal computer. Generally,
program modules include routines, programs, objects, components,
data structures, etc., that perform particular tasks or implement
particular abstract data types.
[0082] Moreover, those of ordinary skill in the art will appreciate
that implementations may be practiced with other computer system
configurations, including hand-held devices, multiprocessor
systems, microprocessor-based or programmable consumer electronics,
network PCs, minicomputers, mainframe computers, and the like.
Implementations may also be practiced in distributed computing
environments (e.g., cloud computing platforms) where tasks are
performed by remote processing devices that are linked through a
communications network. In a distributed computing environment,
program modules may be located in both local and remote memory
storage devices.
[0083] The exemplary hardware and operating environment of FIG. 12
includes a general-purpose computing device in the form of the
computing device 12. Each of the computing devices mentioned above,
including those illustrated in FIG. 1 (e.g., the customer computing
devices 110A-110C, the merchant computing systems 120A and 120B,
and the product reservation computing system 130), may be
substantially identical to the computing device 12. By way of
non-limiting examples, the computing device 12 may be implemented
as a laptop computer, a tablet computer, a web enabled television,
a personal digital assistant, a game console, a smartphone, a
mobile computing device, a cellular telephone, a desktop personal
computer, a blade computer, and the like.
[0084] The computing device 12 includes a system memory 22, the
processing unit 21, and a system bus 23 that operatively couples
various system components, including the system memory 22, to the
processing unit 21. There may be only one or there may be more than
one processing unit 21, such that the processor of computing device
12 includes a single central-processing unit ("CPU"), or a
plurality of processing units, commonly referred to as a parallel
processing environment. When multiple processing units are used,
the processing units may be heterogeneous. By way of a non-limiting
example, such a heterogeneous processing environment may include a
conventional CPU, a conventional graphics processing unit ("GPU"),
a floating-point unit ("FPU"), combinations thereof, and the
like.
[0085] The computing device 12 may be a conventional computer, a
distributed computer, or any other type of computer.
[0086] The system bus 23 may be any of several types of bus
structures including a memory bus or memory controller, a
peripheral bus, and a local bus using any of a variety of bus
architectures. The system memory 22 may also be referred to as
simply the memory, and includes read only memory (ROM) 24 and
random access memory (RAM) 25. A basic input/output system (BIOS)
26, containing the basic routines that help to transfer information
between elements within the computing device 12, such as during
start-up, is stored in ROM 24. The computing device 12 further
includes a hard disk drive 27 for reading from and writing to a
hard disk, not shown, a magnetic disk drive 28 for reading from or
writing to a removable magnetic disk 29, and an optical disk drive
30 for reading from or writing to a removable optical disk 31 such
as a CD ROM, DVD, or other optical media.
[0087] The hard disk drive 27, magnetic disk drive 28, and optical
disk drive 30 are connected to the system bus 23 by a hard disk
drive interface 32, a magnetic disk drive interface 33, and an
optical disk drive interface 34, respectively. The drives and their
associated computer-readable media provide nonvolatile storage of
computer-readable instructions, data structures, program modules,
and other data for the computing device 12. It should be
appreciated by those of ordinary skill in the art that any type of
computer-readable media which can store data that is accessible by
a computer, such as magnetic cassettes, flash memory cards, solid
state memory devices ("SSD"), USB drives, digital video disks,
Bernoulli cartridges, random access memories ("RAMs"), read only
memories ("ROMs"), and the like, may be used in the exemplary
operating environment. As is apparent to those of ordinary skill in
the art, the hard disk drive 27 and other forms of
computer-readable media (e.g., the removable magnetic disk 29, the
removable optical disk 31, flash memory cards, SSD, USB drives, and
the like) accessible by the processing unit 21 may be considered
components of the system memory 22.
[0088] A number of program modules may be stored on the hard disk
drive 27, magnetic disk 29, optical disk 31, ROM 24, or RAM 25,
including the operating system 35, one or more application programs
36, other program modules 37, and program data 38. A user may enter
commands and information into the computing device 12 through input
devices such as a keyboard 40 and pointing device 42. Other input
devices (not shown) may include a microphone, joystick, game pad,
satellite dish, scanner, touch sensitive devices (e.g., a stylus or
touch pad), video camera, depth camera, or the like. These and
other input devices are often connected to the processing unit 21
through a serial port interface 46 that is coupled to the system
bus 23, but may be connected by other interfaces, such as a
parallel port, game port, a universal serial bus (USB), or a
wireless interface (e.g., a Bluetooth interface). A monitor 47 or
other type of display device is also connected to the system bus 23
via an interface, such as a video adapter 48. In addition to the
monitor, computers typically include other peripheral output
devices (not shown), such as speakers, printers, and haptic devices
that provide tactile and/or other types of physical feedback (e.g.,
a force feedback game controller).
[0089] The input devices described above are operable to receive
user input and selections. Together the input and display devices
may be described as providing a user interface.
[0090] The computing device 12 may operate in a networked
environment using logical connections to one or more remote
computers, such as remote computer 49. These logical connections
are achieved by a communication device coupled to or a part of the
computing device 12 (as the local computer). Implementations are
not limited to a particular type of communications device. The
remote computer 49 may be another computer, a server, a router, a
network PC, a client, a memory storage device, a peer device or
other common network node, and typically includes many or all of
the elements described above relative to the computing device 12.
The remote computer 49 may be connected to a memory storage device
50. The logical connections depicted in FIG. 12 include a
local-area network (LAN) 51 and a wide-area network (WAN) 52. Such
networking environments are commonplace in offices, enterprise-wide
computer networks, intranets and the Internet. The network(s) 134
(see FIG. 1) may be implemented using one or more of the LAN 51 or
the WAN 52 (e.g., the Internet).
[0091] Those of ordinary skill in the art will appreciate that a
LAN may be connected to a WAN via a modem using a carrier signal
over a telephone network, cable network, cellular network, or power
lines. Such a modem may be connected to the computing device 12 by
a network interface (e.g., a serial or other type of port).
Further, many laptop computers may connect to a network via a
cellular data modem.
[0092] When used in a LAN-networking environment, the computing
device 12 is connected to the local area network 51 through a
network interface or adapter 53, which is one type of
communications device. When used in a WAN-networking environment,
the computing device 12 typically includes a modem 54, a type of
communications device, or any other type of communications device
for establishing communications over the wide area network 52, such
as the Internet. The modem 54, which may be internal or external,
is connected to the system bus 23 via the serial port interface 46.
In a networked environment, program modules depicted relative to
the personal computing device 12, or portions thereof, may be
stored in the remote computer 49 and/or the remote memory storage
device 50. It is appreciated that the network connections shown are
exemplary and other means of and communications devices for
establishing a communications link between the computers may be
used.
[0093] The computing device 12 and related components have been
presented herein by way of particular example and also by
abstraction in order to facilitate a high-level view of the
concepts disclosed. The actual technical design and implementation
may vary based on particular implementation while maintaining the
overall nature of the concepts disclosed.
[0094] In some embodiments, the system memory 22 stores computer
executable instructions that when executed by one or more
processors cause the one or more processors to perform all or
portions of one or more of the methods (including the method 200
illustrated in FIG. 2) described above. Such instructions may be
stored on one or more non-transitory computer-readable media.
[0095] The foregoing described embodiments depict different
components contained within, or connected with, different other
components. It is to be understood that such depicted architectures
are merely exemplary, and that in fact many other architectures can
be implemented which achieve the same functionality. In a
conceptual sense, any arrangement of components to achieve the same
functionality is effectively "associated" such that the desired
functionality is achieved. Hence, any two components herein
combined to achieve a particular functionality can be seen as
"associated with" each other such that the desired functionality is
achieved, irrespective of architectures or intermedial components.
Likewise, any two components so associated can also be viewed as
being "operably connected," or "operably coupled," to each other to
achieve the desired functionality.
[0096] While particular embodiments of the present invention have
been shown and described, it will be obvious to those skilled in
the art that, based upon the teachings herein, changes and
modifications may be made without departing from this invention and
its broader aspects and, therefore, the appended claims are to
encompass within their scope all such changes and modifications as
are within the true spirit and scope of this invention.
Furthermore, it is to be understood that the invention is solely
defined by the appended claims. It will be understood by those
within the art that, in general, terms used herein, and especially
in the appended claims (e.g., bodies of the appended claims) are
generally intended as "open" terms (e.g., the term "including"
should be interpreted as "including but not limited to," the term
"having" should be interpreted as "having at least," the term
"includes" should be interpreted as "includes but is not limited
to," etc.). It will be further understood by those within the art
that if a specific number of an introduced claim recitation is
intended, such an intent will be explicitly recited in the claim,
and in the absence of such recitation no such intent is present.
For example, as an aid to understanding, the following appended
claims may contain usage of the introductory phrases "at least one"
and "one or more" to introduce claim recitations. However, the use
of such phrases should not be construed to imply that the
introduction of a claim recitation by the indefinite articles "a"
or "an" limits any particular claim containing such introduced
claim recitation to inventions containing only one such recitation,
even when the same claim includes the introductory phrases "one or
more" or "at least one" and indefinite articles such as "a" or "an"
(e.g., "a" and/or "an" should typically be interpreted to mean "at
least one" or "one or more"); the same holds true for the use of
definite articles used to introduce claim recitations. In addition,
even if a specific number of an introduced claim recitation is
explicitly recited, those skilled in the art will recognize that
such recitation should typically be interpreted to mean at least
the recited number (e.g., the bare recitation of "two recitations,"
without other modifiers, typically means at least two recitations,
or two or more recitations).
[0097] Accordingly, the invention is not limited except as by the
appended claims.
* * * * *