U.S. patent application number 14/489241 was filed with the patent office on 2016-03-17 for controlled access queue-based gating based on cooperative detection of viable registration.
This patent application is currently assigned to LIVE NATION ENTERTAINMENT, INC.. The applicant listed for this patent is Live Nation Entertainment, Inc.. Invention is credited to Debbie Hsu, Robert McEwen.
Application Number | 20160078370 14/489241 |
Document ID | / |
Family ID | 49301094 |
Filed Date | 2016-03-17 |
United States Patent
Application |
20160078370 |
Kind Code |
A1 |
McEwen; Robert ; et
al. |
March 17, 2016 |
CONTROLLED ACCESS QUEUE-BASED GATING BASED ON COOPERATIVE DETECTION
OF VIABLE REGISTRATION
Abstract
Before tickets for an event go onsale, users are allowed to
register for the event. The registration requires completion of
verification steps useful for discriminating between human and
robot users. Due to the complexity of the first verification step,
it can be estimated that registered users are more likely than
other users to be human. Registered users are allowed to
electronically submit requests for tickets for the event prior to
the tickets going on sale. Unregistered users must wait to request
tickets until a later time (e.g., when the tickets are onsale) and
may--at that time--complete similar or simpler verification steps,
further delaying receipt of their requests. Requests from
registered users may further be preferentially served simply due to
the registrations. Thus, tickets can be preferentially provided to
users estimated to be more likely to be human.
Inventors: |
McEwen; Robert; (Los
Angeles, CA) ; Hsu; Debbie; (Los Angeles,
CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Live Nation Entertainment, Inc. |
Beverly Hills |
CA |
US |
|
|
Assignee: |
LIVE NATION ENTERTAINMENT,
INC.
Beverly Hills
CA
|
Family ID: |
49301094 |
Appl. No.: |
14/489241 |
Filed: |
September 17, 2014 |
Current U.S.
Class: |
705/5 |
Current CPC
Class: |
G06F 21/604 20130101;
G06F 21/31 20130101; G06F 21/316 20130101; G06F 21/6218 20130101;
G06F 9/50 20130101; G06Q 10/02 20130101; G06Q 50/01 20130101; G06Q
20/405 20130101; G06F 16/2455 20190101; G06F 21/62 20130101; G06F
2221/2133 20130101; H04L 63/102 20130101; G06F 9/5005 20130101;
G06F 21/44 20130101; H04L 63/083 20130101; G06Q 20/401
20130101 |
International
Class: |
G06Q 10/02 20060101
G06Q010/02; G06F 17/30 20060101 G06F017/30; G06Q 20/40 20060101
G06Q020/40 |
Claims
1. A ticket management system for offering tickets to an event to
users in an iterative and prioritized manner, the ticket management
system comprising: a ticket offerer that, prior to a beginning of
an onsale period during which tickets for the event are sold:
electronically presents information about the event to a set of
users, the set of users including a first user and a second user,
and electronically presents the first user with an invitation to
electronically register for the event; a ticket requestor that:
prior to the beginning of the onsale period, receives, from the
first user, a first request to register for the event; facilitates
a first electronic presentation of a verification step at a first
electronic device associated with the first user, the verification
step including a Completely Automated Public Turing test to tell
Computers and Humans Apart (CAPTCHA) test; determines, based on the
verification step, that the first user is a human and not a robot;
upon determining that the first user has completed the verification
step: registers the first user for the event prior to the beginning
of the onsale period, and electronically presents the first user,
but not the second user, with an interface to request a ticket for
the event prior to the beginning of the onsale period, wherein the
second user has not completed the verification step prior to the
beginning of the onsale period and the interface is not presented
to the second user prior to the beginning of the onsale period due
to the second user not having completed the verification step, and
receives a first request from the first user and a second request
from the second user, wherein each of the first request and the
second request is a request for the ticket to the event, wherein
the first request is received prior to the beginning of the onsale
period, and wherein the second request is received after the
beginning of the onsale period; a queue engine that, using one or
more processors, places the first request in a queue and the second
request in the queue queue, the first request being prioritized
over the second request due to the first user having completed the
verification step prior to the onsale period and the second user
not having completed the verification step prior to the onsale
period; and a ticket browser that, using the one or more
processors, after the beginning of the onsale period: accesses the
queue, performs a first search of a ticket database, the first
search being responsive to the first request, performs a second
search of the ticket database, the second search being responsive
to the second request, wherein the second search is performed after
the first search due to the first request being prioritized over
the second request, and receives results for the first search that
includes an identification of one or more tickets for the
event.
2. The ticket management system for offering tickets to the event
to users in the iterative and prioritized manner as recited in
claim 1, wherein the ticket browser further offers the first user a
first ticket found in response to the first search, and wherein the
ticket browser modifies the ticket database such that the first
ticket is at least temporarily identified as not being available to
offer to other users.
3. The ticket management system for offering tickets to the event
to users in the iterative and prioritized manner as recited in
claim 1, wherein: the ticket requestor further facilitates a second
electronic presentation of the verification step at a second
electronic device associated with the second user; the verification
step is presented after the second request is received, and the
ticket browser only performs the second search when the
verification step is completed by the second user.
4. The ticket management system for offering tickets to the event
to users in the iterative and prioritized manner as recited in
claim 1, wherein completion of the verification step includes
performing an act that requires access to an electronic system
independent from the ticket management system.
5. (canceled)
6. The ticket management system for offering tickets to the event
to users in the iterative and prioritized manner as recited in
claim 1, wherein: the queue engine further generates a first score
for the first request and a second score for the second request,
the generation of the first score depending on at least how the
first user performed the verification test the generation of the
second score depending on at least how the second user performed
the verification test; and the queue engine prioritizes the first
request and the second request at least partly based on the first
and second scores.
7. The ticket management system for offering tickets to the event
to users in the iterative and prioritized manner as recited in
claim 6, wherein the generation of the first and second scores
further depends on whether the respective first and second users
are registered for the event.
8. The ticket management system for offering tickets to the event
to users in the iterative and prioritized manner as recited in
claim 1, wherein the presenting of the verification step includes
presenting a set of suggested verification steps, and wherein the
ticket requestor determines that the first user has completed the
verification step by determining that the first user has completed
a sufficient number of the suggested verification steps.
9. The ticket management system for offering tickets to the event
to users in the iterative and prioritized manner as recited in
claim 1, wherein the second user's access to any results from the
second search is artificially inhibited, the artificial inhibition
being separate from any first delay based on the placement of the
second request in the queue and from any second delay attributable
to performing the second search.
10. A method for offering tickets to an event to users in an
iterative and prioritized manner, the method comprising: prior to a
beginning of an onsale period during which tickets for the event
are sold, electronically presenting information about the event to
a set of users, the set of users including a first user and a
second user; electronically presenting the first user with an
invitation to electronically register for the event; prior to the
beginning of the onsale period, receiving, from the first user, a
request to register for the event; facilitating a first electronic
presentation of a verification step at a first electronic device
associated with the first user, the verification step including a
Completely Automated Public Turing test to tell Computers and
Humans Apart (CAPTCHA) test; determining, based on the verification
step, that the first user is a human and not a robot; upon
determining that the first user has completed the verification
step: registering the first user for the event prior to the
beginning of the onsale period; and electronically presenting the
first user, but not the second user, with an interface to request a
ticket for the event prior to the beginning of the onsale period,
wherein the second user has not completed the verification step
prior to the beginning of the onsale period and the interface is
not presented to the second user prior to the beginning of the
onsale period due to the second user not having completed the
verification step; receiving a first request from the first user
and a second request from the second user, wherein each of the
first request and the second request is a request for the ticket to
the event, wherein the first request is received prior to the
beginning of the onsale period, and wherein the second request is
received after the beginning of the onsale period; placing the
first request in a queue and the second request in the queue, the
first request being prioritized over the second request due to the
first user having completed the verification step prior to the
onsale period and the second user not having completed the
verification step prior to the onsale period; after the beginning
of the onsale period, performing a first search of a ticket
database, the first search being responsive to the first request;
performing a second search of the ticket database, the second
search being responsive to the second request, wherein the second
search is performed after the first search due to the first request
being prioritized over the second request, and receiving results
for the first search that includes an identification of one or more
tickets for the event.
11. The method for offering tickets to the event to users in the
iterative and prioritized manner as recited in claim 10, further
comprising: offering the first user a first ticket found in
response to the first search, and modifying the ticket database
such that the first ticket is at least temporarily identified as
not being available to offer to other users.
12. The method for offering tickets to the event to users in the
iterative and prioritized manner as recited in claim 10, further
comprising: facilitating a second electronic presentation of the
verification step at a second electronic device associated with the
second user, wherein the second search is only performed when the
verification step is completed by the second user.
13. (canceled)
14. The method for offering tickets to the event to users in the
iterative and prioritized manner as recited in claim 10, further
comprising: generating a first score for the first request and a
second score for the second request, wherein: the generation of the
first score depending on at least how the first user performed the
verification test, the generation of the second score depending on
at least how the second user performed the verification test, the
first request and the second request are prioritized at least
partly based on the first and second scores.
15. The method for offering tickets to the event to users in the
iterative and prioritized manner as recited in claim 14, wherein
the generation of the first and second scores further depends on
whether the respective first and second users are registered for
the event.
16. The method for offering tickets to the event to users in the
iterative and prioritized manner as recited in claim 10, wherein
the presenting of the verification step includes presenting a set
of suggested verification steps, and wherein the ticket requestor
determines that the first user has completed the verification step
by determining that the first user has completed a sufficient
number of the suggested verification steps.
17. A ticket management system for offering tickets to the event to
users in the iterative and prioritized manner, the ticket
management system comprising: one or more processors; and one or
more memories coupled with the one or more processors, wherein the
one or more processors and one or more memories are configured to:
prior to a beginning of an onsale period during which tickets for
the event are sold, electronically present information about the
event to a set of users, the set of users including a first user
and a second user; electronically present the first user with an
invitation to electronically register for the event; prior to the
beginning of the onsale period, receive, from the first user, a
request to register for the event; facilitates a first electronic
presentation of a verification step at a first electronic device
associated with the first user, the verification step including a
Completely Automated Public Turing test to tell Computers and
Humans Apart (CAPTCHA) test; prior to the beginning of the onsale
period, determines, based on the verification step, that the first
user is a human and not a robot; upon determining that the first
user has completed the verification step: register the first user
for the event prior to the beginning of the onsale period, and
present the first user, but not the second user, with an interface
to request a ticket for the event prior to the beginning of the
onsale period, wherein the second user has not completed the
verification step prior to the beginning of the onsale period and
the interface is not presented to the second user prior to the
beginning of the onsale period due to the second user not having
completed the verification step; and receive a first request from
the first user and a second request from the second user, wherein
each of the first request and the second request is a request for
the ticket to the event, wherein the first request is received
prior to the beginning of the onsale period, and wherein the second
request is received after the beginning of the onsale period; place
each of the first request and the second request in a single queue,
the first request being prioritized over the second request due to
the first user having completed the verification step prior to the
onsale period and the second user not having completed the
verification step prior to the onsale period; and after the
beginning of the onsale period: perform a first search of a ticket
database, the first search being responsive to the first request;
perform a second search of the ticket database, the second search
being responsive to the second request, wherein the second search
is performed after the first search due to the first request being
prioritized over the second request, and receive results for the
first search that includes an identification of one or more tickets
for the event.
18. The ticket management system for offering tickets to the event
to users in the iterative and prioritized manner as recited in
claim 17, wherein the one or more processors and one or more
memories are further configured to: offer the first user a first
ticket found in response to the first search, and modify the ticket
database such that the first ticket is at least temporarily
identified as not being available to offer to other users.
19. The ticket management system for offering tickets to the event
to users in the iterative and prioritized manner as recited in
claim 17, wherein the one or more processors and one or more
memories are further configured to: present the second user with
the verification step after the second request is received, wherein
the second search is performed when the verification step is
completed by the second user.
20. The ticket management system for offering tickets to the event
to users in the iterative and prioritized manner as recited in
claim 17, wherein: the one or more processors and one or more
memories are further configured to generate a first score for the
first request and a second score for the second request, the
generation of the first score depending on at least how the first
user performed the verification test; the generation of the second
score depending on at least how the second user performed the
verification test; and the first request and the second request are
prioritized at least partly based on the first and second
scores.
21. The method of claim 10, wherein the second user's access to any
results from the second search is artificially inhibited, the
artificial inhibition being separate from any first delay based on
the placement of the second request in the queue and from any
second delay attributable to performing the second search.
22. The ticket management system for offering tickets to the event
to users in the iterative and prioritized manner as recited in
claim 17, wherein the second user's access to any results from the
second search is artificially inhibited, the artificial inhibition
being separate from any first delay based on the placement of the
second request in the queue and from any second delay attributable
to performing the second search.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of and priority to PCT
application No. PCT/US2013/035487, filed Apr. 5, 2013, which claims
the benefit of U.S. Provisional Application No. 61/621,388, filed
on Apr. 6, 2012. Each of these applications is hereby incorporated
by reference in its entirety for all purposes.
BACKGROUND
[0002] This disclosure relates in general to methods and systems
for assigning resources via a network, and in particular, to
methods and systems for inhibiting access to network resources by
automated programs.
[0003] Initial sales of event tickets are increasingly being
performed online. However, many ticket brokers utilize automated
programs to reserve and purchase tickets. Because these automated
programs act quicker than a human can, the automated programs are
able to reserve and purchase large amount of tickets for the best
seats before humans can. Thus, fans are often prevented from being
able to reserve and purchase the desirable tickets early and for
initial-sale prices.
SUMMARY
[0004] In one embodiment, the present disclosure provides a method
and system for offering tickets to an event to users in an
iterative and prioritized manner. Before tickets for an event go
onsale, users are provided with the opportunity to register for the
event. The registration requires completion of verification steps
useful for discriminating between human and robot users (e.g.,
verifying an email account, completing a CAPTCHA test, etc.).Due to
the complexity of the verification steps, it can be estimated that
registered users are more likely than other users to be human.
Registered users are allowed to electronically submit requests for
tickets for the event prior to the tickets going on sale.
Unregistered users must wait to request tickets until a later time
(e.g., when the tickets are onsale) and may--at that time--complete
similar or simpler verification steps, further delaying receipt of
their requests. Requests from registered users may further be
preferentially served simply due to the registrations. Thus,
tickets can be preferentially provided to users estimated to be
more likely to be human.
[0005] In one instance, each request is assigned a score, and
requests are served in an order based on the score. The score can
depend on a number of verification steps completed and/or an
accuracy of the completion(s). Verification steps can be presented
to registered users before they are presented to unregistered
users, making it more likely that they will receive desired tickets
to the event.
[0006] In some embodiments, a ticket management system is provided
for offering tickets to an event to users in an iterative and
prioritized manner. A ticket offerer electronically presents
information about the event to a set of users. The set of users
includes a first user and a second user. The ticket offerer also
electronically presents, prior to a beginning of an onsale period,
the first user with an invitation to electronically register for
the event. The onsale period is a time period during which tickets
for the event are sold. A ticket requestor receives, from the first
user, a request to register for the event and electronically
presents the first user with a verification step useful for
discriminating between human and robot users. The ticket requestor
also determines that the first user has completed the verification
step prior to the beginning of the onsale period, determines that
the second user has not completed the verification step prior to
the beginning of the onsale period and registers the first user for
the event. The ticket requestor further, upon determining that the
first user has completed the verification step, electronically
presents the first user, but not the second user, with an interface
to request a ticket for the event prior to the beginning of the
onsale period. The interface is not presented to the second user
prior to the beginning of the onsale period due to the
determination that the second user has not completed the
verification step. The ticket requestor receives a first request
from the first user and a second request from the second user. Each
of the first request and the second request is a request for the
ticket to the event. The first request is received prior to the
beginning of the onsale period, and wherein the second request is
received after the beginning of the onsale period. A queue engine
places each of the first request and the second request in a single
queue, the first request being prioritized over the second request.
A ticket browser accesses the queue and performs a first search of
a ticket database. The first search is responsive to the first
request. The ticket browser also performs a second search of the
ticket database, the second search being responsive to the second
request, wherein the second search is performed after the first
search due to the first request being prioritized over the second
request.
[0007] In some embodiments, a method is provided for offering
tickets to an event to users in an iterative and prioritized
manner. Information about the event is electronically presented to
a set of users. The set of users includes a first user and a second
user. Prior to a beginning of an onsale period, the first user is
electronically presented with an invitation to electronically
register for the event. The onsale period is a time period during
which tickets for the event are sold. A request to register for the
event is received from the first user. The first user is
electronically presented with a verification step useful for
discriminating between human and robot users. It is determined that
the first user has completed the verification step prior to the
beginning of the onsale period. It is further determined that the
second user has not completed the verification step prior to the
beginning of the onsale period. The first user is registered for
the event. Upon determining that the first user has completed the
verification step, the first user, but not the second user, is
presented with an interface to request a ticket for the event prior
to the beginning of the onsale period. The interface is not
presented to the second user prior to the beginning of the onsale
period due to the determination that the second user has not
completed the verification step. A first request is received from
the first user, and a second request is received from the second
user, wherein each of the first request and the second request is a
request for the ticket to the event, wherein the first request is
received prior to the beginning of the onsale period, and wherein
the second request is received after the beginning of the onsale
period. Each of the first request and the second request is placed
in a single queue. The first request is prioritized over the second
request. A first search of a ticket database is performed. The
first search is responsive to the first request. A second search of
the ticket database is performed. The second search is responsive
to the second request. The second search is performed after the
first search due to the first request being prioritized over the
second request.
[0008] In some embodiments, a ticket management system is provided
for offering tickets to the event to users in the iterative and
prioritized manner. The ticket management system includes one or
more processors and one or more memories coupled with the one or
more processors. The one or more processors and one or more
memories are configured to a method is provided for offering
tickets to an event to users in an iterative and prioritized
manner.
[0009] Further areas of applicability of the present disclosure
will become apparent from the detailed description provided
hereinafter. It should be understood that the detailed description
and specific examples, while indicating various embodiments, are
intended for purposes of illustration only and are not intended to
necessarily limit the scope of the disclosure.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] The present disclosure is described in conjunction with the
appended figures:
[0011] FIG. 1 depicts a block diagram of an embodiment of a ticket
interaction system;
[0012] FIG. 2 depicts a block diagram of an embodiment of ticket
management system;
[0013] FIG. 3 illustrates a flowchart of an embodiment of a process
for presenting an offer for tickets to a user;
[0014] FIG. 4 illustrates a flowchart of an embodiment of a process
for receiving pre-onsale ticket requests using a queue;
[0015] FIG. 5 illustrates a flowchart of an embodiment of a process
for receiving onsale ticket requests using a queue;
[0016] FIG. 6 illustrates a flowchart of an embodiment of a process
for assigning tickets to users using a queue;
[0017] FIG. 7 illustrates a flowchart of an embodiment of a process
for prioritizing requests for tickets for an event.
[0018] FIG. 8 depicts a block diagram of an embodiment of a
computer system; and
[0019] FIG. 9 depicts a block diagram of an embodiment of a
special-purpose computer system.
[0020] In the appended figures, similar components and/or features
can have the same reference label. Further, various components of
the same type can be distinguished by following the reference label
by a dash and a second label that distinguishes among the similar
components. If only the first reference label is used in the
specification, the description is applicable to any one of the
similar components having the same first reference label
irrespective of the second reference label.
DETAILED DESCRIPTION
[0021] The ensuing description provides preferred exemplary
embodiment(s) only and is not intended to limit the scope,
applicability or configuration of the disclosure. Rather, the
ensuing description of the preferred exemplary embodiment(s) will
provide those skilled in the art with an enabling description for
implementing a preferred exemplary embodiment. It is understood
that various changes can be made in the function and arrangement of
elements without departing from the spirit and scope as set forth
in the appended claims.
[0022] As similarly discussed above, sales of event tickets are
increasingly being performed online. However, many ticket brokers
utilize automated programs to reserve and purchase tickets being
offered via such online sales. Because these automated programs act
quicker than a human can, the automated programs are able to
reserve and purchase large amounts of tickets for the best seats
before humans can. Thus, fans are often prevented from being able
to reserve and purchase the more tickets for the more desirable
seats (e.g., seats that are closer to the stage for a concert, that
are closer to the center-line (mid-court line) and court for a
basketball game, that are closer to the 50 yard line and playing
field for a football game, etc.). Further, pricing control can be
largely transferred from an event provider to third-party
intermediaries.
[0023] Further yet, such automated programs pose a technical
problem as they can greatly increase the peak demand placed on a
ticketing system infrastructure trying to respond to the enormous
numbers of ticket requests being submitted in the first seconds and
minutes tickets are placed on sale. Thus, additional processing
power, memory, and bandwidth need to be brought online to service
such peak requests, or user requests will need to be queued for
long periods of time before the requests or serviced, or they can
simply not be able to access or utilize various purchase request
controls. Additionally, because many of the tickets initially
reserved by the automated programs are not finally purchased by the
automated program operator, the system is further loaded with the
task of having to reassign large numbers of reserved (and then
released) tickets, to other requesters. Humans interested in
attending an event can also be deprived of this opportunity, as the
system utilization by robots can delay humans' access to the system
to an extent deemed unacceptable by the humans, leading them to
abandon their ticket-purchasing efforts. Because the robots
frequently do not complete their ticket purchases, the tickets are
wasted, humans are not able to enjoy the event, and the event
provider loses potential profits.
[0024] To attempt to inhibit robot use of ticketing system, a
CAPTCHA (Completely Automated Public Turing test to tell Computers
and Humans Apart) technique can be used to present distorted text
to a user and to request that the user then enter the text into a
field. However, many automated programs have become more advanced
and are able to recognize and enter such text into the specified
field, thereby negating much of the intended benefits of such
CAPTCHA techniques. Further, such a technique can make it more
difficult for humans to request tickets. Additionally, the
successful completion by a human user of such a test does not
provide a particular user with any benefits other than the ability
to submit the ticket request.
[0025] As will be described in greater detail below, in certain
embodiments, a user can be invited to register for a ticketing
offering (e.g., prior to the start of an onsale) for an event in
order to submit, via a ticketing system, a pre-onsale purchase
request for tickets for the event. As part of the registration
process, the user is requested to provide certain information
and/or perform certain acts which enable the ticketing system to
estimate that the user is a human and not an automated program
(also referred to as a "bot" or "robot"). Advantageously, the
information requests and/or requested acts can be configured so
that they are fun for the user to respond to, to thereby further
motivate the user to complete the verification process and to
provide the user with an enjoyable experience. Further, the user
responses/acts can provide additional information about the user,
which in turn can be utilized to select and provide the user with
information that may be of interest to the user and/or offer
services/products (e.g., event tickets for certain types of events
or certain performers) that may be of interest to the user.
[0026] Further, the registered/registering user can specify a
certain ticket price level and/or seating area, or specify that the
ticket system is to select the seats for the user without
specifying a price level and/or a seating area (e.g., the best
available seats). Then, at a later time (which can be a
substantially later time, such as one or more hours or one or more
days, weeks, or months later), the system can identify tickets
matching (or matching as closely as possible or within a certain
range) the user's specification. The priority in which tickets are
identified for users can be based in whole or in part on the
requesting users' performance of a robot detection process. For
example, a higher rank can be assigned to a user who provided more
information or performed more acts, and the ticket request ranking
can be utilized in determining which ticket requests are to be
serviced first.
[0027] Optionally, during an onsale period, identification of
tickets responsive to ticket requests received within a submission
window (e.g., a pre-onsale period, during which tickets are not
identified to certain or any users submitting ticket requests) is
not based on the date or timing of the submission within that
pre-onsale submission window (e.g., ticket searches are optionally
not made on a first-come first serve basis). This can enable fair
competition, rather than distributing tickets solely on how quickly
purchase requests are submitted (by robots or humans) within the
submission window. Further, because the success rate will be much
lower, this technique can discourage the use of automated programs
for acquiring desirable tickets, which will reduce the loading on
the ticketing system during the onsale period. The onsale period
can include the sale of event tickets at a price (where users do
not have to bid for the tickets in an auction). The number of
ticket requests received during the pre-onsale, registration period
can be used to adjust or set prices for seat tickets for the onsale
period.
[0028] Referring first to FIG. 1, a block diagram of an embodiment
of a ticket interaction system 100 is shown. Users 105 and event
providers 115 (e.g., a sports team manager or a vendor operator)
can interact with a ticket management system 150 via respective
devices 110 and 120 and a network, such as the Internet 140 or a
wide area network (WAN), local area network (LAN) 114 or other
backbone. In some embodiments, ticket management system 150 is made
available to one or more of users 105 and/or event providers 115
via an app (that can be downloaded to and executed on a portable
electronic device) or a website. It will be understood that,
although only one user 105 and event provider 115 are shown, system
100 can include multiple users 105 and/or event providers 115.
[0029] Using the ticket management system 150, an event provider
115 can identify an event, a price of attending the event, a date
or dates of the event, a location or locations of the event, etc.
Examples of events for which tickets can be obtained include
sporting events, concerts, meals, shows, movies, and amusement
parks. As described further below, ticket management system 150 can
use the information provided by event provider 115 to allocate
tickets for the event, generate an offer and present offer
information to users 105. For each event, ticket management system
150 can generate and store one or more offer records in an offer
database 160, each offer record including event information (a date
and name of the event) and ticket information (e.g., a maximum
number of tickets to be sold, a price for a ticket, etc.).
[0030] A user 105 can then use the ticket management system 150 to
identify offer information and/or to purchase a ticket for an
event. In some instances, a user 105 can be allowed to create and
use an account before using one or more features of ticket
management system 150. For example, purchasing a ticket or
registering for an event to request tickets can require that a user
105 be logged into his account. Account database 170 can, for each
account, store information about the user, such as identifying
information, contact information, a history of interactions with
system 150, event preferences, and payment information. Examples of
account information includes a user's name, email address, credit
card information, home address, phone number, types of events of
interest, etc. Once an account is created, a user can access the
account by entering a username or email address and a password.
Alternatively, such login information can be saved, or cookies can
be utilized such that the user is always logged in while using a
particular device.
[0031] Using ticket management system 150, a user 105 can be able
to request a ticket for an event. As described in further detail
below, the request can be an advance or real-time request.
Specifically, a user 105 can register for an event before tickets
go on sale and request tickets. Alternatively, a user 105 can wait
until tickets are onsale and request tickets. Either request can
result in the user 105 being added to a queue (stored in queue
database 180). In some instances, requests by registered users are
prioritized over other requests in the queue.
[0032] An onsale period can be characterized in that a user's
ticket requests can be quickly responded to and the user can be
quickly informed as to whether tickets were identified in response
to the user's search or whether there are no available tickets
(e.g., that meet the user's specified criteria). For example,
during an onsale, users can submit ticket requests and be informed
shortly thereafter by the system (e.g., within 1 second, 5 second,
30 seconds, 1 minute, 2 minutes, 10 minutes) whether tickets have
been identified in response to a user's search, and, in certain
circumstances, for which seats (if, for example, the tickets are
for a reserved seat event as opposed to a general admission event).
An onsale can also be in the form of an auction, during which a
user's bid is received and processed and used to generate new
minimum bids for a given ticket or ticket type.
[0033] When the tickets for an event go onsale, ticket management
system 150 iteratively searches for tickets available to a user 105
for purchase. One or more queues tied to the event can be used to
determine which users are to be placed earlier in the iteration. If
a user accepts and pays for a ticket, the ticket is then assigned
to the user. The assigned ticket is no longer available to other
users and can be accessed by the user (e.g., such that the user can
view the ticket, print the ticket, or transmit information from the
ticket), such that the user can redeem the ticket. The assigned
ticket can be stored in a ticket database 190, which can be a
central database or a database tied to the user's account. Either
way, the assignment can be reflected in the database, and the user
can be allowed to access the ticket (e.g., using user device
110).
[0034] The ticket provides the user with a right, such as a right
to attend an event and/or to receive a service (e.g., a dinner
service at a show). The right can, however, be restricted (e.g.,
based on an expiration date, prohibited dates of redemption, etc.).
In some instances, a ticket can be equivalent to a voucher, gift
card, and/or coupon, which can be valid for use for an absolute
amount, a percentage amount, or a functional amount (e.g., three
movie tickets). The ticket can be electronic or tangible and can
change between the states (e.g., being electronic when purchased
but tangible after a user prints it).
[0035] User device 110 and/or event-provider device 120 can each be
a single electronic device, such as a hand-held electronic device
(e.g., a smartphone. It will be understood that user device 110
and/or event-provider device 120 can also include a system that
includes multiple devices and/or components. The device(s) 110
and/or 120 can comprise a computer, such as the desktop computer, a
laptop computer or a tablet. In some instances, a party 105, and/or
115 uses different devices at different times to interact with the
ticket management system 150. For example, user 105 can use a
desktop computer initially to purchase a ticket, and user 105 can
later use a smartphone to access the purchased ticket and redeem it
at an event.
[0036] Referring next to FIG. 2, a block diagram of an embodiment
of ticket management system 150 is shown. Ticket management system
150 can be, in part or in its entirety, in a cloud. In some
instances, at least part of ticket management system 150 is present
on a device, such as a user device 110 and/or event-provider device
120. For example, a CAPTCHA engine 235 (described further below) or
ticket requestor 230 can be on user device 105, and a ticket
browser 250 can be in a cloud. In some instances, part of a
component (e.g., part of ticket requestor 230) resides in a cloud
and another part of the component resides in a device. Thus, ticket
management system 150 can include a distributed system.
[0037] Ticket management system 150 includes an offer engine 205,
which collects information about particular offers (e.g., from an
event provider 115). For example, the information can identify an
event or service for which the offer is available, time or times of
the event or service, location or locations of the event or
service, a price or prices for a ticket to or for the event or
service, or a minimum price for a ticket to the event or service.
The information can further include a time period during which the
offer is to be made available. The information can further identify
restrictions on the offer. For example, an event provider 115 can
limit a number of tickets available for a particular event. As
another example, an event provider 115 can indicate that tickets
are only to be issued to users indicating that they are 18 or
older. As yet another example, an event provider 115 can indicate
that use of a ticket requires a purchase, such as a purchase of the
dinner while attending a show.
[0038] The offer information (which can include any associated
restrictions) is stored in offer database 160. A ticket offerer 210
generates one or more presentations of the offer, which can include
high-level information, short summaries and/or graphics. Ticket
offerer 210 then presents (e.g., electronically presents via a
provided user interface) the presentation of the offer to some or
all users 105. The offer can be presented via an app. For example,
a user 105 can be presented with a summary of an event upon
initially accessing the app, or a user 105 can be presented with
the summary of the event upon searching for events using the app.
In some instances, the offer is sent to users 105 (e.g., via email
or text message). In some instances, offer information is only
presented to or sent to users 105 with an account for the ticket
management system 150, but in some instances, offer information is
also presented to other users.
[0039] In some instances, offer information is presented on a
dedicated page, such as a webpage or a page displayed using an app.
The user may have navigated to the dedicated page via a search
result listing (e.g., where the user may have searched for a
concert or performer, and a link to the user interface was provided
in the search result listing), via a link provided via user
interface specifically regarding the performer (which can be hosted
by ticket management system 150 or by another system, such as a
system hosting a fan club site operated by the performer or a fan),
via a link provided by a social networking site (e.g., via a page
operated by the ticket system operator, a fan, or other entity),
via a paid advertisement included in a document, such as a web
page, etc.
[0040] The presentation of the offer can include information
regarding the event, including performer(s) name(s), a venue name,
a venue location, a venue seating chart, ticket price levels and
seating areas associated therewith, and the date and time of the
event. The presentation of the offer can include information about
user interest in an event, such as by identifying a number of
"fans" of the event, presenting partial or full identities of fans
of the event, supporting a chat or message on a dedicated event
page, or allowing users to post images or movies related to the
event onto the dedicated event page. The page can further allow or
encourage a user to share information or enthusiasm about an event,
e.g., by linking to or liking the event via a social-network site
or sending information about the event to others via an email or
other type of message. The presentation can enable users to share
their "check-in" status on social networking services, such as
Facebook.RTM., LinkedIn.RTM., Twitter.RTM., Google+, etc.
[0041] Merchandise and other ancillary items (e.g., parking, food)
related to the performer(s) or event can be displayed and offered
for purchase. A media area can display and play videos (optionally
including audio tracks) and photographs, or play audio tracks
posted by users, the performer(s), and/or other entity. The videos
and photographs can be of the performer(s) and/or prior events
involving the performer(s). Controls can be provided enabling the
user to play, rewind, fast forward, and pause video and audio
tracks. Controls can also be provided enabling a user to download
such photographs/videos/audio tracks to the user terminal.
[0042] Ticket offerer 210 can further present information about
event tickets. For example, seating zones in a venue and respective
pricing can be identified using zone-colored graphics and/or text,
e.g., on a dedicated event page. A predicted or actual interest in
specific types of tickets (e.g., associated with different seating
zones) can also be presented. Ticket offerer 210 can present an
indication about when offered tickets will be onsale and/or a time
until the tickets are onsale (e.g., using a countdown timer).
[0043] Ticket offerer 210 can present one or more users 105 with
the option to register for an event and/or to become fans of an
event (e.g., the option(s) being presented on a dedicated event
page). The option can be presented along with advantages of
registering (e.g., prioritization of requests for tickets to the
event), advantages of becoming a fan (e.g., receiving notices via
an account page or message about a time remaining until tickets are
onsale or a prioritization of requests for tickets to the event)
and/or registration requirements (e.g., passing CAPTCHA tests
and/or entering information).
[0044] In some instances, information presented to users 105 logged
into an account differs from that presented to other users. For
example, two event pages can be generated--the first for logged-in
users and having event-registration options and the second for
other users and having an account-generation option, no
registration option and less event detail. As another example, a
same initial event page can be available to all users, but a
separate registration page (e.g., a pop-up window) can only be
available to users logged into their accounts.
[0045] Ticket management system 150 can limit the actions by the
user 105 can perform until or unless he creates and logs into an
account. For example, the user 105 can be unable to view any
offers, search for offers, register for an event, purchase tickets,
and/or access purchased tickets until or unless he logs into his
account. User 105 can interact with an account generator 215 in
order to create an account. In this process, the user can be asked
to provide information about himself, such as his name, email
address, telephone number, home address, types of events or
services of interest and/or payment information, such as
credit-card numbers. In some instances, account generation is free,
and in some instances, generation requires a fee. User 105 can also
be asked to provide a username (or email address) and password.
During the generation, user 105 can be asked to agree to certain
terms of service. For example, user 105 can be asked to agree to
receive notifications of offers and/or promotions. Completion of
the account generation can be conditioned upon receiving
information from the user and/or his agreement to terms of service.
Account generator 215 stores account information (i.e., personal
information and/or login information) in account database 170.
[0046] Subsequently, when user 105 attempts to access his account
(by logging into his account or opening an app associated with
ticket management system 150), a user validator 220 can verify that
such access is permissible. For example, user validator 220 can
ensure that a username and password matches that of an account
stored in database 170. As another example, user validator 220 can
ensure that user 105 had not previously logged off of his account
on a particular electronic device.
[0047] Once the verification is complete, user validator 220 grants
user 105 access to his account, and a ticket accessor 225 grants
user 105 access to tickets owned by user 105 and associated with
the account. User validator 220 can further ensure that appropriate
information (e.g., event registration options, notifications about
time-to-onsale for events for which the user is a fan, special
pricing, etc.) is presented to the user 105 following the log
in
[0048] A ticket requestor 230 handles event registrations,
post-registration pre-onsale ticket requests and onsale ticket
requests. These actions can be from logged-in users and/or users
who are not logged in. While ticket requestor 230 is shown as a
single component, it will be appreciated that it can nonetheless be
composed of multiple separate sub-components (e.g., a registration
engine, a pre-onsale ticket requestor and an onsale ticket
requestor).
[0049] Ticket requestor 230 can first detect a user request (e.g.,
to register for an event or to purchase tickets). The user request
can include an identification of an event, a ticket preference or
restriction (e.g., a seating-zone preference, a price preference
and/or a number of requested tickets) and/or user-identifying
information. For example, a user can specify a price level or a not
to exceed price level of the tickets (e.g., $12 per ticket, $45 or
less per ticket, $70 or less per ticket, any price). In addition or
instead, the user can be able to specify desired seating sections
and/or select specific seats (e.g., via a seating chart where the
user can select specific seats by clicking on representations of
the seats).
[0050] Ticket requestor 230 can then determine whether the user is
authorized to complete the requested action. The authorization can
depend on, e.g., whether the user is logged into an account,
whether an onsale period has begun, whether the user passes one or
more CAPTCHA tests, whether the user has a verified account (e.g.,
based on input identifying a social-media account, previous
purchase history and/or valid account login information), whether
the user is a suspected threat (e.g., based on previous fraudulent
activity, and/or entry of invalid (e.g., payment or identification)
information, a high number of user-initiated requests).
[0051] As part of the authorization determination, ticket requestor
230 can request information from user 105. For example, to estimate
whether user 105 is a human, ticket requestor 230 can request that
user 105 complete one or more CAPTCHA tests. A CAPTCHA engine 235
can generate a test. The test can include, e.g., a graphic
including a series of characters and text identifying the
characters or any other test likely to be failed by a robot (e.g.,
an audio file speaking characters or words and text identifying the
characters or words, or an image and possible choices indicating
what was in the image and the correct answer). Ticket requestor 230
can then present the test to user 105 and determine whether the
user responded correctly.
[0052] One or more user actions (e.g., registering for an event,
requesting a ticket, or selecting a specific ticket) can require a
payment. Ticket requestor 230 can identify any required payment to
payment engine 240. Payment engine 240 can then present the amount
due to user 105, request payment information (e.g., a credit card
number), identify payment information based on data previously
stored in association with an account, request a user's agreement
to pay a specific amount, complete the processing of a payment
and/or indicate to ticket requestor 230 whether a required payment
was completed.
[0053] Ticket requestor 230 then determines whether a request is to
be approved or denied. The request can be denied due to, e.g., to
receiving insufficient information, the requesting user not being
authorized to make the request, the requesting user failing one or
more CAPTCHA tests and/or not receiving required payments. Ticket
requestor 230 can then, e.g., invite the user to revise and
resubmit the request, identify alternative options (e.g.,
suggesting that a user who submitted a pre-onsale ticket request
make the request during the onsale period), block the user from use
of some or all of ticket management system 150 or places a ticket
(e.g., subsequently) request received by the user low or towards a
back of a queue (e.g., to avoid encouraging robots to beat the
system based on an indication of a registration denial).
[0054] If ticket requestor 230 approves a request to register for
an event, ticket requestor 230 can invite and/or allow user 105 to
request tickets before the tickets are onsale. The user can be
required to submit further information (e.g., seating preferences
or restrictions) or perform other actions to indicate that he is a
human.
[0055] If a pre-onsale or onsale ticket request is approved, a
queue engine 245 can add the requesting user to a queue associated
with the event. The queue is structured to prioritize some users
over others. This can be accomplished by ranking users or by
assigning users to various prioritization groups. Higher
prioritizations can be given to users who, e.g., requested tickets
during a pre-onsale period due to registering for the event, had
stronger estimations of being a human (due to participation in
activities or providing of information), had stronger estimations
of not being a threat, and/or promoted a website or event (e.g., by
referencing it using a social-network site.
[0056] When the onsale period commences, a ticket browsers 250
iteratively searches for tickets. For example, ticket browser 250
first searches for tickets for a first user and can identify a best
match based on restrictions or preferences of the user. Ticket
requestor 230 can present the search results to the user 105 and
receive any indication that he wishes to purchase the tickets. In
some embodiments, all users are simultaneously presented with the
results and are given the opportunity to modify their ticket
request (e.g., to change preferences, restrictions or a number of
requested tickets). In some instances, the modification opportunity
is only presented when no available tickets were found to match the
request.
[0057] The ticket browser can place the tickets from search results
on hold for a period of time, while a user can indicate that he
wishes to purchase them and/or while the purchasing transaction is
completed. If the user positively responds to the results (by
agreeing to purchase the tickets or by paying for the tickets), a
ticket issuer 255 assigns the tickets to the user, such that the
user can access and redeem the tickets and the tickets can no
longer be assigned to other users. Otherwise, ticket browser 250
makes the tickets available to other users. Either way, ticket
browser 250 then proceeds to search for tickets for a next user. In
embodiments in which queues are ranked, successive users can be
identified by progressively going through the ranks In embodiments
in which queues include prioritization groups, a user within a
group can be pseudo-randomly selected.
[0058] While this process is described as a singularly iterative
process, some searches can be conducted in parallel. For example,
ticket browser 250 can proceed to a next search while tickets from
a prior search are on hold to allow the first user to purchase
them. As another example, multiple queues can exist for a single
event--the queues differing with regard to requested ticket type
(e.g., seating zones). Concurrent searches can then be performed,
each search utilizing a different queue to identify ticket
requests.
[0059] FIG. 3 illustrates a flowchart of an embodiment of a process
300 for presenting an offer for tickets to a user 105. Process 300
begins at block 305, where offer engine 205 accesses information
provided by an event provider 115 (e.g., via an event-provider
device 120) pertaining to an offer. The offer information can
identify an event for which tickets are available to a population
(such as the public or a subset of the public), a date or dates of
the event, and/or a location or locations of the event. The
information can further indicate a maximum number of tickets that
can be distributed, a price that must be paid before a user 105 can
receive a ticket, various types of tickets (e.g., in various
seating zones), and/or a time period during which the offer is to
be available.
[0060] Ticket offerer 210 allocates tickets at block 310. The
allocated tickets or an identification of the allocation can be
stored in ticket database 190. The ticket allocation can include
allocating a number of similar or identical tickets and/or
allocating a ticket for each of a set of seats. For example, for a
sporting event to be hosted in a stadium, a ticket can be allocated
for each seat in the stadium available to the public. The seats can
be directly or indirectly identified based on information provided
by event provider 115 (e.g., as an event provider can identify a
venue, such that ticket offerer 210 can automatically identify
available seats). As another example, for an open-seating concert
event, ticket offerer 210 can identify a number of tickets to issue
based on information provided by event provider 115 and can
allocate that number of similar (e.g., differing only with respect
to a ticket identification number) or identical tickets.
[0061] The ticket allocation can include identifying distinct types
of tickets. For example, a first set of tickets for a show can be
designated as premier (due to the proximity of the respective seats
to a stage). The ticket allocation can include identifying one or
more ticket prices (e.g., based on information provided by an event
provider), which can be uniform or dependent on ticket types.
[0062] The ticket allocation can include identifying an
identification code for each ticket. The code can be unique across
all tickets for a given event or for all events. The code can be
generated based on, e.g., a respective event provider, offer,
venue, event date, ticket type, ticket number, seat number and/or a
pseudorandom element. For example, a first segment can be
indicative of an offer and a second segment can be indicative of a
seat number. The segments can then be concatenated.
[0063] Ticket offerer 210 uses the offer information to generate an
offer at block 315. The offer is stored in offer database 160 at
block 320. The stored offer can include some or all of the offer
information and/or identification of the associated event provider
115. The offer can be stored in a standard format.
[0064] Ticket offerer 210 presents users an invitation to register
for the offer's event at block 325. The invitation can be presented
on front page (e.g., a home page on a website or a front page of an
app) or a page dedicated to a user account, the event, a performer
at the event, a venue of the event, etc. The invitation can be
presented on a page returning results responsive to a user's
search. The invitation can indicate advantages of registering for
the event and/or requirements for completing the registration.
[0065] Ticket requestor 230 accepts registrations for the event
from users at block 330. In order for the registration to be
accepted, users may need to enter specific (e.g., user-identifying)
information, be estimated to be a human (based on completion of one
or more activities, providing objective and factual information or
responding to questions that a robot would have difficulty
responding to), and/or not be estimated to be suspicious or a
threat. The user can be estimated to be a human (as compared to a
robot) based on performance of one or more of the following
operations: [0066] connect to another account or an account hosted
by another system (e.g., a social network site account which
enables data to be shared between the ticketing system and the
social networking site); [0067] provide or update a user phone
address/number; [0068] validate an email address; [0069] provide or
select a method of payment (e.g., gift card, credit card, debit
card, etc.); [0070] sign into an account associated with another
system or merchant; [0071] enter information, such as a score,
obtained from another site; [0072] answer a question about the user
or other topic (e.g., are you a robot? Will the sun rise tomorrow?
What color is mustard?, etc.); [0073] play a game (where the number
of user game interactions, frequency of user interactions, and/or
user game score can be used in determining whether the user is a
robot); [0074] chat with a human agent or an automated program
configured to engage in chat; [0075] share the event with other
users (where the user posts information regarding the event or a
link to event information to a social networking page associated
with the user or the user emails information or a link to
information to other users).
[0076] In some instances, ticket requestor 230 generates a
registration score, which can depend upon the amount of information
provided by the user, the type of information provided by the user,
the number of CAPTCHA tests completed, the accuracy of responses to
CAPTCHA tests, a degree of suspicious activity, an amount and/or
type of event-promotion acts performed by the user (e.g., sharing a
link for the event using a social-network site), etc. A score above
a threshold can indicate that registration is complete and/or the
score can be used for prioritization of one or more ticket requests
made by the user. The score can also be modified in time, such that
a user can improve his score after he is registered by, e.g.,
providing additional information or completing additional acts.
[0077] Ticket offerer 210 presents the offer to one or more users
105 during a pre-onsale period at block 335. The offer can be
presented electronically on a webpage or an app page (e.g., a front
webpage or app page, a page dedicated to an event, a page dedicated
to an artist, a page dedicated to a performer, and/or a page
dedicated to a user's account). The users to whom the offer is
presented can depend upon whether a user is registered for an
event, search queries of the user (e.g., searching for a comedic
event in a particular city within a defined date range), user
preferences, users accessing an account within a time period,
and/or restrictions of the offer specifying who the offer is to be
made available to. In one instance, the pre-onsale offer
information is only presented to registered users. In one instance,
the information can also be presented to unregistered users and can
be (in some instances) accompanied by an invitation to register for
the event.
[0078] Ticket offerer 210 subsequently presents the offer
information during an onsale period at block 340. The offer can be
presented electronically on a webpage or an app page (e.g., a front
webpage or app page, a page dedicated to an event, a page dedicated
to an artist, a page dedicated to a performer, and/or a page
dedicated to a user's account). The users to whom the offer is
presented can depend upon search queries of the user, user
preferences, users accessing an account within a time period,
and/or restrictions of the offer specifying who the offer is to be
made available to. The users to whom the offer is presented can
include non-registered users.
[0079] Ticket requestor 230 accepts and processes ticket requests
at block 345. The requests can be responsive to the offer
information presented at blocks 335 and/or 345. In order to submit
a request, a user 105 can need to interact with a ticket request
user interface (e.g., presenteded by ticket offerer 210), which can
include fields and controls enabling the user to specify (via text
fields, menu selections, or otherwise) some or all of the
following: the number of tickets the user wants, the seating
area(s) the user wants tickets for, specific seat(s) the user wants
tickets for (e.g., submitted via an interactive seating map); the
price level for the tickets (e.g., a specific price or a not to
exceed price); that the system should provide the best tickets from
the available inventory, etc. The user can optionally be required
to complete a robot detection test, such as a CAPTCHA test, where
the user needs to type into a field certain text presented to the
user (where the presented text can be visually distorted or
obscured in order to inhibit a robot from successfully entering in
the text). Acceptance of a request from a registered user can
require less provision of information as compared to that required
from non-registered users (e.g., requiring less or no identifying
information) and/or less or no completions of actions.
[0080] Ticket requestor 230 can assign a score to each request,
which can be based on, e.g., an amount of information provided by
the user, a type of information provided by the user, a number of
CAPTCHA tests completed, an accuracy of responses to CAPTCHA tests,
login or account-verification activities completed by the user, a
degree of suspicious activity, an amount and/or type of
event-promotion acts performed by the user (e.g., sharing a link
for the event using a social-network site), etc. For registered
users, the score can be equal to or based on (e.g., building from)
a registration score.
[0081] The requests can be accepted during both the pre-onsale
period and the onsale period and can be accepted as they are
received. In some instances, all requests are processed during the
onsale period. An order for which requests are processed can depend
on, e.g., where the requests are within a queue and/or a
pseudo-random selection element. Queue placement can depend on,
e.g., whether requesting users were registered, when the requests
were received, and/or scores of the requests.
[0082] FIG. 4 illustrates a flowchart of an embodiment of a process
400 for receiving pre-onsale ticket requests using a queue. Process
400 begins at block 405, where ticket offerer 210 provides access
to an event interface (e.g., via a webpage or page of an app). The
event interface can be a part of a performer interface. For
example, a webpage can be dedicated to concerts performed by A.
Singer, and the webpage can further identify upcoming concerts for
A. Singer. The event interface can indicate a time (which can also
include a date) at which tickets for the event will be onsale
and/or a countdown timer.
[0083] User validator 220 determines whether a user account is
identified at block 410. An account can be identified based on,
e.g., a user entering a username and password for an existing
account or based on a prior log-in to an account or cookie
identification of an account. If no account is identified, a user
can be presented (e.g., immediately or upon receiving an attempt to
request tickets or register for an event) with an invitation to
create an account. The invitation can indicate that event
registration requires that a requesting user be logged into an
account. A user can then interact with account generator 215 to
generate the account. User validator 220 determines whether the
user created a new account at block 415. If he did not, an
indication is presented that the tickets are not yet on sale at
block 420.
[0084] If an existing or new account is identified for the user,
process 400 continues to block 425 where ticket offerer 210
presents an option to register for a particular event (e.g., along
with advantages of and/or requirements for registering). The
particular event can be chosen based on, e.g., event preferences of
the user, events for which the user previously purchased tickets,
events with upcoming dates and in a locale of the user, events for
which offers were recently added to offer database 160 and/or
search queries entered by the user.
[0085] At block 430, ticket requestor 230 determines whether a user
indicated that he wished to register for the event. If so, ticket
requestor 230 requests that the user complete a verification step,
which can include providing information and/or completing tasks. In
some instances, multiple verification steps can be presented and
registration can require of a fixed number or all of the steps. The
verification step can be one that can be used to estimate that a
user is a human and not a robot. Ticket requestor 230 determines
whether the step has been completed at block 440. This
determination can involve determining that the user completed a
sufficient number of steps and/or that the completed step(s) were
completed with sufficient accuracy. If so, the user is registered
for the event and process 400 continues to block 445 where ticket
offerer 210 provides, prior to tickets for the event being onsale,
to the user, an interface for requesting tickets. The interface can
request price preferences or restrictions, seating preferences or
restrictions, event-date preferences or restrictions, and/or
payment information or agreements.
[0086] Ticket requestor 230 determines whether a user submits a
valid pre-onsale ticket request at block 450. The validity can
depend on, e.g., having entered required information (e.g., seat
preferences). If so, queue engine 245 places the request in a queue
for the event at block 455. The queue can be a centralized queue
for the event or can be one of multiple queues for the event, the
queue being selected based on a user's pricing preferences or
restrictions and/or a user's seating preferences or
restrictions.
[0087] FIG. 5 illustrates a flowchart of an embodiment of a process
500 for receiving onsale ticket requests using a queue. Process 500
begins at block 505, where ticket offerer 210 provides users with
access to an interface for requesting tickets for an event (e.g.,
via a webpage or page of an app) during an onsale time period. The
interface can request desired-ticket information from the user,
such as seat preferences or restrictions and/or price preferences
or restrictions.
[0088] Ticket requestor 230 determines whether a user submits a
valid onsale ticket request at block 510. If so, ticket requestor
230 requests that the user complete a verification step, which may
include a request to provide information and/or complete tasks at
block 515. The requested information and/or presented activities
can be simpler than those requested and/or presented at block 435
of process 400. For example, block 435 can require (while block 515
need not require) that the user validate a phone number, validate a
payment method, validate a billing address, play a game, link with
a user account on another system, participate in a chat, like the
event, and/or share the event.
[0089] Ticket requestor 230 determines whether the verification
step was completed at block 520. This determination can involve
determining that the user completed a sufficient number of
verification steps and/or that the user completed the verification
step(s) with sufficient accuracy. The required number and/or
accuracy can be less than that required at block 440. The queue can
be a centralized queue for the event or can be one of multiple
queues for the event, the queue being selected based on a user's
pricing preferences or restrictions and/or a user's seating
preferences or restrictions.
[0090] Notably, process 500 occurs when tickets are onsale. Thus,
unregistered users requesting tickets during this period are likely
to waste onsale time due to the time required to complete process
500 and/or any delay between the start of the onsale period and the
start of process 500. Meanwhile, registered users' completion of
process 400 can enable them to provide necessary ticket-request
information and to complete actions and/or provide information
indicative of them being humans (as opposed to robots) before the
onsale period ever began. Further, ticket requests from registered
users can be preferentially placed in the queue, providing these
users with even further advantage in their attempts to obtain
desired tickets.
[0091] FIG. 6 illustrates a flowchart of an embodiment of a process
600 for assigning tickets to users using a queue. Process 600
begins at block 605, where queue engine 245 accesses a queue for an
event from queue database 180 and prioritizes requests in the
queue. The prioritization can depend on, e.g. an amount of (e.g.,
identifying) information provided by the user, a type of
information provided by the user, a number of CAPTCHA tests
completed, an accuracy of responses to CAPTCHA tests, a degree of
suspicious activity, an amount and/or type of event-promotion acts
performed by the user (e.g., sharing a link for the event using a
social-network site), whether the user registered for the event, a
request score and/or a registration score. The prioritization can
include ranking one or more requests and/or assigning one or more
requests to a prioritization group.
[0092] Queue engine 245 identifies a top-priority request at block
610. The request can be identified by selecting a request with a
prioritized rank (e.g., being top in an order) and/or by
pseudo-randomly selecting a request within a prioritized group.
Once that request is processed, the request can be removed from the
queue such that other requests progress in the prioritization.
[0093] Ticket browser 250 searches ticket database 190 for
available allocated tickets that conform to a request's
restrictions at block 615. The ticket browser determines whether
any such tickets are found at block 620. Searching for tickets at
block 615 can include identifying a price for each of one, more or
all tickets in ticket database for a given event. The price can
include a fixed price (e.g., identified by an event provider) or
one determined a pricing engine in ticket management system 150
(e.g., based on ticket sales to similar events, a current number of
event fans or users registered for the event, and/or a current
number of received ticket requests). The pricing engine can
determine the price(s) shortly before the onsale period begins or
repeatedly throughout at least part of the onsale period.
[0094] If no tickets conforming to the restrictions are found,
ticket requestor 230 presents the user with the option to modify
his ticket request (e.g., to change or eliminate restrictions such
as seating or pricing restrictions or to change a requested number
of tickets) and/or can present the users with offers from one or
more tickets outside the restrictions. If ticket requestor 230
determines that the user completed a request modification, blocks
615 and 620 are repeated.
[0095] If tickets conforming to a request's restriction are found,
ticket requestor 230 offers one, some or all of the identified
tickets to the user at block 635. In some instances, more than a
requested number of tickets are found. Ticket browser 250 can then
identify a subset of the tickets (e.g., the subset including the
number of requested tickets) predicted to be preferred by the user.
This prediction can be done by comparing seats and/or prices across
the tickets (e.g., preferring seats closer to the center and action
(e.g., to the field, stage, etc.) or preferring cheaper tickets)
and/or analyzing general or event-specific preferences of the user.
In some instances, more than the requested number of tickets are
presented to the user (e.g., all tickets identified in 615-620 or
several estimated-to-be-preferred options matching restrictions for
a user to choose between).
[0096] Presenting the identified tickets can include immediately
presenting a seat reservation page to a user via an app or website
or sending a link e.g., via email, SMS, MMS, a web page, or
otherwise) to a user (e.g., who previously registered for the
event) that, when activated, automatically navigates the user
(e.g., via a browser or phone app) to the seat reservation page.
The seat reservation page can indicate which specific seats (or
which seating section) correspond to tickets identified in response
to the user's request user (e.g., based on the information the user
provided via the seat selection user interface and the available
seat tickets), and the user can be provided with a specified amount
of time to complete the ticket purchase.
[0097] The identified tickets can be presented using a seat
reservation user interface, which can, e.g., identify the event
(e.g., the name of the performer, the venue name, the event date
and time, etc.), the identified ticket(s) (e.g., including seat
number and/or seat location), a ticket type (e.g., full price,
discounted price, fan club price, etc.), a number of identified
tickets, a per-ticket price, and a total amount for purchasing some
or all of the identified tickets. A seating chart can be displayed
as well. A timer can be provided indicating how long the user has
to activate a specified control (e.g., a continue control), wherein
if the user does not activate the control within the time limit,
the identified tickets can be released so that they can be offered
to and purchased by other users. If the user does not want the
offered tickets, the user can also activate a corresponding control
and the tickets will likewise be released. If the user releases the
tickets the user can resubmit the request for tickets, optionally
without having to reenter the ticket specification provided during
the registration, prior to the onsale. Optionally, if the user
registered, the resubmitted request can still be provided priority
as compared to at least some other users submitted the request at
about the same time (or even prior to the user's resubmitted
request) that did not register, wherein the priority can be based
at least in part on the score indicating how likely the user is a
human.
[0098] The user can then interact with ticket requestor 230 to
select one or more offered tickets. The selection can include,
e.g., selecting a ticket or group of tickets from amongst multiple
options and/or agreeing to purchase an offered ticket or group of
tickets. If ticket requestor 230 determines, at block 640, that the
selection was completed, ticket issuer 255 places the selected
ticket(s) on hold (e.g., from changing a status of the tickets in
ticket database 190 from "available" or "allocated" to "hold").
Specifically, the tickets can be made unavailable for purchase by
other users for a period of time (e.g., a predefined period of
time). During that time, ticket issuer 255 can wait for the user to
submit valid payment information to complete the purchase of the
tickets. If ticket requestor 230 indicates that valid payment
information has been received and/or that the purchase has been
completed during the holding period, ticket issuer 255 assigns the
tickets to the user in ticket database 190, such that the user can
access the tickets and has the right to redeem the tickets.
[0099] Due to the iterative nature of process 600, at least some
users will experience a delay before they are offered available
tickets. These users can be presented with an estimate of a
duration until or a time when they will be offered tickets, or they
can be informed as to how many users will likely be offered tickets
before them. Such an estimation can be made based on analyzing a
user's position in a queue and an average or median time to
complete process 600 for a single user.
[0100] It will be appreciated that, in some instances, a single
event can have multiple onsale periods. Each period can be open to
users with a particular characteristic (e.g., a first one open to
users having a credit card of a particular brand, a second one open
to users in a particular fan club, and a third one open to the
general public). A user can be able to see the various onsale
periods while viewing, e.g., a dedicated event page. The time until
each onsale period begins and/or ends can also be presented (e.g.,
via a countdown timer).
[0101] FIG. 7 illustrates a flowchart of an embodiment of a process
700 for prioritizing requests for tickets for an event. Process 700
begins at block 705, where user validator 220 provides a user with
an option to log into an account. If the user indicates that he
does not have an account, user validator 220 can present an option
to interact with account generator 215 to generate an account. In
some instances, account login is required to register for events,
perform activities, request tickets and/or purchase tickets.
[0102] Ticket requestor 230 presents the user with one or more
activity options a block 710. The options can include an option to:
complete a CAPTCHA test, identify another online account (e.g., on
a social-network or auction site) and/or promote an event or site
(e.g., by linking to, referencing or liking the event or site on a
social-network site or by sending a text, email or intra-site
message about the event or site to others). Ticket requestor 230
presents the user with the opportunity to enter information at
block 715. The information can include identifying information
(e.g., a phone number, address, age and/or email address), payment
information (e.g. a credit-card number of login information to an
online payment site), online-involvement information (e.g.,
identifying which social-network sites at which the user is a
member), device information (e.g., identifying a type of device
owned or used by the user), etc. The activity and information
options can be chosen in an effort to ensure that the user is a
human, to collect useful data (to speed up later ticket-purchasing
efforts, to identify general user demographics, to identify
demographics of users requesting tickets to a specific event, to
identify other websites frequented by users), to promote a site
associated with ticket management system 150 and/or to promote an
event.
[0103] Ticket requestor 230 searches for any threat indicators at
block 720. The threat indicators can be identified based on account
characteristics, suspicious information entered by the user,
inabilities to complete actions successfully despite efforts, or
characteristics of a present access to a website or use of an app
(e.g., time on a site, time spent per page on the site). For
example, threat indicators can include a very large previous number
of ticket requests, entry of an invalid credit-card number,
inaccurate responses to CAPTCHA tests and/or unusually fast
navigation through pages on a website.
[0104] Ticket requestor 230 identifies a request for tickets from
the user at block 725. The request can be one made before, during
or after one or more of blocks 710-720. Queue engine 245 generates
a score and assigns the score to the request at block 730. The
score can be based on one or more of a number of activities
completed, an accuracy of the completed activities, types of
activities completed, an amount of information provided, types of
information provided, a number of threat indicators, a severity of
any identified threat indicators and/or whether a user registered
for the event. Generally, points can be added to the score for
completed activities, provided information and having registered
for the event, and points can be subtracted from the score for
threat indicators.
[0105] The score can also or alternatively depend on a user's
transaction frequency and/or amount (e.g., based on how often the
user purchases ticket inventory, the amount of inventory the user
has purchased in the past, the total dollar value of inventory
purchased by the user, and/or based on how recently the user
purchased inventory, etc.); an amount of tickets requested (e.g.,
giving preference to low numbers, odd numbers, even numbers or "1",
where the preference can depend on currently available tickets),
past resale activity by user (e.g., how recently and/or how often
the user has resold inventory previously purchased, such as that
originally sold, then resold and tracked via a ticket system); seat
location preferences; whether the user has indicated that the user
is willing to accept alternate inventory (e.g., tickets for other
event performances); how to increase or maximize total inventory
sales (e.g., how to reduce the number of empty seats for an event
using seat packing);whether the user has a membership to a loyalty
program; and/or whether the user has a preferred membership (e.g.,
which can be obtained by paying a fee or by being a subscriber of a
selected other service, such as of a certain credit or charge card
service).
[0106] The score can also or alternatively depend on a location
associated with an IP address, a distance between an event and a
location associated with an IP address, speed of site actions
(e.g., a speed at which a user navigates through site pages or
enters information), a request frequency (e.g., a number of ticket
requests received from a user in a given time), a request
concurrence (e.g., whether multiple requests are received from one
user simultaneously or nearly simultaneously), an receipt of an
unexpected system-capability response (e.g., an indication of
Javascript being disabled), a user congregation (e.g., a number of
users originating from one IP address), suspicious session
activity, any fraud in purchase history (e.g., to leverage a user's
purchase history and fraud status to filter bad actors), whether a
user or user characteristic corresponds to a known bad actors
(e.g., from an internal or community list of, e.g., robots or
spammers), and/or whether a request was part of a multiplicative
request (e.g., identifying, using information provided in request
and/or verification step(s), instances where multiple requests are
associated with a same social login, credit card, billing address,
phone number, Amazon Prime account, etc. In some instances, the
score depends on a factor disclosed in U.S. Application No.
61/788,173, which is hereby incorporated by reference in its
entirety for all purposes.
[0107] The table below provides a listing of example techniques for
that can be used (alone or in combination) to generate the score.
The score can be determined, e.g., based on how many operations the
user performed and/or how well the user performed the operations
(e.g., did a user perform a given operation successfully). The
score can optionally provide more gradations of performance than a
simple pass/fail indication (e.g., at least three possible scores,
such as "A", "B", "C", or likely a robot, likely not a robot,
indeterminate as to whether the user is a robot or not). The score
can be calculated in substantially real time and provide the user
an indication as to the score. The indication can be in the form of
a numerical score (e.g., 1 to 10, with 10 being the highest score
indicating that the user performed a certain number of requested
operation and/or indicating how likely it is the user is a human
based on the number of operations performed by the user and the
performance of the user on one or more of the operations), a letter
grade (e.g., F to A), a bar graph, a color (e.g., green is a
pass--a human, red is fail--a robot) or the score can otherwise be
presented.
TABLE-US-00001 Validate Email Display module to validate email
address Validation of user email address Check email address
against previous history and fraud information Validate Phone
Display module to validate phone number Validation of phone number
Check phone number against VOIP list Check phone number against
previous history and fraud information Validate Payment Method
Display module to validate payment method (Credit Card) Validate
Payment method against billing address Validate payment method
against possible fraud (prepaid cards etc., history, etc.) Validate
Billing Address Display module to validate Billing address Check
billing address against Payment method Check billing address
against previous history, fraud, etc. Check billing address against
distance from the venue location Play Game Integrate 3rd party game
provider Collect metrics about game play: frequency, interaction,
etc. Link with Facebook Display module to link Facebook account
Validate user's Facebook account attributes Check Facebook account
against previous history and fraud information Link with Twitter
Display module to link twitter account Validate user's twitter
account attributes Check twitter account against previous history
and fraud information Link with Google Display module to link
Google account Validate user's Google account attributes Check
Google account against previous history and fraud information
Integrate with Klout Display module to register/login to Klout
Validate user's Klout score Check Klout account against history and
fraud information Validate User Interaction Validate user has
participated in chat Validate user has liked the event Validate
user has shared the event Display Validation Criteria Show
validation modules Show the user's "completeness" Randomize Items
that are collected from the user Technical Attributes Check user's
status on the frequency grey list Check user's previous purchase
history Check how many times the user is currently queued Check
IP's location against billing address and venue location *
Integrate with 3rd party device finger printing service * Integrate
with 3rd party fraud service CAPTCHA Check how long user takes to
solve CAPTCHA Verify CAPTCHA responses Randomize CAPTCHA prompt
location/time * Integrate 3rd party Captcha Link with Amazon Prime
Display module to link with Amazon prime. Verify account
information with Amazon prime Check Amazon prime account for
previous history and fraud Validate User Account Display module to
require login earlier in check out process Check user account
against history and fraud. Ranking Algorithm Algorithm to rank
users into multiple (e.g., 3) buckets. Algorithm to order users
within each bucket. Ranking algorithm based on event demand.
Inventory Request Assign inventory according to rank determined by
the algorithm Throttle users determined to be "high risk"
[0108] In addition, in generating the score, the system can ask
that the user provide an account identifier and/or login
information. The system can use the account identifier and/or login
information to locate and access the user's purchase history (if
one exists). The user's score can then be based on the number of
purchases the user has made (overall and/or over a specified period
of time), the total dollar value of the purchases (overall and/or
over a specified period of time), and/or the types of items
purchased (e.g., the types of events of which tickets have been
purchased.
[0109] Thus, for example, if the user has continuously/repeatedly
purchased 1 or 2 tickets per concerts for rock concerts over the
previous year, indicative of a normal fan's ticket purchasing
behavior, the user can receive a beneficial adjustment to the
user's score. If the user not made any ticket purchases, the user
can receive a negative adjustment to the user's score. If the user
has only purchased tickets to events that tend to sell out, and,
for concert tickets purchased by the user, there is little
consistency to the musical style of the acts for which the user
purchased tickets (e.g., the user has purchased large numbers of
tickets for sold out concerts, including rock, rap, dance,
classical, and country music) and has not purchased any (or
relatively few) tickets for events that did not sell-out, the
system can infer that the user is a robot being operated by a
scalper who is only interested in purchasing tickets for sold out
events so that the tickets can be resold for much higher than the
face value of the tickets.
[0110] Queue engine 245 prioritizes the request based on the score
in 735. In one instance, the request is assigned to a group in a
queue based on the score (e.g., by comparing the score to one or
more thresholds). In one instance, the request is ranked amongst
other requests based on the score (e.g., ranking requests with high
scores over requests with low scores). In one instance, requests
associated with scores below a threshold are not even added to the
queue. The prioritization can be performed with respect to other
similar requests (e.g., for a same event, with similar
ticket-request restrictions, etc.). In some instances, all pending
pre-onsale requests are prioritized over all pending onsale
requests within a given queue. The prioritization can be dynamic to
accommodate new user data (e.g., completed activity or provided
information) which can influence a request's score and/or to
accommodate new requests.
[0111] Ticket browser 250 serves requests in a queue base on the
prioritization at block 740. In one instance, requests are ranked
at block 735 and ticket browser 250 searches for tickets for
requests with the lowest rank in the queue. In one instance,
requests are assigned to prioritization groups at block 735, and
ticket browser 250 searches for tickets for requests in a
high-prioritization group before searching for tickets for request
in a lower prioritization group. A request can be selected from
amongst all outstanding requests in a group based on, e.g., a
pseudo-random selection.
[0112] In some instances, requests with low scores (e.g., below a
threshold) and/or of low prioritization are processed differently
as compared to other requests. Specifically, a use-inhibition
technique can be (e.g., automatically) employed during request
processing. In some instances, a score or prioritization is
compared to one or more thresholds (which may be fixed or depend on
one or more variables, such as an event provider, system load,
ticket demand, etc.), which can determine whether a technique is to
be used, which technique is to be used, and/or a technique severity
(e.g., delay duration). These low scores and/or low prioritizations
can suggest that users making the requests are robots. It may be
advantageous to inhibit the suspected robot users' access to system
150 to better provide human users with the opportunity to purchase
desirable tickets.
[0113] The use-inhibition technique can include, e.g., presenting
the user with a message indicating that system 150 is unavailable,
that tickets for an event of interest are sold out, that specific
tickets (e.g., within a desirable price range or seating area) are
sold out, that it is estimated that the user is a robot and/or that
a verification-step completion was unsatisfactory. The message may
or may not be accurate. For example, even if tickets are available
to an event, a message presented to a suspected-robot user can
state that they are not. The use-inhibition technique can also or
alternatively include delaying processing of a ticket request. This
delay can be represented as being due to a volume of requests being
processed but, in actuality, can be actively implemented in order
to improve the likelihood that human users will be able to request
and purchase tickets during this time period and/or to encourage
robot users to abandon ticket-purchasing efforts. The
use-inhibition technique can include inflating a ticket price
and/or blocking the user from accessing part or all of system 150
(e.g., by locking an account) indefinitely or for a period of time.
The use-inhibition technique can include a consequence disclosed in
U.S. Application No. 61/788,173, which is hereby incorporated by
reference in its entirety for all purposes.
[0114] In some instances, an identity of and/or severity of
use-inhibition techniques can vary. For example, one technique may
be used to respond to a first user having a low score and another
for a second user having a low score. The variation may, or may
not, depend on the score or prioritization (e.g., using harsher
techniques in response to low scores). In some instances, the
variation is random or includes a random element. This may make it
more difficult for robot users to understand that a use-inhibition
technique is being actively used or more difficult for them to
avoid the consequence.
[0115] In some instances, the prioritization at block 735 and/or
any use of a use-inhibition technique depends on a user's score.
The user score can be generated in a manner similar to a generation
of a request score, but the user score can be influenced by factors
surrounding multiple requests. For example, if a user successfully
completes verification tasks while submitting requests for tickets
to three events and subsequently inaccurately completes a
verification task while requesting tickets to a fourth event, the
user score may reduce a penalty for the inaccuracy by considering
the successful completions. The user score can be based on a
weighted or unweighted averaging of factors, such as
verification-step completions.
[0116] Referring next to FIG. 8, an exemplary environment with
which embodiments can be implemented is shown with a computer
system 800 that can be used by a designer 804 to design, for
example, electronic designs. The computer system 800 can include a
computer 802, keyboard 822, a network router 812, a printer 808,
and a monitor 806. The monitor 806, processor 802 and keyboard 822
are part of a computer system 826, which can be a laptop computer,
desktop computer, handheld computer, mainframe computer, etc.
Monitor 806 can be a CRT, flat screen, etc.
[0117] A designer 804 can input commands into computer 802 using
various input devices, such as a mouse, keyboard 822, track ball,
touch screen, etc. If the computer system 800 comprises a
mainframe, a designer 804 can access computer 802 using, for
example, a terminal or terminal interface. Additionally, computer
system 826 can be connected to a printer 808 and a server 810 using
a network router 812, which can connect to the Internet 818 or a
WAN.
[0118] Server 810 can, for example, be used to store additional
software programs and data. In one embodiment, software
implementing the systems and methods described herein can be stored
on a storage medium in server 810. Thus, the software can be run
from the storage medium in server 810. In another embodiment,
software implementing the systems and methods described herein can
be stored on a storage medium in computer 802. Thus, the software
can be run from the storage medium in computer system 826.
Therefore, in this embodiment, the software can be used whether or
not computer 802 is connected to network router 812. Printer 808
can be connected directly to computer 802, in which case, computer
system 826 can print whether or not it is connected to network
router 812.
[0119] With reference to FIG. 9, an embodiment of a special-purpose
computer system 900 is shown. Ticket management system 150 and/or
any components thereof are examples of a special-purpose computer
system 900. Thus, for example, one or more special-purpose computer
systems 900 can be used to provide the function of ticket
management system 150. The above methods can be implemented by
computer-program products that direct a computer system to perform
the actions of the above-described methods and components. Each
such computer-program product can comprise sets of instructions
(codes) embodied on a computer-readable medium that directs the
processor of a computer system to perform corresponding actions.
The instructions can be configured to run in sequential order, or
in parallel (such as under different processing threads), or in a
combination thereof. After loading the computer-program products on
a general purpose computer system 826, it is transformed into the
special-purpose computer system 900.
[0120] Special-purpose computer system 900 comprises a computer
802, a monitor 806 coupled to computer 802, one or more additional
user output devices 930 (optional) coupled to computer 802, one or
more user input devices 940 (e.g., keyboard, mouse, track ball,
touch screen) coupled to computer 802, an optional communications
interface 950 coupled to computer 802, a computer-program product
905 stored in a tangible computer-readable memory in computer 802.
Computer-program product 905 directs system 900 to perform the
above-described methods. Computer 802 can include one or more
processors 960 that communicate with a number of peripheral devices
via a bus subsystem 990. These peripheral devices can include user
output device(s) 930, user input device(s) 940, communications
interface 950, and a storage subsystem, such as random access
memory (RAM) 970 and non-volatile storage drive 980 (e.g., disk
drive, optical drive, solid state drive), which are forms of
tangible computer-readable memory.
[0121] Computer-program product 905 can be stored in non-volatile
storage drive 990 or another computer-readable medium accessible to
computer 802 and loaded into memory 970. Each processor 960 can
comprise a microprocessor, such as a microprocessor from Intel.RTM.
or Advanced Micro Devices, Inc.RTM., or the like. To support
computer-program product 905, the computer 802 runs an operating
system that handles the communications of product 905 with the
above-noted components, as well as the communications between the
above-noted components in support of the computer-program product
905. Exemplary operating systems include Windows.RTM. or the like
from Microsoft Corporation, Solaris.RTM. from Sun Microsystems,
LINUX, UNIX, and the like.
[0122] User input devices 940 include all possible types of devices
and mechanisms to input information to computer system 802. These
can include a keyboard, a keypad, a mouse, a scanner, a digital
drawing pad, a touch screen incorporated into the display, audio
input devices such as voice recognition systems, microphones, and
other types of input devices. In various embodiments, user input
devices 940 are typically embodied as a computer mouse, a
trackball, a track pad, a joystick, wireless remote, a drawing
tablet, a voice command system. User input devices 940 typically
allow a user to select objects, icons, text and the like that
appear on the monitor 806 via a command such as a click of a button
or the like. User output devices 930 include all possible types of
devices and mechanisms to output information from computer 802.
[0123] These can include a display (e.g., monitor 806), printers,
non-visual displays such as audio output devices, etc.
[0124] Communications interface 950 provides an interface to other
communication networks and devices and can serve as an interface to
receive data from and transmit data to other systems, WANs and/or
the Internet 818. Embodiments of communications interface 950
typically include an Ethernet card, a modem (telephone, satellite,
cable, ISDN), a (asynchronous) digital subscriber line (DSL) unit,
a FireWire.RTM. interface, a USB.RTM. interface, a wireless network
adapter, and the like. For example, communications interface 950
can be coupled to a computer network, to a FireWire.RTM. bus, or
the like. In other embodiments, communications interface 950 can be
physically integrated on the motherboard of computer 802, and/or
can be a software program, or the like.
[0125] RAM 970 and non-volatile storage drive 980 are examples of
tangible computer-readable media configured to store data such as
computer-program product embodiments of the present invention,
including executable computer code, human-readable code, or the
like. Other types of tangible computer-readable media include
floppy disks, removable hard disks, optical storage media such as
CD-ROMs, DVDs, bar codes, semiconductor memories such as flash
memories, read-only-memories (ROMs), battery-backed volatile
memories, networked storage devices, and the like. RAM 970 and
non-volatile storage drive 980 can be configured to store the basic
programming and data constructs that provide the functionality of
various embodiments of the present invention, as described
above.
[0126] Software instruction sets that provide the functionality of
the present invention can be stored in RAM 970 and non-volatile
storage drive 980. These instruction sets or code can be executed
by processor(s) 960. RAM 970 and non-volatile storage drive 980 can
also provide a repository to store data and data structures used in
accordance with the present invention. RAM 970 and non-volatile
storage drive 980 can include a number of memories including a main
random access memory (RAM) to store of instructions and data during
program execution and a read-only memory (ROM) in which fixed
instructions are stored. RAM 970 and non-volatile storage drive 980
can include a file storage subsystem providing persistent
(non-volatile) storage of program and/or data files. RAM 970 and
non-volatile storage drive 980 can also include removable storage
systems, such as removable flash memory.
[0127] Bus subsystem 990 provides a mechanism to allow the various
components and subsystems of computer 802 communicate with each
other as intended. Although bus subsystem 990 is shown
schematically as a single bus, alternative embodiments of the bus
subsystem can utilize multiple busses or communication paths within
computer 802.
[0128] Specific details are given in the above description to
provide a thorough understanding of the embodiments. However, it is
understood that the embodiments can be practiced without these
specific details. For example, circuits can be shown in block
diagrams in order not to obscure the embodiments in unnecessary
detail. In other instances, well-known circuits, processes,
algorithms, structures, and techniques can be shown without
unnecessary detail in order to avoid obscuring the embodiments.
[0129] Implementation of the techniques, blocks, steps and means
described above can be done in various ways. For example, these
techniques, blocks, steps and means can be implemented in hardware,
software, or a combination thereof. For a hardware implementation,
the processing units can be implemented within one or more
application specific integrated circuits (ASICs), digital signal
processors (DSPs), digital signal processing devices (DSPDs),
programmable logic devices (PLDs), field programmable gate arrays
(FPGAs), processors, controllers, micro-controllers,
microprocessors, other electronic units designed to perform the
functions described above, and/or a combination thereof.
[0130] Also, it is noted that the embodiments can be described as a
process which is depicted as a flowchart, a flow diagram, a data
flow diagram, a structure diagram, or a block diagram. Although a
flowchart can describe the operations as a sequential process, many
of the operations can be performed in parallel or concurrently. In
addition, the order of the operations can be re-arranged. A process
is terminated when its operations are completed, but could have
additional steps not included in the figure. A process can
correspond to a method, a function, a procedure, a subroutine, a
subprogram, etc. When a process corresponds to a function, its
termination corresponds to a return of the function to the calling
function or the main function.
[0131] Furthermore, embodiments can be implemented by hardware,
software, scripting languages, firmware, middleware, microcode,
hardware description languages, and/or any combination thereof.
When implemented in software, firmware, middleware, scripting
language, and/or microcode, the program code or code segments to
perform the necessary tasks can be stored in a machine readable
medium such as a storage medium. A code segment or
machine-executable instruction can represent a procedure, a
function, a subprogram, a program, a routine, a subroutine, a
module, a software package, a script, a class, or any combination
of instructions, data structures, and/or program statements. A code
segment can be coupled to another code segment or a hardware
circuit by passing and/or receiving information, data, arguments,
parameters, and/or memory contents. Information, arguments,
parameters, data, etc. can be passed, forwarded, or transmitted via
any suitable means including memory sharing, message passing,
ticket passing, network transmission, etc.
[0132] For a firmware and/or software implementation, the
methodologies can be implemented with modules (e.g., procedures,
functions, and so on) that perform the functions described herein.
Any machine-readable medium tangibly embodying instructions can be
used in implementing the methodologies described herein. For
example, software codes can be stored in a memory. Memory can be
implemented within the processor or external to the processor. As
used herein the term "memory" refers to any type of long term,
short term, volatile, nonvolatile, or other storage medium and is
not to be limited to any particular type of memory or number of
memories, or type of media upon which memory is stored.
[0133] Moreover, as disclosed herein, the term "storage medium" can
represent one or more memories for storing data, including read
only memory (ROM), random access memory (RAM), magnetic RAM, core
memory, magnetic disk storage mediums, optical storage mediums,
flash memory devices and/or other machine readable mediums for
storing information. The term "machine-readable medium" includes,
but is not limited to portable or fixed storage devices, optical
storage devices, wireless channels, and/or various other storage
mediums capable of storing that contain or carry instruction(s)
and/or data.
[0134] While the principles of the disclosure have been described
above in connection with specific apparatuses and methods, it is to
be clearly understood that this description is made only by way of
example and not as limitation on the scope of the disclosure.
* * * * *