CONTROLLED ACCESS QUEUE-BASED GATING BASED ON COOPERATIVE DETECTION OF VIABLE REGISTRATION
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.
Latest LIVE NATION ENTERTAINMENT, INC. Patents:
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.
BACKGROUNDThis 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.
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.
SUMMARYIn 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.
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.
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.
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.
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.
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.
The present disclosure is described in conjunction with the appended figures:
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 DESCRIPTIONThe 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.
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.
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.
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.
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.
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.
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.
Referring first to
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.).
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.
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.
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.
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).
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).
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.
Referring next to
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.
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.
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.
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®, LinkedIn®, Twitter®, Google+, etc.
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.
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).
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).
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.
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.
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.
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
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).
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).
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).
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
-
- 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);
- provide or update a user phone address/number;
- validate an email address;
- provide or select a method of payment (e.g., gift card, credit card, debit card, etc.);
- sign into an account associated with another system or merchant;
- enter information, such as a score, obtained from another site;
- 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.);
- 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);
- chat with a human agent or an automated program configured to engage in chat;
- 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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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).
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Referring next to
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.
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.
With reference to
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.
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® or Advanced Micro Devices, Inc®, 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® or the like from Microsoft Corporation, Solaris® from Sun Microsystems, LINUX, UNIX, and the like.
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.
These can include a display (e.g., monitor 806), printers, non-visual displays such as audio output devices, etc.
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® interface, a USB® interface, a wireless network adapter, and the like. For example, communications interface 950 can be coupled to a computer network, to a FireWire® 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Type: Application
Filed: Sep 17, 2014
Publication Date: Mar 17, 2016
Applicant: LIVE NATION ENTERTAINMENT, INC. (Beverly Hills, CA)
Inventors: Robert McEwen (Los Angeles, CA), Debbie Hsu (Los Angeles, CA)
Application Number: 14/489,241
