US20140379390A1 - Location-based presentations of ticket opportunities - Google Patents
Location-based presentations of ticket opportunities Download PDFInfo
- Publication number
- US20140379390A1 US20140379390A1 US14/295,033 US201414295033A US2014379390A1 US 20140379390 A1 US20140379390 A1 US 20140379390A1 US 201414295033 A US201414295033 A US 201414295033A US 2014379390 A1 US2014379390 A1 US 2014379390A1
- Authority
- US
- United States
- Prior art keywords
- ticket
- user
- offer
- event
- location
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W48/00—Access restriction; Network selection; Access point selection
- H04W48/02—Access restriction performed under specific conditions
- H04W48/04—Access restriction performed under specific conditions based on user or terminal location or mobility data, e.g. moving direction, speed
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0639—Item locations
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/02—Reservations, e.g. for tickets, services or events
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/02—Services making use of location information
- H04W4/023—Services making use of location information using mutual or relative location information between multiple location based services [LBS] targets or of distance thresholds
Definitions
- This disclosure relates in general to methods and systems for identifying users based on location-based predictions of actual or possible event attendance.
- the present disclosure provides a method and system for utilizing location-based information to estimate which tickets are likely to be unused and to provide channels through which such tickets can be reassigned to others capable of attending the appropriate event.
- locations of users e.g., ticket holders or users interested in an event
- locations of users are tracked (e.g., by tracking a user device or determining whether the user has redeemed other related tickets, such as a parking voucher). Based on the location, it is estimated whether and/or when the user could arrive at the event.
- an electronic offer can be presented to the ticket holder to surrender the ticket (which may result in a partial or full compensation). If the ticket is surrendered, the ticket can be electronically offered (for free or for a price) to another user selected based on the user's location and/or relationship to the initial ticket provider (e.g., based on those in a shared season-ticket group).
- a ticket management system for estimating user locations and presenting location-sensitive ticket offers.
- a ticket database identifies, for each ticket in a set of tickets for an event, an assignment indicating whether the ticket has been assigned to a user and an identifier of any user to whom the ticket is assigned.
- An offer database identifies a location and a time of the event.
- a locator accesses the offer database to identify the location of an event and the time of the event and estimates a current location of a user.
- An attendance predictor that predicts whether the user will be able to attend the event, the prediction being based on the location of the event, the time of the event and the estimated current location of the user.
- An offer engine determines, based on the prediction of whether the user will be able to attend the event, that an offer is to be presented to the user.
- the offer engine also generates the offer.
- the offer indicates that acceptance of the offer will cause an assignment of a ticket of the set of tickets for the event to change.
- the offer engine further presents the offer to the user and detects an acceptance of the offer from the user.
- a ticket assigner changes, in response to the detection of the acceptance, the assignment of the ticket in the ticket database.
- a method for estimating user locations and presenting location-sensitive ticket offers is provided.
- An offer database that identifies a location and a time of an event is accessed. Based on the access to the offer database, the location and time of the event are identified.
- a current location of a user of a ticket management system is estimated.
- a prediction is made as to whether the user will be able to attend the event, the prediction being based on the location of the event, the time of the event and the estimated current location of the user. Based on the prediction of whether the user will be able to attend the event, it is determined that an offer is to be presented to the user.
- the offer is offered, and an there is an indication that acceptance of the offer will cause an assignment of a ticket of a set of tickets for the event to change in a ticket database.
- the ticket database identifies, for each ticket in the set of tickets for the event.
- An assignment indicates whether the ticket has been assigned and an identifier of any user to whom the ticket is assigned.
- the offer is presented to the user.
- An acceptance of the offer from the user is detected.
- the assignment of the ticket is changed in the ticket database.
- a ticket management system for estimating user locations and presenting location-sensitive ticket offers.
- 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 perform a method disclosed herein.
- FIG. 1 depicts a block diagram of an embodiment of a ticket interaction system
- FIG. 2 depicts a block diagram of an embodiment of ticket management system
- FIG. 3 illustrates a flowchart of an embodiment of a process for assigning a ticket for an event to a user
- FIG. 4 illustrates a flowchart of an embodiment of a process for presenting a ticket holder with an offer to surrender a ticket
- FIG. 5 illustrates a flowchart of an embodiment of a process for predicting whether a ticket holder will attend an event
- FIG. 6 illustrates a flowchart of an embodiment of a process for predicting whether a ticket holder will attend an event
- FIG. 7 illustrates a flowchart of an embodiment of a process for offering a surrendered ticket to another user
- FIG. 8 illustrates a flowchart of an embodiment of a process for identifying users to whom a surrendered ticket will be offered
- FIG. 9 illustrates a flowchart of an embodiment of a process for identifying users to whom a surrendered ticket will be offered
- FIG. 10 illustrates a flowchart of an embodiment of a process for identifying users to whom a surrendered ticket will be offered
- FIG. 11 illustrates a flowchart of an embodiment of a process for identifying users to whom a surrendered ticket will be offered
- FIG. 12 depicts a block diagram of an embodiment of a computer system
- FIG. 13 depicts a block diagram of an embodiment of a special-purpose computer system.
- FIG. 1 a block diagram of an embodiment of a ticket interaction system 100 is shown.
- Users 105 and event providers 115 e.g., a sports team manager or a vendor operator
- a ticket management system 150 can interact with a ticket management system 150 via respective devices 110 and 120 and a network, such as the Internet 140 or a wide area network (WAN), local area network (LAN) 114 or other backbone.
- ticket management system 150 is made available to one or more of users 105 and/or event providers 115 via an app (that can be downloaded to and executed on a portable electronic device) or a website.
- app that can be downloaded to and executed on a portable electronic device
- system 100 can include different numbers of users 105 and/or event providers 115 .
- 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, lectures and amusement parks. Event provider 115 can further identify one or more times (which can include a date) or time periods for the event. For example, event provider 115 can indicate that a pre-game show begins at 1 pm EST and the game begins at 1:15 pm EST, or event provider 115 can indicate that lecture begins at 7 pm on Apr. 15, 2013 and will last three hours.
- Event provider 115 can identify a location of the event (e.g., a street address or venue name) and/or an expiration time (e.g., the ticket being invalid after Aug. 30, 2013). 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 .
- a location of the event e.g., a street address or venue name
- an expiration time e.g., the ticket being invalid after Aug. 30, 2013.
- 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 .
- a first user 105 - 1 can then use the ticket management system 150 to identify offer information and/or to purchase a ticket for an event, after which it can be assigned to first user 105 - 1 .
- Ticket management system 150 can use information from and/or pertaining to the ticket (e.g., information about the event) and location information to predict whether first user 105 - 1 will use the ticket. For example, system 150 can estimate whether it is likely or possible that first user 105 - 1 will be able to commute from an estimated current location to an event location and arrive at the event before it begins. This assessment can be performed at a time relative to an event- or ticket-associated time (e.g., shortly before, at or shortly after an event start time or shortly before an expiration time).
- the assessment can be based on an event location and/or a location of first user 105 - 1 .
- the latter location can be estimated based on a location of user device 110 - 1 or a determination as to whether another ticket related to the event or assigned to first user 105 - 1 has been redeemed (e.g., and, if so, where).
- system 150 can provider first user 105 - 1 with an offer to surrender the ticket. Surrendering the ticket can be for free, for guaranteed payment (e.g., less than, equal to or more than an initial purchase price of value of the ticket) or for conditioned payment (e.g., conditioned upon the ticket being subsequently purchased by another user). If first user 105 - 1 accepts the surrender offer, the surrendered ticket can then be offered to one or more second users 105 - 2 .
- the one or more second users 105 - 2 can include those who previously expressed interest in the event, who previously expressed interest in events of a type of the event, who are estimated to be at a location making it feasible and/or likely that they could arrive at the event on time, and/or who have a user relationship with the initial ticket holder (e.g., belonging to a shared season-ticket holder group or being part of a ticket-transfer club). If a second user 105 - 2 provides sufficient confirmation, information and/or payment, the ticket can then be reassigned to second user 105 - 2 . In instances in which second user 105 - 2 pays for the surrendered ticket, part or all of the payment can be provided to, e.g., event-provider 115 , an operator of ticket management system 150 and/or first user 105 - 1 .
- Ticket management system 150 can be, in part or in its entirety, in a cloud. In some instances, at least part of ticket management system 150 is present on a device, such as a user device 110 and/or event-provider device 120 .
- a payment engine 225 can be on user device 105
- a surrender-offer engine 250 can be in a cloud. In some instances, part of a component (e.g., part of surrender-offer engine 250 ) resides in a cloud and another part of the component resides in a device.
- ticket management system 150 can include a distributed system.
- Ticket management system 150 includes an account engine 205 , which generates accounts for users, stores accounts in account database 210 , identifies users' accounts and accesses account data from account database 210 .
- the account can be generated based on information provided by a user 105 and/or based on automatically detected data. For example, a user 105 can provide her name, email address, mailing address, billing address, credit card information, event types of interest and phone number. The operating system, make and model, and software capabilities of user device 110 can be automatically detected. In some instances, an account is accessed using login information. Thus, e.g., a user 105 can provide a username and password, each of which is stored in an account.
- account engine 205 can automatically detect this characteristic and store it in an account.
- the device or IP address can be matched to the appropriate account and other information from the account can be accessed.
- Account generation can occur for some or all users 105 accessing system 150 . In some instances, the generation only occurs for users 105 who participate in generating the account (e.g., by agreeing to create an account and by providing information). In some instances, the generation occurs upon detecting particular user actions (e.g., interacting with a website provided by system 150 for a set period of time, attempting to purchase a ticket, or attempting to view price of tickets). Some system functions (e.g., purchasing a ticket) can require that a user 105 be logged into an account before utilizing part or all of the functions.
- Ticket management system 150 includes a ticket-offer engine 215 , which collects information about particular offers (e.g., from an event provider 115 ).
- 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, a minimum price for a ticket to the event or service, available seats, and/or an expiration time.
- the information can 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.
- Ticket-offer engine 215 aggregates the offer information, generates an offer record that includes the aggregated information and stores the offer record in offer database 220 .
- Ticket-offer engine generates a presentation of the offer, which can include high-level information, short summaries and/or graphics, and presents (e.g., electronically via a provided user interface) the presentation of the offer to some or all users 105 .
- the offer can be presented via an app, webpage, email, SMS, MMS, voice message, etc.
- the presentation can be automatically presented (e.g., upon a user 105 accessing the app or webpage) or presented in response to a query from user 105 .
- a user 105 can interact with ticket-offer engine 215 to respond to an offer by requesting tickets.
- the request can include a number of tickets; a seating area and/or a price threshold, range or amount.
- Ticket-offer engine 215 can determine whether the requested ticket(s) are available. If they are, ticket-offer engine 215 can offer specific tickets to user 105 . This specific offer can include one or more seat numbers, one or more seating zones, one or more unique ticket identifiers, one or more event dates and/or times, one or more, event locations, and/or a price due for the ticket(s).
- Payment engine 225 can use account data and/or payment information provided in real-time by user 105 to collect the required payment for the ticket(s).
- payment engine 225 can 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 user 105 whether a required payment was completed.
- payment information e.g., a credit card number
- a ticket assigner 230 can assign the offered ticket(s).
- the ticket(s) can be assigned to designated ticket holder(s), which may be and/or include the purchasing user 105 and/or other identified individuals.
- Assigning the ticket(s) can include generating an electronic ticket or paper ticket (which can be sent by courier to the user or held at a location for the user).
- An electronic ticket can include a code (e.g., an optical code, barcode, alphanumeric code, etc.).
- the electronic ticket can include one that can be presented on a display of the user's mobile device, can include a file that can be printed, can include a token that can be electronically read (e.g., via an RF read, such as an NFC reader).
- the electronic ticket can be stored in association with an electronic record of an identification instrument of the user (e.g., a credit card/credit card number or driver's license number of the user), wherein when the user presents the identification instrument, the identification instrument may be read by an optical, magnetic, RF, or other scanner (or have an associated number manually entered via a keyboard), and system 150 may determine from an identifier scanned from the identification instrument whether there is a ticket for the event associated with the identification instrument.
- an identification instrument of the user e.g., a credit card/credit card number or driver's license number of the user
- system 150 may determine from an identifier scanned from the identification instrument whether there is a ticket for the event associated with the identification instrument.
- a generated ticket can include information about the ticket holder (e.g., the ticket holder's name), information about the event, and/or information about the specific tickets that were offered (e.g., seat numbers).
- Assigning the ticket(s) can include transmitting a ticket to user 105 (e.g., to the user's email) or granting access to a ticket via an account of the user.
- assigning the ticket(s) includes associating a ticket identifier with a user identifier or ticket-holder identifier or updating a database to add a user or ticket-holder identifier to a list (e.g., for a given event).
- Ticket assigner 230 can store any generated tickets and/or assignments in ticket database 235 .
- Ticket database 235 can further include information indicating when the tickets were purchased, whether there are any restrictions on ticket transfer (e.g., identified by an event provider 115 , identified based on a discount code, or identified based on a ticket type).
- Ticket database 235 can also include information about the purchasing user and/or ticket holders, such as information about respective mobile device(s) or other related tickets held by the user and/or ticket holder (such as parking vouchers or pre-game shows).
- ticket assigner 230 can further update an account of the ticket holder to reflect assignment of the ticket and/or to allow the ticket holder to access (e.g., view or print) the ticket.
- Ticket assigner 230 informs ticket-offer engine 215 of the assignment, such that ticket-offer engine 215 does not subsequently offer the same ticket(s) to other users 105 and/or oversell the event.
- Ticket-offer engine 215 can update an offer stored in offer database 220 to reflect the assignment (e.g., by reducing a number of available tickets or removing an identifier of a ticket from an “available” list or database).
- ticket-offer engine 215 can allow user 105 to continue to express their interest in specific tickets or groups of tickets (e.g., all tickets in a seating zone, all tickets within a price range, or all tickets for an event) despite their unavailability.
- ticket-offer engine 215 can present a user 105 with an option which, if selected, will cause a notification to be transmitted (e.g., to the user's email or to the user's phone via a call or text message) if a ticket holder subsequently surrenders his ticket such that it then becomes available.
- ticket-offer engine 215 can present a user 105 with an option which, if selected, will cause a ticket to be automatically transferred to the user (i.e., reassigned to the user) if a ticket holder subsequently surrenders his ticket.
- the user 105 can opt to become a back-up ticket holder.
- Serving as a back-up ticket holder can require that the user submit a payment (e.g., which may or may not be refunded if the ticket is not surrendered to the user, and which may be part or all of the original ticket price), that the user agree in advance to pay for and/or accept the ticket upon it being surrendered and/or that the user identify any restrictions on accepting a surrendered ticket (e.g., a required notice prior to the event's start time).
- a user can indicate that he wishes to be a back-up for a particular ticket (e.g., Seat A42) or for a group of tickets (e.g., any two consecutive seats in seating section “Lodge”).
- the number of users that can serve for a back-up may or may not be limited.
- ticket-offer engine 215 can allow no more than two backups for a given ticket, or ticket-offer engine 215 can allow no more than 150 total backups for seating zones: Lower Level A-F.
- back-up users are ranked, e.g., based on when a the users requested to be back-ups, an amount that the users are willing to pay for a surrendered ticket, an amount already paid to serve as back-ups, how much advance notice the users identified as being required to take a surrendered ticket, an account membership status, a number of tickets previously purchased from system 150 , etc.
- ticket assigner 230 can automatically identify back-ups for a ticket. For example, ticket assigner 230 can identify users who are related, through system 150 , to the ticket holder. For example, these users and the ticket holder can belong to a same season-ticket group or ticket-exchange group. Such group memberships can be identified in each group member's accounts, such that users in a group can be identified by searching through accounts for a group identifier. As another example, ticket assigner 230 can identify users who have an account with system 150 and have an address within a specified distance to an event location (potentially excluding those users who already have purchased tickets to the event). User identifications can also or alternatively depend on preferences or purchase history favoring a type of event or performer.
- an attendance predictor 240 predicts which tickets ticket holders likely wish to surrender and/or which tickets will go unused. This prediction can be made based on estimating a location of the ticket holders. If an event's start time is near, ticket holders that are estimated to be far from an event location (e.g., based on a GPS location) or not being near the event (e.g., based on not having redeemed a parking voucher) may be predicted to miss the event.
- attendance predictor 240 can access data from ticket database 235 that can aid in identifying a location of a ticket holder.
- This information can include, e.g., an identifier of a user device 115 , a related ticket identifier or an account identifier.
- a locator 245 can estimate the ticket holder's current location. For example, locator 245 can send a signal to a mobile device and request that it return its location and/or can receive location information.
- An estimated location can be determined (e.g., at a mobile device or at locator 245 ) based on GPS, cell-towers, and/or WiFi-access-point signals.
- an app e.g., provided by an operator of ticket management system 150
- downloaded and installed on the mobile device estimates a current location.
- locator 245 can determine whether a related ticket (e.g., a parking voucher) has been redeemed and identify where the redemption occurred.
- locator 245 can trace an IP address based on a recent access to an account of the ticket holder and can associate the IP address with a location.
- Locator 245 can then compare the estimated current location with a location of the event. This comparison can include identifying a separation distance and/or identifying one or more routes between the locations. The distance and/or routes can be used to estimate a transit time between the locations, which can account for current traffic conditions and/or speed limits. Locator 245 can then predict when, if the ticket holder is currently in route to the event or immediately leaves for the event, the ticket holder will be able to reach the event location. The prediction can include a single time and/or a range of times. The time(s) can be compared to a scheduled and/or predicted event start time and/or end time. Thus, e.g., locator 245 can estimate that, in a best-case scenario, a ticket holder would arrive at an event 45 minutes after it began.
- Attendance predictor 240 can access a surrender-offer criterion (e.g., which can be the same across events or can be specific to an event type, an event provider or an event).
- Attendance predictor 240 can assess the criterion in view of the estimated ticket-holder location and/or an estimated (absolute or relative) arrival time. The assessment can include, e.g., comparing a time difference between the estimated arrival time and the event start time to a threshold, determining whether the estimated location was amongst the fifty furthest (relative to an event location) amongst estimated locations for all tickets for the event, weighting an estimated lateness variable based on a number of back-ups for a ticket, etc.
- the criterion includes a factor or variable that accounts for when the criterion (e.g., relative to an event time) is being assessed. In some instances, different criteria are used based on when the criterion is being assessed. In some instances, the criterion is only evaluated during a fixed time or time period relative to an event time (e.g., 10 minutes before an estimated actual event start-time). The criterion can be designed such that satisfaction of the criterion suggests that a ticket holder may or likely will not be attending the event and/or may or likely would be interested in surrendering his ticket.
- a surrender-offer engine 250 If the surrender-offer criterion is satisfied, a surrender-offer engine 250 generates a ticket-surrender offer.
- the ticket-surrender offer can include an identification of the event (e.g., its name, location and/or start time).
- the ticket-surrender offer can further include estimations generated by locator 245 (e.g., an earliest estimated arrival time, an estimated lateness, or an estimated minimum fraction of event that the ticket holder would miss).
- the ticket-surrender offer can include an expiration time, after which the offer is no longer open.
- Surrender-offer engine 250 can determine a surrender price that could or would be provided to the ticket holder if he agrees to surrender the ticket.
- the surrender price can be determined, e.g., based on an amount that the ticket holder paid for the ticket, how many back-ups there are for the ticket, an amount that the back-ups have agreed to pay for the surrendered ticket, where back-ups are estimated to be located, an amount that the ticket would be remarketed (e.g., to back-ups, to users generally or to another entity) for, how many tickets to the event are available, when other tickets were purchased for the event (e.g., a sell-out date), a current value of the specific ticket or tickets for the event generally (e.g., based on other resale prices or auction prices), a quality of seat (e.g., seat location), an estimated probability as to how likely it is that the ticket holder will miss the event, and/or a time (e.g., relative to a scheduled
- ticket management system 150 does not set a surrender price. Rather, the ticket holder can be afforded the opportunity to set a price (which may or may not be bounded). In some instances, a recommended resale price or price range can be provided, which can be determined as similarly discussed above The ticket holder's surrender of the ticket can then be conditioned on whether another user will purchase the ticket such that the set price will be provided to the initial ticket holder. The price that the ticket would be offered to other users can be the price set by the ticket holder or a price otherwise based on the set price (but supplemented to include a fee for the transfer).
- an illustrative ticket-surrender offer may state: “This is to remind you that the Ravens-Jets football game begins at 1:15 pm today. Based on the location of your mobile phone, it is estimated that you will, at the earliest, arrive at the stadium gate at 1:45 pm. If you wish to surrender the 3 tickets that you purchased for this event in exchange for $100, click here . You may surrender your tickets for this payment only until 12:45 pm.”
- Another illustrative ticket-surrender offer may state: “You are estimated to arrive at the event venue 45 minutes after the scheduled beginning of the event if you take route 1 (along Olympic Boulevard) ⁇ link to directions ⁇ ; You are estimated to arrive at the event venue 49 minutes after the scheduled beginning of the event if you take route 2 (along Pico Boulevard) ⁇ link to directions ⁇ ; You are estimated to arrive at the event venue 54 minutes after the scheduled beginning of the event if you take route 3 (along Venice Boulevard) ⁇ link to directions ⁇ . If you are interested in surrendering your ticket for a partial refund, click here .”
- Another illustrative ticket-surrender offer may state: “Based on your current location and parking congestion, we estimate that you will miss at least the first twenty minutes of the event. If you would like to attempt to resell your ticket to another user, click here to set your resale price. You will be notified if another user has accepted your resale offer within the next ten minutes.”
- Surrender-offer engine 250 can transmit the offer to a ticket holder.
- the offer can be included in an email, message (e.g., text message), webpage text, or phone call (e.g., an automated phone call) and sent to the user's email account, phone or browser.
- the offer can include a link, phone number or email address that the ticket holder can click on, call or message or email to, e.g., view further details regarding the offer or accept or decline the offer.
- surrender-offer engine 250 can transmit multiple surrender offers to a ticket holder, which may be repeated transmissions of a same off or can vary in price (e.g., reducing a surrender price as the event nears).
- surrender-offer engine 250 can terminate transmissions of such offer upon receiving an explicit decline of the offer from the ticket holder.
- ticket assigner 230 can remove unassign the ticket to the user.
- the unassignment can include removing a ticket from ticket database 235 , removing the original ticket holder from a list or database, and/or updating the ticket holder's account.
- the ticket may be once again available.
- the ticket-offer engine 215 can then offer the ticket to users 105 .
- a price of the ticket can be less than, equal to or more than the price of the ticket when it was purchased by the original ticket holder.
- the price can be determined, e.g., based on how many tickets are available to the event, how soon the event will began (or how much of the event has already occurred), an amount that the ticket holder paid for the ticket, how many back-ups there are for the ticket, an amount the back-ups have agreed to pay for the surrendered ticket, when other tickets were purchased for the event (e.g., a sell-out date), a seat location, and/or a current value of the specific ticket or tickets for the event generally (e.g., based on other resale prices or auction prices). If a user 105 requests the ticket, payment can be collected and the ticket can be assigned as described above for the original ticket purchase.
- Ticket-offer engine 215 can offer the ticket to all users, a subset of all users, all back-up users for the ticket or a subset of the back-up users for the ticket. In one instance, ticket-offer engine 215 selectively offers the ticket to users of back-up users near an event.
- account engine 205 can identify a set of users who may be interested in the event (e.g., based on event preferences, residence location, and/or purchase history) or can identify a set of applicable back-up users (e.g., with account data indicating that they are to serve as back-up users for the event, for particular types of tickets for the event, for the particular ticket of issue, for tickets surrendered by the original ticket holder, etc.). In some instances, account engine 205 also identifies data useful to determine a real-time location of the users, such as device identifiers.
- locator 245 can estimate a current location of the users or back-up users in a manner similar to one described above. In some instances, instead, locator 245 merely uses users' or back-up users' addresses as estimates of their locations. Using the estimated locations, locator 245 can perform a similar distance and/or time estimations as described above, such as estimating when each user would be able to arrive at the event. Locator 245 can rank order the users or back-up users or select a subset of users or back-up users based on the estimations such that highly ranked users or users in the subset are those with estimated locations closest to the event location or estimated to be able to arrive at the event before its beginning or faster than other users.
- Ticket-offer engine 215 can then iteratively offer the ticket to users in the subset or of highest ranks, progressing to a next subset or rank if the initial users do not accept or respond to the offer.
- the offer can be presented to the users in a manner similar to that described above with respect to the initial offer to the original ticket holder. If and/or once a user accepts the offer (e.g., and provides required payment or payment information), ticket assigner 230 can reassign the ticket to the user.
- this illustrates how system 150 can employ an opt-in reassignment of a surrendered ticket.
- a ticket is automatically reassigned to a back-up user.
- the automatic reassignment can occur, e.g., due to the back-up user's previous explicit or implicit agreement to serve as a back-up for a particular ticket or event or a particular group of tickets or events (e.g., all tickets in a particular season-ticket row throughout the season).
- FIG. 3 illustrates a flowchart of an embodiment of a process 300 for assigning a ticket for an event to a user.
- Process 300 begins at block 305 , where ticket-offer engine 215 accesses information about an offer.
- the information can identify an event (e.g., by identifying its name, performing artist/team(s), location, and/or start time), can indicate how many tickets (e.g., and their respective zones and/or seat numbers) are to be made available to the public or a portion of the public and/or can identify one or more ticket prices.
- the information can include that provided by an event provider by interacting with ticket-offer engine 215 .
- Ticket-offer engine 215 stores the offer information in offer database 220 at block 315 .
- Ticket-offer engine 215 allocates tickets for the event at block 310 .
- the allocation can include creating an event database (stored, e.g., in ticket database 235 ), with each database element corresponding to an offered ticket. Each element can further have an assignment status, which can be “unassigned” initially.
- Ticket-offer engine 215 generates one or more offers to purchase tickets at block 315 .
- the generated offer can identify the event, can indicate that tickets are available and/or can identify prices and/or seat locations for tickets.
- the generated offer can include text and/or graphics (e.g., of seating charts).
- Ticket-offer engine 215 presents the one or more offers to users at block 325 .
- the offer can be presented, e.g., via a webpage, an app, SMS, MMS, voice message, email, etc.
- the offer can be presented by default (e.g., such that it is always presented on a webpage or such that it is presented on a webpage if a user's preferences align with the event), or it can be presented in response to a user query (e.g., for “comedy” events occurring in the next two weeks).
- Ticket-offer engine 215 detects a ticket request, in response to the offer, from a user at block 330 .
- the request can identify a number of requested tickets, a seating zone and/or one or more seat numbers.
- Payment engine 225 can determine an amount due for the requested tickets. Payment engine 225 then collects payment information from the user and obtains the user's consent to pay the determined amount at block 335 .
- Ticket assigner 230 assigns the requested ticket(s) to the user at block 340 and stores the assignment (e.g., in ticket database 235 ) at block 345 .
- the assignment can include updating the event database to associate database elements corresponding to the requested tickets to the user and/or to identify such elements as having an “assigned” status.
- the assignment can also or alternatively include generating and/or providing the user with access to the appropriate electronic and/or paper ticket(s). It will be appreciated that process 300 can also apply to an offer for tickets to a group of events (e.g., a season-ticket offer), such that block 340 can include assigning a group of tickets corresponding to a group of events to the user.
- a group of events e.g., a season-ticket offer
- FIG. 4 illustrates a flowchart of an embodiment of a process 400 for presenting a ticket holder with an offer to surrender a ticket.
- Process 400 begins at block 405 , where attendance predictor 240 detects a pre-event time. For example, attendance predictor 240 can detect that it is a threshold amount of time before or after an event's start time or that it is the event's start time.
- Attendance predictor 240 identifies one or more ticket holders at block 410 .
- the identified ticket holders can include, e.g., all ticket holders, those in preferred seating locations, those with addresses far from the event or season-ticket holders.
- locator 245 estimates a location of the ticket holder at block 415 .
- the location can be estimated by tracking a device, noting a ticket holder's home or work address, tracking access to an electronic ticket, etc.
- Locator 245 can further estimate a distance that the ticket holder is from the event, a commute time from the estimated location to the event and/or an earliest arrival time.
- Attendance predictor 240 predicts whether the ticket holder will attend the event at block 420 .
- the prediction can be based on location, distance, travel-time and/or arrival-time estimations.
- the prediction can also or alternatively be based on real-time or past communications from the ticket holder identifying whether he will attend the event and/or a probability that he will attend the event.
- Surrender-offer engine 250 determines a price to offer the ticket holder for surrendering his ticket at block 425 . Surrender-offer engine 250 presents the ticket holder with an offer to surrender the ticket at block 430 . Surrender-offer engine 250 determines whether the ticket holder accepted the offer to surrender the ticket at block 435 . If the offer is not accepted, process 400 returns to block 415 and continues with respect to another ticket holder. If the offer is accepted, process 400 continues to block 440 where payment engine 225 initiates a payment to the original ticket holder for the determined surrender-offer price (e.g., by crediting the original ticket holder's account, initiating an electronic payment, issuing a check, etc.).
- payment engine 225 initiates a payment to the original ticket holder for the determined surrender-offer price (e.g., by crediting the original ticket holder's account, initiating an electronic payment, issuing a check, etc.).
- Ticket assigner 230 removes the assignment of the ticket to the ticket holder at block 445 .
- the ticket can either be instantly reassigned to another user or can be identified as being available.
- the assignment removal can include invalidating a ticket, such as noting that a bar-code number is not to be accepted.
- process 400 is shown as being an iterative process, it can be performed such that surrender offers are presented to multiple ticket holders simultaneously. In some instances, surrender offers are presented until a threshold number of offers have been accepted. It will further be appreciated that, rather than initiating process 400 with block 405 , blocks 415 and 420 are repeatedly performed. Once a current time and estimated ticket-holder location results in an estimate of there being a low attendance probability, process 400 can continue to block 425 . It will still further be appreciated that process 400 can be modified to include conditional acceptances.
- the offer presented at block 430 can indicate that the ticket holder's surrender of the ticket will be conditioned upon whether another user purchases the ticket (e.g., for a predetermined price or a price set by the ticket holder). Blocks 440 and 445 can then occur once another user has agreed to purchased the ticket.
- FIG. 5 illustrates a flowchart of an embodiment of a process 500 for predicting whether a ticket holder will attend an event.
- Process 500 begins at block 505 , where locator 245 identifies whether a ticket holder granted permission to track her location. The permission status can be included in an account of the ticket holder and can be determined, e.g., based on input from the user entered while purchasing the ticket or setting up the account or based on whether the ticket holder changed a default permission in his account. In some instances, block 505 is omitted from process 500 .
- Locator 245 detects the ticket holder's current location at block 510 .
- Locator 245 accesses information (e.g., from offer database 220 or from an electronic ticket) indicating where an event is to or is being held at block 515 .
- Locator 245 determines one or more routes to the venue at block 520 .
- the route(s) can include one(s) that are the least distance between the locations or are predicted to involve the shortest commute time (e.g., considering current traffic. traffic patterns and/or speed limits).
- Locator 245 estimates a travel time from the current location to the event location based on the routes. The estimation can include accounting for current traffic. traffic patterns and/or speed limits.
- Locator 245 estimates an earliest realistic arrival time at block 530 . The estimation can be performed by adding the estimated travel time to a current time.
- locator 245 accesses, from offer database 220 , an event time, which can include a time when the event is scheduled. In some instances, locator 245 first accesses an event start time and then estimates an actual event start time based on historic data or scheduled pre-event activities.
- Attendance predictor 240 predicts whether the ticket holder will attend the event at block 540 .
- This prediction can include, e.g., determining whether the estimated arrival time is before the event time or determining whether the estimated arrival time is before the event time plus a set delay time (e.g., such that the ticket holder is predicted as still being able to make an event if she can arrive before 10% of the event is over).
- process 500 can further include estimating an event duration and/or end time to determine times at which a particular fraction of the event will have occurred.
- process 500 can be modified to eliminate one or more of blocks 520 - 535 , and the prediction at block 540 can include comparing a distance between a current location and an event location or an estimated travel time to a threshold.
- process 500 is extended to determine whether the ticket holder has recently been moving and, potentially, to identify a speed and/or direction of the movement. Such information can improve estimations about when the ticket holder may be able to arrive at the event and can be used to provide an estimate as to whether the ticket holder even intends to attempt to attend the event.
- Those predicted to be unable to attend the event e.g., unable to arrive by the event's start time or another threshold time
- uninterested in attending the event, or unlikely to be able to attend the event can be identified as ticket holders at block 410 for which ticket-surrender offers can be presented to.
- FIG. 6 illustrates a flowchart of an embodiment of a process 600 for predicting whether a ticket holder will attend an event.
- Process 600 begins at block 605 , where attendance predictor 240 accesses, from offer database 220 , information about an event.
- the information can identify ticket types for other services or events related to the event (e.g., for admission into a parking area or to a pre-game show).
- the information can further identify any redemption requirements, such as a check-in requirement (and/or a check-in time requirement).
- Attendance predictor 240 accesses, from account database 210 , information from an account of a ticket holder.
- the information can identify other tickets held by the ticket holder likely to be used before attending the event (e.g., vouchers for parking, shuttles, meals, etc.).
- attendance predictor 240 based on the event and/or event information, identifies one or more actions expected to occur before the event.
- the actions can include, e.g., redeeming a related ticket (e.g., parking voucher) or checking into the event.
- attendance predictor 240 estimates an absolute or relative time when the one or more actions should occur. For example, redemption of a parking voucher may be estimated to occur 15 minutes before redeeming an event voucher, or redemption of a pre-game show ticket can be estimated to occur at 11 am.
- attendance predictor 240 determines whether the pre-event action(s) have occurred (e.g., by checking for other ticket-redemption statuses). This determination can be performed at or after a time when it was estimated that the pre-event action should have occurred. Attendance predictor 240 predicts whether the ticket holder will attend the event based on the occurrence status of the pre-event action(s). If the action(s) have not occurred by an expected time or by a threshold amount of time thereafter, it can be predicted that the ticket holder will not be attending the event.
- Those predicted to be unable to attend the event e.g., unable to arrive by the event's start time or another threshold time
- unlikely to be able to attend the event can be identified as ticket holders at block 410 for which ticket-surrender offers can be presented to.
- FIG. 7 illustrates a flowchart of an embodiment of a process 700 for offering a surrendered ticket to another user.
- Process 700 begins at block 705 , where ticket-offer engine 215 detects that a ticket has been surrendered. It will be appreciated that, in some instances, block 705 can include detecting that a ticket has been conditionally surrendered (e.g., conditioned upon an agreement from another user to purchase the ticket). Ticket-offer engine 215 identifies users who potentially may be interested in owning the surrendered ticket at block 710 .
- Ticket-offer engine 215 determines details of an offer for the surrendered ticket to present to the identified user(s) at block 715 .
- ticket-offer engine 215 can identify event details (e.g., location and time), a price (which may be less than, the same as or greater than the price of the original ticket), and an offer expiration time.
- the offer further includes specific seat information.
- the offer does not include a price, as acceptance may not be charged (e.g., if a user to whom the offer is presented is in a season-ticket group with an initial ticket holder).
- the offer can also include an estimate as to a distance and/or time that the user is from the event location and/or an estimate as to an amount of the event that will be missed if he leaves for the event upon receiving the offer.
- Ticket-offer engine 215 presents an offer with the offer details to the identified user(s) at block 720 .
- the offer can be presented in a manner as described herein (e.g., via a webpage, in an email, in a text message, SMS, MMS, etc.).
- Ticket-offer engine 215 determines whether the identified user(s) accepted the offer (e.g., and potentially which of the identified users accepted the offer) at block 725 . If the offer is accepted, payment engine 225 initiates payment collection from the appropriate user at block 730 . For example, payment engine 225 can collect payment information (e.g., a credit card number and expiration date) and/or collect an agreement to pay a particular amount. In some instances, block 730 is omitted from process 700 . Ticket assigner 730 assigns the ticket to the user at block 735 (in a manner described elsewhere herein regarding ticket assignment).
- payment information e.g., a credit card number and expiration date
- a group of potential ticket holders is identified at block 710 .
- Process 700 can perform blocks 715 - 725 for single potential ticket holders, repeating the blocks until one accepts.
- an offer is simultaneously presented to multiple potential ticket holders, and the ticket is assigned to the first potential ticket holder that accepts the offer.
- the seat tickets may be awarded to the first person who accepts the sales offer.
- the tickets may be assigned in ranked order based on the order in which the offer acceptances are received.
- the first user who accepts the sales offer may be assigned the best ranked seats being offered (or the best-priced or best-valued seat), and the second person who accepts the offer may be assigned the second best ranked seats being offered, and so on.
- An offer may include more than one ticket or set of tickets, at the same or different prices.
- the offer may include 3 pairs of tickets, each at a different price and of different quality, and the user can select which of the 3 pairs the user wants to purchase.
- FIG. 8 illustrates a flowchart of an embodiment of a process 800 for identifying users to whom a surrendered ticket will be offered (e.g., at block 710 in process 700 ).
- Process 800 begins at block 805 , where ticket-offer engine 215 identifies a set of users.
- the set of users can include, e.g., all users, all users with an event preference matching a particular event characteristic, all users serving as back-up users for an event or ticket, etc.
- Locator 245 estimates a location for each user in the set at block 810 .
- the location can include a tracked device location, a home address, etc.
- Locator 245 estimates a distance and/or time that each user is from an event location 815 . This estimation can involve, e.g., actions similar to those in one or more of blocks 515 - 530 in process 500 .
- attendance predictor 240 estimates which users from the set of users are most likely or likely to be able to attend the event based on the estimated current distance and/or time.
- ticket-offer engine 215 defines potential ticket holder(s) as being those users from the set of users who are estimated to be able to attend the event, such that one or more surrendered tickets can be offered to these users.
- FIG. 9 illustrates a flowchart of an embodiment of a process 900 for identifying users to whom a surrendered ticket will be offered (e.g., at block 710 in process 700 ).
- Process 900 begins at block 905 , where ticket-offer engine 215 presents event information to users.
- the event information can include an event's name, performing artist/team/athlete, location and/or start time. In some instances, the event information includes a price of a ticket to the event.
- Ticket-offer engine 215 informs a user that tickets are no longer available to the event at block 910 .
- the user can be so informed while viewing the event information or upon an attempt to purchase a ticket to the event.
- ticket-offer engine 215 offers the user an ability to serve as a back-up ticket holder.
- Ticket-offer engine 215 can indicate that if a current ticket holder surrenders his ticket, the user could or would then be contacted such that he could acquire the ticket (or such a transfer could occur automatically).
- the offer could be with respect to a particular ticket (e.g., seat number), group of tickets (e.g., seating zone) or all tickets for the event.
- the offer may or may not include a fee that would be due in order to serve as a back-up ticket holder.
- Ticket-offer engine 215 receives an acceptance of the offer from the user at block 920 .
- block 920 can include detecting that the user clicked on a specific offer link, provided sufficient payment or payment information, called an appropriate number, etc.
- Ticket-offer engine 215 stores an indication (e.g., in the user's account) that the user will serve as a back-up ticket holder at block 925 .
- the indication can include an identification of the ticket(s) for which the user will serve as a back-up holder for and/or information regarding how to contact the user (e.g., a phone number, a call request, an email address, an email request, etc.).
- ticket-offer engine 215 defines potential ticket holder(s) as being some or all of the back-up ticket holders, such that one or more surrendered tickets can be offered to these users.
- a subset of the back-up ticket holders is identified to identify those who are close or the closest to an event location, and the potential ticket holders are defined as being the subset.
- FIG. 10 illustrates a flowchart of an embodiment of a process 1000 for identifying users to whom a surrendered ticket will be offered.
- Process 1000 begins at block 1005 , where account engine 205 presents users with group options.
- the group options can include an option to, e.g., join a fan club, a ticket-share club, a season-ticket group, etc.
- Account engine 205 detects requests to join a group from a first user and from one or more second users at block 1010 .
- the group membership may require a fee, in which case payment can be collected from the users.
- Account engine 210 grants group membership to the first and second users and stores indicators of the membership in the respective user accounts at block 1015 .
- Ticket-offer engine 215 detects that the first user surrendered a ticket at block 1020 .
- Ticket-offer engine 215 searches user accounts and identifies the second user(s) as belonging to the same group as the first user at block 1025 .
- ticket-offer engine 215 defines potential ticket holder(s) as being some or all of the second users, such that one or more surrendered tickets can be offered to these users.
- a subset of the second users is identified to identify those who are close or the closest to an event location, and the potential ticket holders are defined as being the subset.
- FIG. 11 illustrates a flowchart of an embodiment of a process 1100 for identifying users to whom a surrendered ticket will be offered.
- Process 1100 begins at block 1105 , where account engine 205 collects event preferences from users.
- the event preferences can identify types of events that the user likes to attend, preferred event locations, preferred event times (e.g., times of day, days of week, etc.), or preferred artists or athletes (e.g., sports team).
- the preferences can include those identified by the user during account generation.
- Account engine 205 stores the preferences in the respective users' accounts at block 1110 .
- Ticket-offer engine 215 identifies preferences that match an event characteristic (e.g., keyword) at block 1115 .
- Ticket-offer engine 215 searches user accounts and identifies accounts users that have accounts having the select preferences at block 1120 .
- ticket-offer engine 215 defines potential ticket holder(s) as being some or all of the users having accounts with the select preferences, such that one or more surrendered tickets can be offered to these users.
- a subset of the interest-matching users identified to identify those who are close or the closest to an event location, and the potential ticket holders are defined as being the subset.
- one or more of processes 800 , 1000 and 1100 can be used to identify users to whom an offer for an original ticket can be presented to (e.g., rather than an offer for a surrendered ticket).
- block 1020 of process 1000 can be modified to detect that the first user has purchased a ticket (e.g., thereby allowing other tickets to be offered to those likely interested in the event or interested in attending the event with the first user).
- the use of one or more of processes 800 , 1000 and 1100 with respect to original-ticket offerings can allow system 150 to reach out to users most likely to be interested in attending an event due to their location, event-type preferences, and user relationships.
- Active ticket promotion can reduce a number of unused tickets. Offers extended through active promotion can be extended during a particular time period (e.g., as an event nears) and/or can include a different ticket price compared to initial ticket offerings.
- the computer system 1200 can include a computer 1202 , keyboard 1222 , a network router 1212 , a printer 1208 , and a monitor 1206 .
- the monitor 1206 , processor 1202 and keyboard 1222 are part of a computer system 1226 , which can be a laptop computer, desktop computer, handheld computer, mainframe computer, etc.
- Monitor 1206 can be a CRT, flat screen, etc.
- a designer 1204 can input commands into computer 1202 using various input devices, such as a mouse, keyboard 1222 , track ball, touch screen, etc. If the computer system 1200 comprises a mainframe, a designer 1204 can access computer 1202 using, for example, a terminal or terminal interface. Additionally, computer system 1226 can be connected to a printer 1208 and a server 1210 using a network router 1212 , which can connect to the Internet 1218 or a WAN.
- Server 1210 can, for example, be used to store additional software programs and data.
- software implementing the systems and methods described herein can be stored on a storage medium in server 1210 .
- the software can be run from the storage medium in server 1210 .
- software implementing the systems and methods described herein can be stored on a storage medium in computer 1202 .
- the software can be run from the storage medium in computer system 1226 . Therefore, in this embodiment, the software can be used whether or not computer 1202 is connected to network router 1212 .
- Printer 1208 can be connected directly to computer 1202 , in which case, computer system 1226 can print whether or not it is connected to network router 1212 .
- Ticket management system 150 and/or any components thereof are examples of a special-purpose computer system 1300 .
- one or more special-purpose computer systems 1300 can be used to provide the function of ticket management system 150 .
- the above methods can be implemented by computer-program products that direct a computer system to perform the actions of the above-described methods and components.
- Each such computer-program product can comprise sets of instructions (codes) embodied on a computer-readable medium that directs the processor of a computer system to perform corresponding actions.
- the instructions can be configured to run in sequential order, or in parallel (such as under different processing threads), or in a combination thereof. After loading the computer-program products on a general purpose computer system 1226 , it is transformed into the special-purpose computer system 1300 .
- Special-purpose computer system 1300 comprises a computer 1202 , a monitor 1206 coupled to computer 1202 , one or more additional user output devices 1330 (optional) coupled to computer 1202 , one or more user input devices 1340 (e.g., keyboard, mouse, track ball, touch screen) coupled to computer 1202 , an optional communications interface 1350 coupled to computer 1202 , a computer-program product 1305 stored in a tangible computer-readable memory in computer 1202 .
- Computer-program product 1305 directs system 1300 to perform the above-described methods.
- Computer 1202 can include one or more processors 1360 that communicate with a number of peripheral devices via a bus subsystem 1390 .
- peripheral devices can include user output device(s) 1330 , user input device(s) 1340 , communications interface 1350 , and a storage subsystem, such as random access memory (RAM) 1370 and non-volatile storage drive 1380 (e.g., disk drive, optical drive, solid state drive), which are forms of tangible computer-readable memory.
- RAM random access memory
- non-volatile storage drive 1380 e.g., disk drive, optical drive, solid state drive
- Computer-program product 1305 can be stored in non-volatile storage drive 1390 or another computer-readable medium accessible to computer 1202 and loaded into memory 1370 .
- Each processor 1360 can comprise a microprocessor, such as a microprocessor from Intel® or Advanced Micro Devices, Inc®, or the like.
- the computer 1202 runs an operating system that handles the communications of product 1305 with the above-noted components, as well as the communications between the above-noted components in support of the computer-program product 1305 .
- Exemplary operating systems include Windows® or the like from Microsoft Corporation, Solaris® from Sun Microsystems, LINUX, UNIX, and the like.
- User input devices 1340 include all possible types of devices and mechanisms to input information to computer system 1202 . 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 1340 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 1340 typically allow a user to select objects, icons, text and the like that appear on the monitor 1206 via a command such as a click of a button or the like. User output devices 1330 include all possible types of devices and mechanisms to output information from computer 1202 . These can include a display (e.g., monitor 1206 ), printers, non-visual displays such as audio output devices, etc.
- a display e.g., monitor 1206
- printers e.g., non-visual displays
- Communications interface 1350 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 1218 .
- Embodiments of communications interface 1350 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.
- communications interface 1350 can be coupled to a computer network, to a FireWire® bus, or the like.
- communications interface 1350 can be physically integrated on the motherboard of computer 1202 , and/or can be a software program, or the like.
- RAM 1370 and non-volatile storage drive 1380 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 1370 and non-volatile storage drive 1380 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.
- RAM 1370 and non-volatile storage drive 1380 can be stored in RAM 1370 and non-volatile storage drive 1380 . These instruction sets or code can be executed by processor(s) 1360 .
- RAM 1370 and non-volatile storage drive 1380 can also provide a repository to store data and data structures used in accordance with the present invention.
- RAM 1370 and non-volatile storage drive 1380 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 1370 and non-volatile storage drive 1380 can include a file storage subsystem providing persistent (non-volatile) storage of program and/or data files.
- RAM 1370 and non-volatile storage drive 1380 can also include removable storage systems, such as removable flash memory.
- Bus subsystem 1390 provides a mechanism to allow the various components and subsystems of computer 1202 communicate with each other as intended. Although bus subsystem 1390 is shown schematically as a single bus, alternative embodiments of the bus subsystem can utilize multiple busses or communication paths within computer 1202 .
- 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.
- 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.
- ASICs application specific integrated circuits
- DSPs digital signal processors
- DSPDs digital signal processing devices
- PLDs programmable logic devices
- FPGAs field programmable gate arrays
- processors controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described above, and/or a combination thereof.
- 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.
- embodiments can be implemented by hardware, software, scripting languages, firmware, middleware, microcode, hardware description languages, and/or any combination thereof.
- 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.
- 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.
- software codes can be stored in a memory.
- Memory can be implemented within the processor or external to the processor.
- 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.
- 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.
- ROM read only memory
- RAM random access memory
- magnetic RAM magnetic RAM
- core memory magnetic disk storage mediums
- optical storage mediums flash memory devices and/or other machine readable mediums for storing information.
- 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.
Abstract
Description
- This application claims the benefit of and priority to U.S. Provisional Application No. 61/837,288, filed on Jun. 20, 2013, which is hereby incorporated by reference in its entirety for all purposes.
- This disclosure relates in general to methods and systems for identifying users based on location-based predictions of actual or possible event attendance.
- Conventionally, if on the day of a ticketed event a ticket holder cannot attend the event, the ticket holder has few options available to make use of the ticket because there is almost no time left to market the ticket. Consequentially, the ticket holder may give the ticket away or let it go unused, thereby sacrificing an amount paid for the ticket. The drawbacks are not one-sided. Others may desire to use the ticket, as the event may be sold out or the ticket may offer, e.g., seating advantages. Providing the ticket to such an interested person may be difficult due to, e.g., the ticket holder not knowing the person or not being able to easily communicate with, collect payment from, or provide the ticket to the person.
- In one embodiment, the present disclosure provides a method and system for utilizing location-based information to estimate which tickets are likely to be unused and to provide channels through which such tickets can be reassigned to others capable of attending the appropriate event. In one instance, locations of users (e.g., ticket holders or users interested in an event) are tracked (e.g., by tracking a user device or determining whether the user has redeemed other related tickets, such as a parking voucher). Based on the location, it is estimated whether and/or when the user could arrive at the event. If it is unlikely that a ticket holder will be able to arrive at the event (e.g., by the start of the event or at a different threshold), an electronic offer can be presented to the ticket holder to surrender the ticket (which may result in a partial or full compensation). If the ticket is surrendered, the ticket can be electronically offered (for free or for a price) to another user selected based on the user's location and/or relationship to the initial ticket provider (e.g., based on those in a shared season-ticket group).
- In some embodiments, a ticket management system is provided for estimating user locations and presenting location-sensitive ticket offers. A ticket database identifies, for each ticket in a set of tickets for an event, an assignment indicating whether the ticket has been assigned to a user and an identifier of any user to whom the ticket is assigned. An offer database identifies a location and a time of the event. A locator accesses the offer database to identify the location of an event and the time of the event and estimates a current location of a user. An attendance predictor that predicts whether the user will be able to attend the event, the prediction being based on the location of the event, the time of the event and the estimated current location of the user. An offer engine determines, based on the prediction of whether the user will be able to attend the event, that an offer is to be presented to the user. The offer engine also generates the offer. The offer indicates that acceptance of the offer will cause an assignment of a ticket of the set of tickets for the event to change. The offer engine further presents the offer to the user and detects an acceptance of the offer from the user. A ticket assigner changes, in response to the detection of the acceptance, the assignment of the ticket in the ticket database.
- In some embodiments, a method for estimating user locations and presenting location-sensitive ticket offers is provided. An offer database that identifies a location and a time of an event is accessed. Based on the access to the offer database, the location and time of the event are identified. A current location of a user of a ticket management system is estimated. A prediction is made as to whether the user will be able to attend the event, the prediction being based on the location of the event, the time of the event and the estimated current location of the user. Based on the prediction of whether the user will be able to attend the event, it is determined that an offer is to be presented to the user. The offer is offered, and an there is an indication that acceptance of the offer will cause an assignment of a ticket of a set of tickets for the event to change in a ticket database. The ticket database identifies, for each ticket in the set of tickets for the event. An assignment indicates whether the ticket has been assigned and an identifier of any user to whom the ticket is assigned. The offer is presented to the user. An acceptance of the offer from the user is detected. In response to the detection of the acceptance, the assignment of the ticket is changed in the ticket database.
- In some embodiments, a ticket management system is provided for estimating user locations and presenting location-sensitive ticket offers. 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 perform a method disclosed herein.
- 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:
-
FIG. 1 depicts a block diagram of an embodiment of a ticket interaction system; -
FIG. 2 depicts a block diagram of an embodiment of ticket management system; -
FIG. 3 illustrates a flowchart of an embodiment of a process for assigning a ticket for an event to a user; -
FIG. 4 illustrates a flowchart of an embodiment of a process for presenting a ticket holder with an offer to surrender a ticket; -
FIG. 5 illustrates a flowchart of an embodiment of a process for predicting whether a ticket holder will attend an event; -
FIG. 6 illustrates a flowchart of an embodiment of a process for predicting whether a ticket holder will attend an event; -
FIG. 7 illustrates a flowchart of an embodiment of a process for offering a surrendered ticket to another user; -
FIG. 8 illustrates a flowchart of an embodiment of a process for identifying users to whom a surrendered ticket will be offered; -
FIG. 9 illustrates a flowchart of an embodiment of a process for identifying users to whom a surrendered ticket will be offered; -
FIG. 10 illustrates a flowchart of an embodiment of a process for identifying users to whom a surrendered ticket will be offered; -
FIG. 11 illustrates a flowchart of an embodiment of a process for identifying users to whom a surrendered ticket will be offered; -
FIG. 12 depicts a block diagram of an embodiment of a computer system; and -
FIG. 13 depicts a block diagram of an embodiment of a special-purpose computer system. - 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.
- The ensuing description provides preferred exemplary embodiment(s) only and is not intended to limit the scope, applicability or configuration of the disclosure. Rather, the ensuing description of the preferred exemplary embodiment(s) will provide those skilled in the art with an enabling description for implementing a preferred exemplary embodiment. It is understood that various changes can be made in the function and arrangement of elements without departing from the spirit and scope as set forth in the appended claims.
- Referring first to
FIG. 1 , a block diagram of an embodiment of aticket interaction system 100 is shown. Users 105 and event providers 115 (e.g., a sports team manager or a vendor operator) can interact with aticket management system 150 viarespective devices 110 and 120 and a network, such as theInternet 140 or a wide area network (WAN), local area network (LAN) 114 or other backbone. In some embodiments,ticket management system 150 is made available to one or more of users 105 and/orevent providers 115 via an app (that can be downloaded to and executed on a portable electronic device) or a website. It will be understood that, although only two users 105 and oneevent provider 115 are shown,system 100 can include different numbers of users 105 and/orevent providers 115. - Using the
ticket management system 150, anevent 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, lectures and amusement parks.Event provider 115 can further identify one or more times (which can include a date) or time periods for the event. For example,event provider 115 can indicate that a pre-game show begins at 1 pm EST and the game begins at 1:15 pm EST, orevent provider 115 can indicate that lecture begins at 7 pm on Apr. 15, 2013 and will last three hours.Event provider 115 can identify a location of the event (e.g., a street address or venue name) and/or an expiration time (e.g., the ticket being invalid after Aug. 30, 2013). As described further below,ticket management system 150 can use the information provided byevent provider 115 to allocate tickets for the event, generate an offer and present offer information to users 105. - A first user 105-1 can then use the
ticket management system 150 to identify offer information and/or to purchase a ticket for an event, after which it can be assigned to first user 105-1.Ticket management system 150 can use information from and/or pertaining to the ticket (e.g., information about the event) and location information to predict whether first user 105-1 will use the ticket. For example,system 150 can estimate whether it is likely or possible that first user 105-1 will be able to commute from an estimated current location to an event location and arrive at the event before it begins. This assessment can be performed at a time relative to an event- or ticket-associated time (e.g., shortly before, at or shortly after an event start time or shortly before an expiration time). The assessment can be based on an event location and/or a location of first user 105-1. The latter location can be estimated based on a location of user device 110-1 or a determination as to whether another ticket related to the event or assigned to first user 105-1 has been redeemed (e.g., and, if so, where). - If it is predicted that first user 105-1 will not use the ticket,
system 150 can provider first user 105-1 with an offer to surrender the ticket. Surrendering the ticket can be for free, for guaranteed payment (e.g., less than, equal to or more than an initial purchase price of value of the ticket) or for conditioned payment (e.g., conditioned upon the ticket being subsequently purchased by another user). If first user 105-1 accepts the surrender offer, the surrendered ticket can then be offered to one or more second users 105-2. The one or more second users 105-2 can include those who previously expressed interest in the event, who previously expressed interest in events of a type of the event, who are estimated to be at a location making it feasible and/or likely that they could arrive at the event on time, and/or who have a user relationship with the initial ticket holder (e.g., belonging to a shared season-ticket holder group or being part of a ticket-transfer club). If a second user 105-2 provides sufficient confirmation, information and/or payment, the ticket can then be reassigned to second user 105-2. In instances in which second user 105-2 pays for the surrendered ticket, part or all of the payment can be provided to, e.g., event-provider 115, an operator ofticket management system 150 and/or first user 105-1. - Referring next to
FIG. 2 , a block diagram of an embodiment ofticket management system 150 is shown.Ticket management system 150 can be, in part or in its entirety, in a cloud. In some instances, at least part ofticket management system 150 is present on a device, such as a user device 110 and/or event-provider device 120. For example, apayment engine 225 can be on user device 105, and a surrender-offer engine 250 can be in a cloud. In some instances, part of a component (e.g., part of surrender-offer engine 250) resides in a cloud and another part of the component resides in a device. Thus,ticket management system 150 can include a distributed system. -
Ticket management system 150 includes anaccount engine 205, which generates accounts for users, stores accounts inaccount database 210, identifies users' accounts and accesses account data fromaccount database 210. The account can be generated based on information provided by a user 105 and/or based on automatically detected data. For example, a user 105 can provide her name, email address, mailing address, billing address, credit card information, event types of interest and phone number. The operating system, make and model, and software capabilities of user device 110 can be automatically detected. In some instances, an account is accessed using login information. Thus, e.g., a user 105 can provide a username and password, each of which is stored in an account. When user 105 subsequently enters the username and password, other information from the account can be accessed. In another instance, an account is accessed using a device identifier, IP address, etc. Thus, e.g.,account engine 205 can automatically detect this characteristic and store it in an account. When user 105 subsequently accessessystem 150 using the same device or IP address, the device or IP address can be matched to the appropriate account and other information from the account can be accessed. - Account generation can occur for some or all users 105 accessing
system 150. In some instances, the generation only occurs for users 105 who participate in generating the account (e.g., by agreeing to create an account and by providing information). In some instances, the generation occurs upon detecting particular user actions (e.g., interacting with a website provided bysystem 150 for a set period of time, attempting to purchase a ticket, or attempting to view price of tickets). Some system functions (e.g., purchasing a ticket) can require that a user 105 be logged into an account before utilizing part or all of the functions. -
Ticket management system 150 includes a ticket-offer engine 215, 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, a minimum price for a ticket to the event or service, available seats, and/or an expiration time. The information can include a time period during which the offer is to be made available. The information can further identify restrictions on the offer. For example, anevent provider 115 can limit a number of tickets available for a particular event. - Ticket-
offer engine 215 aggregates the offer information, generates an offer record that includes the aggregated information and stores the offer record inoffer database 220. Ticket-offer engine generates a presentation of the offer, which can include high-level information, short summaries and/or graphics, and presents (e.g., electronically via a provided user interface) the presentation of the offer to some or all users 105. The offer can be presented via an app, webpage, email, SMS, MMS, voice message, etc. The presentation can be automatically presented (e.g., upon a user 105 accessing the app or webpage) or presented in response to a query from user 105. - A user 105 can interact with ticket-
offer engine 215 to respond to an offer by requesting tickets. The request can include a number of tickets; a seating area and/or a price threshold, range or amount. Ticket-offer engine 215 can determine whether the requested ticket(s) are available. If they are, ticket-offer engine 215 can offer specific tickets to user 105. This specific offer can include one or more seat numbers, one or more seating zones, one or more unique ticket identifiers, one or more event dates and/or times, one or more, event locations, and/or a price due for the ticket(s).Payment engine 225 can use account data and/or payment information provided in real-time by user 105 to collect the required payment for the ticket(s). For example,payment engine 225 can 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 user 105 whether a required payment was completed. - Upon receiving the user's consent to purchase the tickets and/or collecting payments, a
ticket assigner 230 can assign the offered ticket(s). The ticket(s) can be assigned to designated ticket holder(s), which may be and/or include the purchasing user 105 and/or other identified individuals. Assigning the ticket(s) can include generating an electronic ticket or paper ticket (which can be sent by courier to the user or held at a location for the user). An electronic ticket can include a code (e.g., an optical code, barcode, alphanumeric code, etc.). The electronic ticket can include one that can be presented on a display of the user's mobile device, can include a file that can be printed, can include a token that can be electronically read (e.g., via an RF read, such as an NFC reader). The electronic ticket can be stored in association with an electronic record of an identification instrument of the user (e.g., a credit card/credit card number or driver's license number of the user), wherein when the user presents the identification instrument, the identification instrument may be read by an optical, magnetic, RF, or other scanner (or have an associated number manually entered via a keyboard), andsystem 150 may determine from an identifier scanned from the identification instrument whether there is a ticket for the event associated with the identification instrument. A generated ticket can include information about the ticket holder (e.g., the ticket holder's name), information about the event, and/or information about the specific tickets that were offered (e.g., seat numbers). Assigning the ticket(s) can include transmitting a ticket to user 105 (e.g., to the user's email) or granting access to a ticket via an account of the user. In some instances, assigning the ticket(s) includes associating a ticket identifier with a user identifier or ticket-holder identifier or updating a database to add a user or ticket-holder identifier to a list (e.g., for a given event). -
Ticket assigner 230 can store any generated tickets and/or assignments inticket database 235.Ticket database 235 can further include information indicating when the tickets were purchased, whether there are any restrictions on ticket transfer (e.g., identified by anevent provider 115, identified based on a discount code, or identified based on a ticket type).Ticket database 235 can also include information about the purchasing user and/or ticket holders, such as information about respective mobile device(s) or other related tickets held by the user and/or ticket holder (such as parking vouchers or pre-game shows). Though not shown,ticket assigner 230 can further update an account of the ticket holder to reflect assignment of the ticket and/or to allow the ticket holder to access (e.g., view or print) the ticket. -
Ticket assigner 230 informs ticket-offer engine 215 of the assignment, such that ticket-offer engine 215 does not subsequently offer the same ticket(s) to other users 105 and/or oversell the event. Ticket-offer engine 215 can update an offer stored inoffer database 220 to reflect the assignment (e.g., by reducing a number of available tickets or removing an identifier of a ticket from an “available” list or database). - Despite the removal of assigned tickets, ticket-
offer engine 215 can allow user 105 to continue to express their interest in specific tickets or groups of tickets (e.g., all tickets in a seating zone, all tickets within a price range, or all tickets for an event) despite their unavailability. For example, ticket-offer engine 215 can present a user 105 with an option which, if selected, will cause a notification to be transmitted (e.g., to the user's email or to the user's phone via a call or text message) if a ticket holder subsequently surrenders his ticket such that it then becomes available. As another example, ticket-offer engine 215 can present a user 105 with an option which, if selected, will cause a ticket to be automatically transferred to the user (i.e., reassigned to the user) if a ticket holder subsequently surrenders his ticket. Thus, the user 105 can opt to become a back-up ticket holder. Serving as a back-up ticket holder can require that the user submit a payment (e.g., which may or may not be refunded if the ticket is not surrendered to the user, and which may be part or all of the original ticket price), that the user agree in advance to pay for and/or accept the ticket upon it being surrendered and/or that the user identify any restrictions on accepting a surrendered ticket (e.g., a required notice prior to the event's start time). A user can indicate that he wishes to be a back-up for a particular ticket (e.g., Seat A42) or for a group of tickets (e.g., any two consecutive seats in seating section “Lodge”). - The number of users that can serve for a back-up may or may not be limited. For example, ticket-
offer engine 215 can allow no more than two backups for a given ticket, or ticket-offer engine 215 can allow no more than 150 total backups for seating zones: Lower Level A-F. In some instances, back-up users are ranked, e.g., based on when a the users requested to be back-ups, an amount that the users are willing to pay for a surrendered ticket, an amount already paid to serve as back-ups, how much advance notice the users identified as being required to take a surrendered ticket, an account membership status, a number of tickets previously purchased fromsystem 150, etc. - In some instances,
ticket assigner 230 can automatically identify back-ups for a ticket. For example,ticket assigner 230 can identify users who are related, throughsystem 150, to the ticket holder. For example, these users and the ticket holder can belong to a same season-ticket group or ticket-exchange group. Such group memberships can be identified in each group member's accounts, such that users in a group can be identified by searching through accounts for a group identifier. As another example,ticket assigner 230 can identify users who have an account withsystem 150 and have an address within a specified distance to an event location (potentially excluding those users who already have purchased tickets to the event). User identifications can also or alternatively depend on preferences or purchase history favoring a type of event or performer. - As an event nears, an
attendance predictor 240 predicts which tickets ticket holders likely wish to surrender and/or which tickets will go unused. This prediction can be made based on estimating a location of the ticket holders. If an event's start time is near, ticket holders that are estimated to be far from an event location (e.g., based on a GPS location) or not being near the event (e.g., based on not having redeemed a parking voucher) may be predicted to miss the event. - Thus,
attendance predictor 240 can access data fromticket database 235 that can aid in identifying a location of a ticket holder. This information can include, e.g., an identifier of auser device 115, a related ticket identifier or an account identifier. Using this information, alocator 245 can estimate the ticket holder's current location. For example,locator 245 can send a signal to a mobile device and request that it return its location and/or can receive location information. An estimated location can be determined (e.g., at a mobile device or at locator 245) based on GPS, cell-towers, and/or WiFi-access-point signals. In some instances, an app (e.g., provided by an operator of ticket management system 150) downloaded and installed on the mobile device estimates a current location. As another example,locator 245 can determine whether a related ticket (e.g., a parking voucher) has been redeemed and identify where the redemption occurred. As another example,locator 245 can trace an IP address based on a recent access to an account of the ticket holder and can associate the IP address with a location. -
Locator 245 can then compare the estimated current location with a location of the event. This comparison can include identifying a separation distance and/or identifying one or more routes between the locations. The distance and/or routes can be used to estimate a transit time between the locations, which can account for current traffic conditions and/or speed limits.Locator 245 can then predict when, if the ticket holder is currently in route to the event or immediately leaves for the event, the ticket holder will be able to reach the event location. The prediction can include a single time and/or a range of times. The time(s) can be compared to a scheduled and/or predicted event start time and/or end time. Thus, e.g.,locator 245 can estimate that, in a best-case scenario, a ticket holder would arrive at an event 45 minutes after it began. -
Attendance predictor 240 can access a surrender-offer criterion (e.g., which can be the same across events or can be specific to an event type, an event provider or an event).Attendance predictor 240 can assess the criterion in view of the estimated ticket-holder location and/or an estimated (absolute or relative) arrival time. The assessment can include, e.g., comparing a time difference between the estimated arrival time and the event start time to a threshold, determining whether the estimated location was amongst the fifty furthest (relative to an event location) amongst estimated locations for all tickets for the event, weighting an estimated lateness variable based on a number of back-ups for a ticket, etc. In some instances, the criterion includes a factor or variable that accounts for when the criterion (e.g., relative to an event time) is being assessed. In some instances, different criteria are used based on when the criterion is being assessed. In some instances, the criterion is only evaluated during a fixed time or time period relative to an event time (e.g., 10 minutes before an estimated actual event start-time). The criterion can be designed such that satisfaction of the criterion suggests that a ticket holder may or likely will not be attending the event and/or may or likely would be interested in surrendering his ticket. - If the surrender-offer criterion is satisfied, a surrender-
offer engine 250 generates a ticket-surrender offer. The ticket-surrender offer can include an identification of the event (e.g., its name, location and/or start time). The ticket-surrender offer can further include estimations generated by locator 245 (e.g., an earliest estimated arrival time, an estimated lateness, or an estimated minimum fraction of event that the ticket holder would miss). The ticket-surrender offer can include an expiration time, after which the offer is no longer open. - Surrender-
offer engine 250 can determine a surrender price that could or would be provided to the ticket holder if he agrees to surrender the ticket. The surrender price can be determined, e.g., based on an amount that the ticket holder paid for the ticket, how many back-ups there are for the ticket, an amount that the back-ups have agreed to pay for the surrendered ticket, where back-ups are estimated to be located, an amount that the ticket would be remarketed (e.g., to back-ups, to users generally or to another entity) for, how many tickets to the event are available, when other tickets were purchased for the event (e.g., a sell-out date), a current value of the specific ticket or tickets for the event generally (e.g., based on other resale prices or auction prices), a quality of seat (e.g., seat location), an estimated probability as to how likely it is that the ticket holder will miss the event, and/or a time (e.g., relative to a scheduled or estimated start-time of the event) that the offer is to be presented to the ticket holder. The ticket-surrender offer can identify the surrender price. The surrender price can be less than, equal to or greater than an initial purchase price (e.g., depending on whether an event is sold out). - In some instances,
ticket management system 150 does not set a surrender price. Rather, the ticket holder can be afforded the opportunity to set a price (which may or may not be bounded). In some instances, a recommended resale price or price range can be provided, which can be determined as similarly discussed above The ticket holder's surrender of the ticket can then be conditioned on whether another user will purchase the ticket such that the set price will be provided to the initial ticket holder. The price that the ticket would be offered to other users can be the price set by the ticket holder or a price otherwise based on the set price (but supplemented to include a fee for the transfer). - Thus, an illustrative ticket-surrender offer may state: “This is to remind you that the Ravens-Jets football game begins at 1:15 pm today. Based on the location of your mobile phone, it is estimated that you will, at the earliest, arrive at the stadium gate at 1:45 pm. If you wish to surrender the 3 tickets that you purchased for this event in exchange for $100, click here. You may surrender your tickets for this payment only until 12:45 pm.”
- Another illustrative ticket-surrender offer may state: “You are estimated to arrive at the event venue 45 minutes after the scheduled beginning of the event if you take route 1 (along Olympic Boulevard) {link to directions}; You are estimated to arrive at the event venue 49 minutes after the scheduled beginning of the event if you take route 2 (along Pico Boulevard) {link to directions}; You are estimated to arrive at the event venue 54 minutes after the scheduled beginning of the event if you take route 3 (along Venice Boulevard) {link to directions}. If you are interested in surrendering your ticket for a partial refund, click here.”
- Another illustrative ticket-surrender offer may state: “Based on your current location and parking congestion, we estimate that you will miss at least the first twenty minutes of the event. If you would like to attempt to resell your ticket to another user, click here to set your resale price. You will be notified if another user has accepted your resale offer within the next ten minutes.”
- Surrender-
offer engine 250 can transmit the offer to a ticket holder. For example, the offer can be included in an email, message (e.g., text message), webpage text, or phone call (e.g., an automated phone call) and sent to the user's email account, phone or browser. The offer can include a link, phone number or email address that the ticket holder can click on, call or message or email to, e.g., view further details regarding the offer or accept or decline the offer. In some instances, surrender-offer engine 250 can transmit multiple surrender offers to a ticket holder, which may be repeated transmissions of a same off or can vary in price (e.g., reducing a surrender price as the event nears). In some instances, surrender-offer engine 250 can terminate transmissions of such offer upon receiving an explicit decline of the offer from the ticket holder. - If surrender-
offer engine 250 detects that the ticket holder has accepted the ticket-surrender offer,ticket assigner 230 can remove unassign the ticket to the user. The unassignment can include removing a ticket fromticket database 235, removing the original ticket holder from a list or database, and/or updating the ticket holder's account. - As a result of the unassignment, the ticket may be once again available. In some instances, the ticket-
offer engine 215 can then offer the ticket to users 105. A price of the ticket can be less than, equal to or more than the price of the ticket when it was purchased by the original ticket holder. The price can be determined, e.g., based on how many tickets are available to the event, how soon the event will began (or how much of the event has already occurred), an amount that the ticket holder paid for the ticket, how many back-ups there are for the ticket, an amount the back-ups have agreed to pay for the surrendered ticket, when other tickets were purchased for the event (e.g., a sell-out date), a seat location, and/or a current value of the specific ticket or tickets for the event generally (e.g., based on other resale prices or auction prices). If a user 105 requests the ticket, payment can be collected and the ticket can be assigned as described above for the original ticket purchase. - Ticket-
offer engine 215 can offer the ticket to all users, a subset of all users, all back-up users for the ticket or a subset of the back-up users for the ticket. In one instance, ticket-offer engine 215 selectively offers the ticket to users of back-up users near an event. Thus,account engine 205 can identify a set of users who may be interested in the event (e.g., based on event preferences, residence location, and/or purchase history) or can identify a set of applicable back-up users (e.g., with account data indicating that they are to serve as back-up users for the event, for particular types of tickets for the event, for the particular ticket of issue, for tickets surrendered by the original ticket holder, etc.). In some instances,account engine 205 also identifies data useful to determine a real-time location of the users, such as device identifiers. - The collected information can be passed to
locator 245, which can estimate a current location of the users or back-up users in a manner similar to one described above. In some instances, instead,locator 245 merely uses users' or back-up users' addresses as estimates of their locations. Using the estimated locations,locator 245 can perform a similar distance and/or time estimations as described above, such as estimating when each user would be able to arrive at the event.Locator 245 can rank order the users or back-up users or select a subset of users or back-up users based on the estimations such that highly ranked users or users in the subset are those with estimated locations closest to the event location or estimated to be able to arrive at the event before its beginning or faster than other users. - Ticket-
offer engine 215 can then iteratively offer the ticket to users in the subset or of highest ranks, progressing to a next subset or rank if the initial users do not accept or respond to the offer. The offer can be presented to the users in a manner similar to that described above with respect to the initial offer to the original ticket holder. If and/or once a user accepts the offer (e.g., and provides required payment or payment information),ticket assigner 230 can reassign the ticket to the user. - Thus, this illustrates how
system 150 can employ an opt-in reassignment of a surrendered ticket. It will be appreciated that, in some other instances, a ticket is automatically reassigned to a back-up user. The automatic reassignment can occur, e.g., due to the back-up user's previous explicit or implicit agreement to serve as a back-up for a particular ticket or event or a particular group of tickets or events (e.g., all tickets in a particular season-ticket row throughout the season). -
FIG. 3 illustrates a flowchart of an embodiment of aprocess 300 for assigning a ticket for an event to a user.Process 300 begins atblock 305, where ticket-offer engine 215 accesses information about an offer. The information can identify an event (e.g., by identifying its name, performing artist/team(s), location, and/or start time), can indicate how many tickets (e.g., and their respective zones and/or seat numbers) are to be made available to the public or a portion of the public and/or can identify one or more ticket prices. The information can include that provided by an event provider by interacting with ticket-offer engine 215. Ticket-offer engine 215 stores the offer information inoffer database 220 atblock 315. - Ticket-
offer engine 215 allocates tickets for the event atblock 310. The allocation can include creating an event database (stored, e.g., in ticket database 235), with each database element corresponding to an offered ticket. Each element can further have an assignment status, which can be “unassigned” initially. - Ticket-
offer engine 215 generates one or more offers to purchase tickets atblock 315. The generated offer can identify the event, can indicate that tickets are available and/or can identify prices and/or seat locations for tickets. The generated offer can include text and/or graphics (e.g., of seating charts). Ticket-offer engine 215 presents the one or more offers to users atblock 325. The offer can be presented, e.g., via a webpage, an app, SMS, MMS, voice message, email, etc. The offer can be presented by default (e.g., such that it is always presented on a webpage or such that it is presented on a webpage if a user's preferences align with the event), or it can be presented in response to a user query (e.g., for “comedy” events occurring in the next two weeks). - Ticket-
offer engine 215 detects a ticket request, in response to the offer, from a user atblock 330. The request can identify a number of requested tickets, a seating zone and/or one or more seat numbers.Payment engine 225 can determine an amount due for the requested tickets.Payment engine 225 then collects payment information from the user and obtains the user's consent to pay the determined amount atblock 335. -
Ticket assigner 230 assigns the requested ticket(s) to the user atblock 340 and stores the assignment (e.g., in ticket database 235) atblock 345. The assignment can include updating the event database to associate database elements corresponding to the requested tickets to the user and/or to identify such elements as having an “assigned” status. The assignment can also or alternatively include generating and/or providing the user with access to the appropriate electronic and/or paper ticket(s). It will be appreciated thatprocess 300 can also apply to an offer for tickets to a group of events (e.g., a season-ticket offer), such thatblock 340 can include assigning a group of tickets corresponding to a group of events to the user. -
FIG. 4 illustrates a flowchart of an embodiment of aprocess 400 for presenting a ticket holder with an offer to surrender a ticket.Process 400 begins atblock 405, whereattendance predictor 240 detects a pre-event time. For example,attendance predictor 240 can detect that it is a threshold amount of time before or after an event's start time or that it is the event's start time. -
Attendance predictor 240 identifies one or more ticket holders atblock 410. The identified ticket holders can include, e.g., all ticket holders, those in preferred seating locations, those with addresses far from the event or season-ticket holders. For a given ticket holder of the identified ticket holders,locator 245 estimates a location of the ticket holder atblock 415. The location can be estimated by tracking a device, noting a ticket holder's home or work address, tracking access to an electronic ticket, etc.Locator 245 can further estimate a distance that the ticket holder is from the event, a commute time from the estimated location to the event and/or an earliest arrival time. -
Attendance predictor 240 predicts whether the ticket holder will attend the event atblock 420. The prediction can be based on location, distance, travel-time and/or arrival-time estimations. The prediction can also or alternatively be based on real-time or past communications from the ticket holder identifying whether he will attend the event and/or a probability that he will attend the event. - Surrender-
offer engine 250 determines a price to offer the ticket holder for surrendering his ticket atblock 425. Surrender-offer engine 250 presents the ticket holder with an offer to surrender the ticket atblock 430. Surrender-offer engine 250 determines whether the ticket holder accepted the offer to surrender the ticket atblock 435. If the offer is not accepted,process 400 returns to block 415 and continues with respect to another ticket holder. If the offer is accepted,process 400 continues to block 440 wherepayment engine 225 initiates a payment to the original ticket holder for the determined surrender-offer price (e.g., by crediting the original ticket holder's account, initiating an electronic payment, issuing a check, etc.).Ticket assigner 230 removes the assignment of the ticket to the ticket holder atblock 445. The ticket can either be instantly reassigned to another user or can be identified as being available. The assignment removal can include invalidating a ticket, such as noting that a bar-code number is not to be accepted. - It will be appreciated that, while
process 400 is shown as being an iterative process, it can be performed such that surrender offers are presented to multiple ticket holders simultaneously. In some instances, surrender offers are presented until a threshold number of offers have been accepted. It will further be appreciated that, rather than initiatingprocess 400 withblock 405, blocks 415 and 420 are repeatedly performed. Once a current time and estimated ticket-holder location results in an estimate of there being a low attendance probability,process 400 can continue to block 425. It will still further be appreciated thatprocess 400 can be modified to include conditional acceptances. Specifically, the offer presented atblock 430 can indicate that the ticket holder's surrender of the ticket will be conditioned upon whether another user purchases the ticket (e.g., for a predetermined price or a price set by the ticket holder).Blocks -
FIG. 5 illustrates a flowchart of an embodiment of aprocess 500 for predicting whether a ticket holder will attend an event.Process 500 begins atblock 505, wherelocator 245 identifies whether a ticket holder granted permission to track her location. The permission status can be included in an account of the ticket holder and can be determined, e.g., based on input from the user entered while purchasing the ticket or setting up the account or based on whether the ticket holder changed a default permission in his account. In some instances, block 505 is omitted fromprocess 500. -
Locator 245 detects the ticket holder's current location atblock 510.Locator 245 accesses information (e.g., fromoffer database 220 or from an electronic ticket) indicating where an event is to or is being held atblock 515.Locator 245 determines one or more routes to the venue atblock 520. The route(s) can include one(s) that are the least distance between the locations or are predicted to involve the shortest commute time (e.g., considering current traffic. traffic patterns and/or speed limits).Locator 245 estimates a travel time from the current location to the event location based on the routes. The estimation can include accounting for current traffic. traffic patterns and/or speed limits.Locator 245 estimates an earliest realistic arrival time atblock 530. The estimation can be performed by adding the estimated travel time to a current time. - At
block 540,locator 245 accesses, fromoffer database 220, an event time, which can include a time when the event is scheduled. In some instances,locator 245 first accesses an event start time and then estimates an actual event start time based on historic data or scheduled pre-event activities. -
Attendance predictor 240 predicts whether the ticket holder will attend the event atblock 540. This prediction can include, e.g., determining whether the estimated arrival time is before the event time or determining whether the estimated arrival time is before the event time plus a set delay time (e.g., such that the ticket holder is predicted as still being able to make an event if she can arrive before 10% of the event is over). (Thus, in some instances,process 500 can further include estimating an event duration and/or end time to determine times at which a particular fraction of the event will have occurred.) - It will be appreciated that, in some instances,
process 500 can be modified to eliminate one or more of blocks 520-535, and the prediction atblock 540 can include comparing a distance between a current location and an event location or an estimated travel time to a threshold. In some instances,process 500 is extended to determine whether the ticket holder has recently been moving and, potentially, to identify a speed and/or direction of the movement. Such information can improve estimations about when the ticket holder may be able to arrive at the event and can be used to provide an estimate as to whether the ticket holder even intends to attempt to attend the event. Those predicted to be unable to attend the event (e.g., unable to arrive by the event's start time or another threshold time), uninterested in attending the event, or unlikely to be able to attend the event can be identified as ticket holders atblock 410 for which ticket-surrender offers can be presented to. -
FIG. 6 illustrates a flowchart of an embodiment of aprocess 600 for predicting whether a ticket holder will attend an event.Process 600 begins atblock 605, whereattendance predictor 240 accesses, fromoffer database 220, information about an event. The information can identify ticket types for other services or events related to the event (e.g., for admission into a parking area or to a pre-game show). The information can further identify any redemption requirements, such as a check-in requirement (and/or a check-in time requirement). -
Attendance predictor 240 accesses, fromaccount database 210, information from an account of a ticket holder. The information can identify other tickets held by the ticket holder likely to be used before attending the event (e.g., vouchers for parking, shuttles, meals, etc.). - At
block 615, based on the event and/or event information,attendance predictor 240 identifies one or more actions expected to occur before the event. The actions can include, e.g., redeeming a related ticket (e.g., parking voucher) or checking into the event. Atblock 620,attendance predictor 240 estimates an absolute or relative time when the one or more actions should occur. For example, redemption of a parking voucher may be estimated to occur 15 minutes before redeeming an event voucher, or redemption of a pre-game show ticket can be estimated to occur at 11 am. - At
block 625,attendance predictor 240 determines whether the pre-event action(s) have occurred (e.g., by checking for other ticket-redemption statuses). This determination can be performed at or after a time when it was estimated that the pre-event action should have occurred.Attendance predictor 240 predicts whether the ticket holder will attend the event based on the occurrence status of the pre-event action(s). If the action(s) have not occurred by an expected time or by a threshold amount of time thereafter, it can be predicted that the ticket holder will not be attending the event. Those predicted to be unable to attend the event (e.g., unable to arrive by the event's start time or another threshold time) or unlikely to be able to attend the event can be identified as ticket holders atblock 410 for which ticket-surrender offers can be presented to. -
FIG. 7 illustrates a flowchart of an embodiment of aprocess 700 for offering a surrendered ticket to another user.Process 700 begins atblock 705, where ticket-offer engine 215 detects that a ticket has been surrendered. It will be appreciated that, in some instances, block 705 can include detecting that a ticket has been conditionally surrendered (e.g., conditioned upon an agreement from another user to purchase the ticket). Ticket-offer engine 215 identifies users who potentially may be interested in owning the surrendered ticket atblock 710. - Ticket-
offer engine 215 determines details of an offer for the surrendered ticket to present to the identified user(s) atblock 715. For example, ticket-offer engine 215 can identify event details (e.g., location and time), a price (which may be less than, the same as or greater than the price of the original ticket), and an offer expiration time. In some instances, the offer further includes specific seat information. In some instances, the offer does not include a price, as acceptance may not be charged (e.g., if a user to whom the offer is presented is in a season-ticket group with an initial ticket holder). The offer can also include an estimate as to a distance and/or time that the user is from the event location and/or an estimate as to an amount of the event that will be missed if he leaves for the event upon receiving the offer. Ticket-offer engine 215 presents an offer with the offer details to the identified user(s) atblock 720. The offer can be presented in a manner as described herein (e.g., via a webpage, in an email, in a text message, SMS, MMS, etc.). - Ticket-
offer engine 215 determines whether the identified user(s) accepted the offer (e.g., and potentially which of the identified users accepted the offer) atblock 725. If the offer is accepted,payment engine 225 initiates payment collection from the appropriate user atblock 730. For example,payment engine 225 can collect payment information (e.g., a credit card number and expiration date) and/or collect an agreement to pay a particular amount. In some instances, block 730 is omitted fromprocess 700.Ticket assigner 730 assigns the ticket to the user at block 735 (in a manner described elsewhere herein regarding ticket assignment). - In some instances, a group of potential ticket holders is identified at
block 710.Process 700 can perform blocks 715-725 for single potential ticket holders, repeating the blocks until one accepts. In some instances, an offer is simultaneously presented to multiple potential ticket holders, and the ticket is assigned to the first potential ticket holder that accepts the offer. In these instances, when an offer is for a specific seat (or set of seats), the seat tickets may be awarded to the first person who accepts the sales offer. When an offer does not specify a specific seat, and several seat tickets are available, the tickets may be assigned in ranked order based on the order in which the offer acceptances are received. For example, the first user who accepts the sales offer may be assigned the best ranked seats being offered (or the best-priced or best-valued seat), and the second person who accepts the offer may be assigned the second best ranked seats being offered, and so on. An offer may include more than one ticket or set of tickets, at the same or different prices. For example, the offer may include 3 pairs of tickets, each at a different price and of different quality, and the user can select which of the 3 pairs the user wants to purchase. -
FIG. 8 illustrates a flowchart of an embodiment of aprocess 800 for identifying users to whom a surrendered ticket will be offered (e.g., atblock 710 in process 700).Process 800 begins atblock 805, where ticket-offer engine 215 identifies a set of users. The set of users can include, e.g., all users, all users with an event preference matching a particular event characteristic, all users serving as back-up users for an event or ticket, etc.Locator 245 estimates a location for each user in the set atblock 810. The location can include a tracked device location, a home address, etc. -
Locator 245 estimates a distance and/or time that each user is from anevent location 815. This estimation can involve, e.g., actions similar to those in one or more of blocks 515-530 inprocess 500. Atblock 820,attendance predictor 240 estimates which users from the set of users are most likely or likely to be able to attend the event based on the estimated current distance and/or time. Atblock 825, ticket-offer engine 215 defines potential ticket holder(s) as being those users from the set of users who are estimated to be able to attend the event, such that one or more surrendered tickets can be offered to these users. -
FIG. 9 illustrates a flowchart of an embodiment of aprocess 900 for identifying users to whom a surrendered ticket will be offered (e.g., atblock 710 in process 700).Process 900 begins atblock 905, where ticket-offer engine 215 presents event information to users. The event information can include an event's name, performing artist/team/athlete, location and/or start time. In some instances, the event information includes a price of a ticket to the event. - Ticket-
offer engine 215 informs a user that tickets are no longer available to the event atblock 910. The user can be so informed while viewing the event information or upon an attempt to purchase a ticket to the event. However, atblock 915, ticket-offer engine 215 offers the user an ability to serve as a back-up ticket holder. Ticket-offer engine 215 can indicate that if a current ticket holder surrenders his ticket, the user could or would then be contacted such that he could acquire the ticket (or such a transfer could occur automatically). The offer could be with respect to a particular ticket (e.g., seat number), group of tickets (e.g., seating zone) or all tickets for the event. The offer may or may not include a fee that would be due in order to serve as a back-up ticket holder. - Ticket-
offer engine 215 receives an acceptance of the offer from the user atblock 920. For example, block 920 can include detecting that the user clicked on a specific offer link, provided sufficient payment or payment information, called an appropriate number, etc. Ticket-offer engine 215 stores an indication (e.g., in the user's account) that the user will serve as a back-up ticket holder atblock 925. The indication can include an identification of the ticket(s) for which the user will serve as a back-up holder for and/or information regarding how to contact the user (e.g., a phone number, a call request, an email address, an email request, etc.). - At
block 930, ticket-offer engine 215 defines potential ticket holder(s) as being some or all of the back-up ticket holders, such that one or more surrendered tickets can be offered to these users. In some instances, a subset of the back-up ticket holders is identified to identify those who are close or the closest to an event location, and the potential ticket holders are defined as being the subset. -
FIG. 10 illustrates a flowchart of an embodiment of aprocess 1000 for identifying users to whom a surrendered ticket will be offered.Process 1000 begins atblock 1005, whereaccount engine 205 presents users with group options. The group options can include an option to, e.g., join a fan club, a ticket-share club, a season-ticket group, etc.Account engine 205 detects requests to join a group from a first user and from one or more second users atblock 1010. The group membership may require a fee, in which case payment can be collected from the users. -
Account engine 210 grants group membership to the first and second users and stores indicators of the membership in the respective user accounts atblock 1015. Ticket-offer engine 215 detects that the first user surrendered a ticket atblock 1020. Ticket-offer engine 215 searches user accounts and identifies the second user(s) as belonging to the same group as the first user atblock 1025. - At
block 1030, ticket-offer engine 215 defines potential ticket holder(s) as being some or all of the second users, such that one or more surrendered tickets can be offered to these users. In some instances, a subset of the second users is identified to identify those who are close or the closest to an event location, and the potential ticket holders are defined as being the subset. -
FIG. 11 illustrates a flowchart of an embodiment of aprocess 1100 for identifying users to whom a surrendered ticket will be offered.Process 1100 begins atblock 1105, whereaccount engine 205 collects event preferences from users. The event preferences can identify types of events that the user likes to attend, preferred event locations, preferred event times (e.g., times of day, days of week, etc.), or preferred artists or athletes (e.g., sports team). The preferences can include those identified by the user during account generation.Account engine 205 stores the preferences in the respective users' accounts atblock 1110. - Ticket-
offer engine 215 identifies preferences that match an event characteristic (e.g., keyword) atblock 1115. Ticket-offer engine 215 searches user accounts and identifies accounts users that have accounts having the select preferences atblock 1120. - At
block 1125, ticket-offer engine 215 defines potential ticket holder(s) as being some or all of the users having accounts with the select preferences, such that one or more surrendered tickets can be offered to these users. In some instances, a subset of the interest-matching users identified to identify those who are close or the closest to an event location, and the potential ticket holders are defined as being the subset. - It will be appreciated that, in some instances, one or more of
processes process 1000 can be modified to detect that the first user has purchased a ticket (e.g., thereby allowing other tickets to be offered to those likely interested in the event or interested in attending the event with the first user). The use of one or more ofprocesses system 150 to reach out to users most likely to be interested in attending an event due to their location, event-type preferences, and user relationships. Active ticket promotion can reduce a number of unused tickets. Offers extended through active promotion can be extended during a particular time period (e.g., as an event nears) and/or can include a different ticket price compared to initial ticket offerings. - Referring next to
FIG. 12 , an exemplary environment with which embodiments can be implemented is shown with acomputer system 1200 that can be used by adesigner 1204 to design, for example, electronic designs. Thecomputer system 1200 can include acomputer 1202,keyboard 1222, anetwork router 1212, aprinter 1208, and amonitor 1206. Themonitor 1206,processor 1202 andkeyboard 1222 are part of acomputer system 1226, which can be a laptop computer, desktop computer, handheld computer, mainframe computer, etc.Monitor 1206 can be a CRT, flat screen, etc. - A
designer 1204 can input commands intocomputer 1202 using various input devices, such as a mouse,keyboard 1222, track ball, touch screen, etc. If thecomputer system 1200 comprises a mainframe, adesigner 1204 can accesscomputer 1202 using, for example, a terminal or terminal interface. Additionally,computer system 1226 can be connected to aprinter 1208 and aserver 1210 using anetwork router 1212, which can connect to theInternet 1218 or a WAN. -
Server 1210 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 inserver 1210. Thus, the software can be run from the storage medium inserver 1210. In another embodiment, software implementing the systems and methods described herein can be stored on a storage medium incomputer 1202. Thus, the software can be run from the storage medium incomputer system 1226. Therefore, in this embodiment, the software can be used whether or notcomputer 1202 is connected tonetwork router 1212.Printer 1208 can be connected directly tocomputer 1202, in which case,computer system 1226 can print whether or not it is connected tonetwork router 1212. - With reference to
FIG. 13 , an embodiment of a special-purpose computer system 1300 is shown.Ticket management system 150 and/or any components thereof are examples of a special-purpose computer system 1300. Thus, for example, one or more special-purpose computer systems 1300 can be used to provide the function ofticket management system 150. The above methods can be implemented by computer-program products that direct a computer system to perform the actions of the above-described methods and components. Each such computer-program product can comprise sets of instructions (codes) embodied on a computer-readable medium that directs the processor of a computer system to perform corresponding actions. The instructions can be configured to run in sequential order, or in parallel (such as under different processing threads), or in a combination thereof. After loading the computer-program products on a generalpurpose computer system 1226, it is transformed into the special-purpose computer system 1300. - Special-
purpose computer system 1300 comprises acomputer 1202, amonitor 1206 coupled tocomputer 1202, one or more additional user output devices 1330 (optional) coupled tocomputer 1202, one or more user input devices 1340 (e.g., keyboard, mouse, track ball, touch screen) coupled tocomputer 1202, anoptional communications interface 1350 coupled tocomputer 1202, a computer-program product 1305 stored in a tangible computer-readable memory incomputer 1202. Computer-program product 1305 directssystem 1300 to perform the above-described methods.Computer 1202 can include one ormore processors 1360 that communicate with a number of peripheral devices via abus subsystem 1390. These peripheral devices can include user output device(s) 1330, user input device(s) 1340,communications interface 1350, and a storage subsystem, such as random access memory (RAM) 1370 and non-volatile storage drive 1380 (e.g., disk drive, optical drive, solid state drive), which are forms of tangible computer-readable memory. - Computer-
program product 1305 can be stored innon-volatile storage drive 1390 or another computer-readable medium accessible tocomputer 1202 and loaded intomemory 1370. Eachprocessor 1360 can comprise a microprocessor, such as a microprocessor from Intel® or Advanced Micro Devices, Inc®, or the like. To support computer-program product 1305, thecomputer 1202 runs an operating system that handles the communications ofproduct 1305 with the above-noted components, as well as the communications between the above-noted components in support of the computer-program product 1305. Exemplary operating systems include Windows® or the like from Microsoft Corporation, Solaris® from Sun Microsystems, LINUX, UNIX, and the like. -
User input devices 1340 include all possible types of devices and mechanisms to input information tocomputer system 1202. 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 1340 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 1340 typically allow a user to select objects, icons, text and the like that appear on themonitor 1206 via a command such as a click of a button or the like.User output devices 1330 include all possible types of devices and mechanisms to output information fromcomputer 1202. These can include a display (e.g., monitor 1206), printers, non-visual displays such as audio output devices, etc. -
Communications interface 1350 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 theInternet 1218. Embodiments ofcommunications interface 1350 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 1350 can be coupled to a computer network, to a FireWire® bus, or the like. In other embodiments,communications interface 1350 can be physically integrated on the motherboard ofcomputer 1202, and/or can be a software program, or the like. -
RAM 1370 andnon-volatile storage drive 1380 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 1370 andnon-volatile storage drive 1380 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 1370 andnon-volatile storage drive 1380. These instruction sets or code can be executed by processor(s) 1360.RAM 1370 andnon-volatile storage drive 1380 can also provide a repository to store data and data structures used in accordance with the present invention.RAM 1370 andnon-volatile storage drive 1380 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 1370 andnon-volatile storage drive 1380 can include a file storage subsystem providing persistent (non-volatile) storage of program and/or data files.RAM 1370 andnon-volatile storage drive 1380 can also include removable storage systems, such as removable flash memory. -
Bus subsystem 1390 provides a mechanism to allow the various components and subsystems ofcomputer 1202 communicate with each other as intended. Althoughbus subsystem 1390 is shown schematically as a single bus, alternative embodiments of the bus subsystem can utilize multiple busses or communication paths withincomputer 1202. - 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 (25)
Priority Applications (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/295,033 US20140379390A1 (en) | 2013-06-20 | 2014-06-03 | Location-based presentations of ticket opportunities |
PCT/US2014/043357 WO2014205320A1 (en) | 2013-06-20 | 2014-06-20 | Location-based presentations of ticket opportunities |
US15/223,114 US9762685B2 (en) | 2005-04-27 | 2016-07-29 | Location-based task execution for enhanced data access |
US15/395,539 US10299189B2 (en) | 2005-04-27 | 2016-12-30 | Location-based task execution for enhanced data access |
US16/415,109 US10862983B2 (en) | 2005-04-27 | 2019-05-17 | Location-based task execution for enhanced data access |
US17/114,133 US11622017B2 (en) | 2005-04-27 | 2020-12-07 | Location based task execution for enhanced data access |
US18/175,478 US20230283682A1 (en) | 2013-06-20 | 2023-02-27 | Location-based task execution for enhanced data access |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201361837288P | 2013-06-20 | 2013-06-20 | |
US14/295,033 US20140379390A1 (en) | 2013-06-20 | 2014-06-03 | Location-based presentations of ticket opportunities |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/170,328 Continuation-In-Part US20140195278A1 (en) | 2005-04-27 | 2014-01-31 | Methods and systems for determining user location |
Related Child Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/413,062 Continuation-In-Part US8668568B2 (en) | 2005-04-27 | 2006-04-27 | Methods and systems for determining user location |
US15/223,114 Continuation-In-Part US9762685B2 (en) | 2005-04-27 | 2016-07-29 | Location-based task execution for enhanced data access |
US15/223,114 Continuation US9762685B2 (en) | 2005-04-27 | 2016-07-29 | Location-based task execution for enhanced data access |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140379390A1 true US20140379390A1 (en) | 2014-12-25 |
Family
ID=52105333
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/295,033 Abandoned US20140379390A1 (en) | 2005-04-27 | 2014-06-03 | Location-based presentations of ticket opportunities |
US15/395,539 Active US10299189B2 (en) | 2005-04-27 | 2016-12-30 | Location-based task execution for enhanced data access |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/395,539 Active US10299189B2 (en) | 2005-04-27 | 2016-12-30 | Location-based task execution for enhanced data access |
Country Status (2)
Country | Link |
---|---|
US (2) | US20140379390A1 (en) |
WO (1) | WO2014205320A1 (en) |
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150051928A1 (en) * | 2008-12-01 | 2015-02-19 | Ebay Inc. | System and methods for variable distribution and access control for purchased event tickets |
US20150154571A1 (en) * | 2013-12-04 | 2015-06-04 | Kamal Zamer | Systems and methods for dynamic event attendance management |
US20150286984A1 (en) * | 2014-04-04 | 2015-10-08 | LoungeBuddy, Inc. | Systems and methods for managing airport lounges |
US20160155088A1 (en) * | 2014-12-01 | 2016-06-02 | Curbside, Inc. | Limited location tracking of a user device for local pickup |
US9396480B2 (en) * | 2014-08-21 | 2016-07-19 | Verizon Patent And Licensing Inc. | Providing on-demand audience based on network |
US20170053217A1 (en) * | 2015-08-11 | 2017-02-23 | Arif Pardesi | System and method for increasing utilization of capacity limited and perishable events |
US20170364941A1 (en) * | 2016-06-20 | 2017-12-21 | Target Brands, Inc. | Dynamic in-store barcode promotions |
US20180268323A1 (en) * | 2016-04-25 | 2018-09-20 | Fliptix, Llc | System and Method for Resale of a Right to Occupy A Vacated Seat |
US20180322550A1 (en) * | 2016-04-25 | 2018-11-08 | Flip Tix, Inc. | System and Method for Resale of a Right to Occupy A Vacated Seat |
US20180374134A1 (en) * | 2016-04-25 | 2018-12-27 | Fliptix, Inc. | System and Method for Resale of a Right to Occupy A Vacated Seat |
US10185918B2 (en) * | 2000-11-06 | 2019-01-22 | Gtj Ventures, Llc | Apparatus and method for selling a ticket to an event and/or to a portion of an event or venue |
US10299189B2 (en) | 2005-04-27 | 2019-05-21 | Live Nation Entertainment, Inc. | Location-based task execution for enhanced data access |
US10298593B2 (en) * | 2017-06-13 | 2019-05-21 | Live Nation Entertainment, Inc. | Systems and methods for big-data resource management |
US10580023B2 (en) | 2015-11-06 | 2020-03-03 | International Business Machines Corporation | Event attendee origin prediction and impact analysis |
WO2020046899A1 (en) * | 2018-08-27 | 2020-03-05 | The Anschutz Corporation | Secure payments by third parties using a processing platform in live entertainment industries |
US10719786B1 (en) * | 2015-01-09 | 2020-07-21 | Facebook, Inc. | Event ticketing in online social networks |
US20200242684A1 (en) * | 2019-01-28 | 2020-07-30 | Mercari, Inc. | Item resale management |
US10862983B2 (en) | 2005-04-27 | 2020-12-08 | Live National Entertainment, Inc. | Location-based task execution for enhanced data access |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015190038A1 (en) * | 2014-06-10 | 2015-12-17 | パナソニックIpマネジメント株式会社 | Authentication method, authentication system, and controller |
US10853775B1 (en) * | 2016-12-29 | 2020-12-01 | Wells Fargo Bank, N.A. | Computing systems for proximity-based fees |
US10909505B2 (en) * | 2017-06-15 | 2021-02-02 | Rovi Guides, Inc. | Systems and methods for delaying the start time of an event based on event attendee arrival times |
CN107864205A (en) * | 2017-11-10 | 2018-03-30 | 上海喜泊客信息技术有限公司 | Trade company end, service end, parking card management method and system |
WO2019160960A1 (en) | 2018-02-13 | 2019-08-22 | Live Nation Entertainment, Inc. | Enhanced processing and verification of digital access rights |
US10936333B2 (en) | 2018-02-28 | 2021-03-02 | Forcepoint Llc | System and method for managing system configuration data models |
Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030216973A1 (en) * | 1999-03-02 | 2003-11-20 | Walker Jay S. | System and method for reselling a previously sold product |
US6732080B1 (en) * | 1999-09-15 | 2004-05-04 | Nokia Corporation | System and method of providing personal calendar services |
US20040260605A1 (en) * | 2003-06-17 | 2004-12-23 | Eastman Kodak Company | Method for promoting entertainment event attendance to networked users using demographic profile data |
US20060095344A1 (en) * | 2000-06-09 | 2006-05-04 | Nakfoor Brett A | System and method for fan lifecycle management |
US20060155591A1 (en) * | 2005-01-10 | 2006-07-13 | Faheem Altaf | Systems, methods, and media for managing a travel itinerary |
US20060168592A1 (en) * | 2004-12-14 | 2006-07-27 | Intrado Inc. | System and method for many-to-many information coordination and distribution |
US20060173781A1 (en) * | 2000-07-24 | 2006-08-03 | Donner Irah H | System and method for interactive messaging and/or allocating and/or upgrading and/or rewarding tickets, other event admittance means, goods and/or services |
US20080189147A1 (en) * | 2007-02-02 | 2008-08-07 | Bartlett Daniel H | Methods and systems for sharing season tickets with multiple owners and managing season tickets over a communication network |
US20110082714A1 (en) * | 2009-10-03 | 2011-04-07 | International Business Machines Corporation | Dynamic Reallocation of Seats in Rail Travel Using RFID Technology |
US20110137692A1 (en) * | 2008-08-06 | 2011-06-09 | Shaun Beheruz Sethna | System and method for boarding passengers based on valuation data |
US20120078667A1 (en) * | 2010-06-15 | 2012-03-29 | Ticketmaster, Llc | Methods and systems for computer aided event and venue setup and modeling and interactive maps |
Family Cites Families (287)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB9817270D0 (en) | 1998-08-07 | 1998-10-07 | Northern Telecom Ltd | A method of allocating resources in a telecommunications network |
US3581072A (en) | 1968-03-28 | 1971-05-25 | Frederick Nymeyer | Auction market computation system |
US3622995A (en) | 1969-03-21 | 1971-11-23 | Burroughs Corp | Automatic ticket/credit card check-in system |
US4412287A (en) | 1975-05-29 | 1983-10-25 | Braddock Iii Walter D | Automated stock exchange |
US4797677A (en) | 1982-10-29 | 1989-01-10 | Istac, Incorporated | Method and apparatus for deriving pseudo range from earth-orbiting satellites |
US4816904A (en) | 1983-06-09 | 1989-03-28 | Control Data Corporation | Television and market research data collection system and method |
US4788643A (en) | 1983-08-29 | 1988-11-29 | Trippe Kenneth A B | Cruise information and booking data processing system |
US4980826A (en) | 1983-11-03 | 1990-12-25 | World Energy Exchange Corporation | Voice actuated automated futures trading exchange |
US4603232A (en) | 1984-09-24 | 1986-07-29 | Npd Research, Inc. | Rapid market survey collection and dissemination method |
US6449346B1 (en) | 1985-07-10 | 2002-09-10 | Ronald A. Katz Technology Licensing, L.P. | Telephone-television interface statistical analysis system |
US4845739A (en) | 1985-07-10 | 1989-07-04 | Fdr Interactive Technologies | Telephonic-interface statistical analysis system |
JPH0743748B2 (en) | 1986-02-17 | 1995-05-15 | 株式会社オークネット | Information transmission processing method of auction information transmission processing system |
US4926255A (en) | 1986-03-10 | 1990-05-15 | Kohorn H Von | System for evaluation of response to broadcast transmissions |
US4799156A (en) | 1986-10-01 | 1989-01-17 | Strategic Processing Corporation | Interactive market management system |
US4862357A (en) | 1987-01-28 | 1989-08-29 | Systemone Holdings, Inc. | Computer reservation system with means to rank travel itineraries chosen in terms of schedule/fare data |
US6937998B1 (en) | 1987-12-28 | 2005-08-30 | Symbol Technologies, Inc. | Arrangement for and method of expediting transactions based on a customer's proximity to the transactions |
JP2793658B2 (en) | 1988-12-28 | 1998-09-03 | 沖電気工業株式会社 | Automatic screening device |
US5496991A (en) | 1989-02-09 | 1996-03-05 | Delfer, Iii; Frank W. | Automated remittance system |
US4889280A (en) | 1989-02-24 | 1989-12-26 | Gas Research Institute | Temperature and humidity auctioneering control |
US5077665A (en) | 1989-05-25 | 1991-12-31 | Reuters Limited | Distributed matching system |
US5136501A (en) | 1989-05-26 | 1992-08-04 | Reuters Limited | Anonymous matching system |
US5101353A (en) | 1989-05-31 | 1992-03-31 | Lattice Investments, Inc. | Automated system for providing liquidity to securities markets |
NL8902818A (en) | 1989-11-15 | 1991-06-03 | Nedap Nv | AUTOMATED CHECKOUT SYSTEM. |
DE69033520T2 (en) | 1989-11-28 | 2000-08-24 | Japan Airlines Co | SCREEN PROCESSING SYSTEM FOR A BOOKING SYSTEM AND METHOD FOR USING THIS SCREEN CALCULATOR |
US5253165A (en) | 1989-12-18 | 1993-10-12 | Eduardo Leiseca | Computerized reservations and scheduling system |
US5112050A (en) | 1990-01-05 | 1992-05-12 | John R. Koza | Broadcast lottery |
US5119295A (en) | 1990-01-25 | 1992-06-02 | Telecredit, Inc. | Centralized lottery system for remote monitoring or operations and status data from lottery terminals including detection of malfunction and counterfeit units |
AU656542B2 (en) | 1990-10-01 | 1995-02-09 | Thomas A. Bush | Transactional processing system |
CA2035767C (en) | 1991-02-06 | 1995-07-18 | Douglas Huegel | Automatic ticket dispensing system |
CA2059078C (en) | 1991-02-27 | 1995-10-03 | Alexander G. Fraser | Mediation of transactions by a communications system |
US5333257A (en) | 1991-08-09 | 1994-07-26 | C/A Architects, Inc. | System for displaying selected assembly-facility seating views |
US5426281A (en) | 1991-08-22 | 1995-06-20 | Abecassis; Max | Transaction protection system |
US5237499A (en) | 1991-11-12 | 1993-08-17 | Garback Brent J | Computer travel planning system |
US5557518A (en) | 1994-04-28 | 1996-09-17 | Citibank, N.A. | Trusted agents for open electronic commerce |
US5428778A (en) | 1992-02-13 | 1995-06-27 | Office Express Pty. Ltd. | Selective dissemination of information |
US5265916A (en) | 1992-03-19 | 1993-11-30 | Moore Business Forms, Inc. | Secure event tickets |
US5408417A (en) | 1992-05-28 | 1995-04-18 | Wilder; Wilford B. | Automated ticket sales and dispensing system |
US6023686A (en) | 1996-02-20 | 2000-02-08 | Health Hero Network | Method for conducting an on-line bidding session with bid pooling |
US5794219A (en) | 1996-02-20 | 1998-08-11 | Health Hero Network, Inc. | Method of conducting an on-line auction with bid pooling |
US5724520A (en) | 1993-06-08 | 1998-03-03 | Anthony V. Pugliese | Electronic ticketing and reservation system and method |
US5794207A (en) | 1996-09-04 | 1998-08-11 | Walker Asset Management Limited Partnership | Method and apparatus for a cryptographically assisted commercial network system designed to facilitate buyer-driven conditional purchase offers |
US5422809A (en) | 1993-08-25 | 1995-06-06 | Touch Screen Media, Inc. | Method and apparatus for providing travel destination information and making travel reservations |
CA2112077C (en) | 1993-09-15 | 1999-08-24 | Barry Craig Smith | Network architecture for allocating flight inventory segments and resources |
US5347306A (en) | 1993-12-17 | 1994-09-13 | Mitsubishi Electric Research Laboratories, Inc. | Animated electronic meeting place |
US5592375A (en) | 1994-03-11 | 1997-01-07 | Eagleview, Inc. | Computer-assisted system for interactively brokering goods or services between buyers and sellers |
US5559707A (en) | 1994-06-24 | 1996-09-24 | Delorme Publishing Company | Computer aided routing system |
US5518239A (en) | 1994-07-07 | 1996-05-21 | Johnston; William H. | Lottery racing sweepstake |
US5826241A (en) | 1994-09-16 | 1998-10-20 | First Virtual Holdings Incorporated | Computerized system for making payments and authenticating transactions over the internet |
JP3614480B2 (en) | 1994-11-18 | 2005-01-26 | 株式会社日立製作所 | Electronic ticket sales / refund system and sales / refund method |
US5598477A (en) | 1994-11-22 | 1997-01-28 | Pitney Bowes Inc. | Apparatus and method for issuing and validating tickets |
JPH08161412A (en) | 1994-12-07 | 1996-06-21 | Oak Net:Kk | Auction information transmitting and processing system |
US5553145A (en) | 1995-03-21 | 1996-09-03 | Micali; Silvia | Simultaneous electronic transactions with visible trusted parties |
US5845265A (en) | 1995-04-26 | 1998-12-01 | Mercexchange, L.L.C. | Consignment nodes |
US5489096A (en) | 1995-04-27 | 1996-02-06 | Double Win, Ltd. | Ticket systems for wagering on sports events |
US5845266A (en) | 1995-12-12 | 1998-12-01 | Optimark Technologies, Inc. | Crossing network utilizing satisfaction density profile with price discovery features |
US5664115A (en) | 1995-06-07 | 1997-09-02 | Fraser; Richard | Interactive computer system to match buyers and sellers of real estate, businesses and other property using the internet |
US5679077A (en) | 1995-08-11 | 1997-10-21 | Pocock; Terrence | System and method for remote participation in bingo and other games of chance where players select numbers |
US5757916A (en) | 1995-10-06 | 1998-05-26 | International Series Research, Inc. | Method and apparatus for authenticating the location of remote users of networked computing systems |
US5757917A (en) | 1995-11-01 | 1998-05-26 | First Virtual Holdings Incorporated | Computerized payment system for purchasing goods and services on the internet |
US5794210A (en) | 1995-12-11 | 1998-08-11 | Cybergold, Inc. | Attention brokerage |
US5812670A (en) | 1995-12-28 | 1998-09-22 | Micali; Silvio | Traceable anonymous transactions |
US5742763A (en) | 1995-12-29 | 1998-04-21 | At&T Corp. | Universal message delivery system for handles identifying network presences |
US6026383A (en) | 1996-01-04 | 2000-02-15 | Ausubel; Lawrence M. | System and method for an efficient dynamic auction for multiple objects |
US5918209A (en) | 1996-01-11 | 1999-06-29 | Talus Solutions, Inc. | Method and system for determining marginal values for use in a revenue management system |
US5766076A (en) | 1996-02-13 | 1998-06-16 | International Game Technology | Progressive gaming system and method for wide applicability |
US5797126A (en) | 1996-02-16 | 1998-08-18 | Helbling; Edward | Automatic theater ticket concierge |
US5850442A (en) | 1996-03-26 | 1998-12-15 | Entegrity Solutions Corporation | Secure world wide electronic commerce over an open network |
US5774873A (en) | 1996-03-29 | 1998-06-30 | Adt Automotive, Inc. | Electronic on-line motor vehicle auction and information system |
US6243691B1 (en) | 1996-03-29 | 2001-06-05 | Onsale, Inc. | Method and system for processing and transmitting electronic auction information |
US5835896A (en) | 1996-03-29 | 1998-11-10 | Onsale, Inc. | Method and system for processing and transmitting electronic auction information |
US6048271A (en) | 1996-05-07 | 2000-04-11 | Barcelou; David M. | Automated league and tournament device |
US6023685A (en) | 1996-05-23 | 2000-02-08 | Brett; Kenton F. | Computer controlled event ticket auctioning system |
US6704713B1 (en) | 1996-05-23 | 2004-03-09 | Ita Investments, Llc | Computer controlled event ticket auctioning system |
US7747507B2 (en) | 1996-05-23 | 2010-06-29 | Ticketmaster L.L.C. | Computer controlled auction system |
US6907405B2 (en) | 1996-05-23 | 2005-06-14 | Ita Investments, Llc | Computer controlled priority right auctioning system |
US5930761A (en) | 1996-07-08 | 1999-07-27 | O'toole; Martin J. | Ticket package management software |
US5890138A (en) | 1996-08-26 | 1999-03-30 | Bid.Com International Inc. | Computer auction system |
US6047264A (en) | 1996-08-08 | 2000-04-04 | Onsale, Inc. | Method for supplying automatic status updates using electronic mail |
EP0823694A1 (en) | 1996-08-09 | 1998-02-11 | Koninklijke KPN N.V. | Tickets stored in smart cards |
US6202023B1 (en) | 1996-08-22 | 2001-03-13 | Go2 Systems, Inc. | Internet based geographic location referencing system and method |
JP3407561B2 (en) | 1996-09-04 | 2003-05-19 | 株式会社日立製作所 | Auction apparatus and method |
US6240396B1 (en) | 1996-09-04 | 2001-05-29 | Priceline.Com Incorporated | Conditional purchase offer management system for event tickets |
US6484153B1 (en) | 1996-09-04 | 2002-11-19 | Priceline.Com Incorporated | System and method for managing third-party input to a conditional purchase offer (CPO) |
US6418415B1 (en) | 1996-09-04 | 2002-07-09 | Priceline.Com Incorporated | System and method for aggregating multiple buyers utilizing conditional purchase offers (CPOS) |
US7022017B1 (en) | 1996-09-25 | 2006-04-04 | Oneida Indian Nation | Interactive resort operating system |
US6175922B1 (en) | 1996-12-04 | 2001-01-16 | Esign, Inc. | Electronic transaction systems and methods therefor |
US7364510B2 (en) | 1998-03-31 | 2008-04-29 | Walker Digital, Llc | Apparatus and method for facilitating team play of slot machines |
US5797127A (en) | 1996-12-31 | 1998-08-18 | Walker Asset Management Limited Partnership | Method, apparatus, and program for pricing, selling, and exercising options to purchase airline tickets |
JP3869065B2 (en) | 1997-03-03 | 2007-01-17 | 株式会社東芝 | Ticket gate system, search device, and ticket management system traffic management method |
US6341353B1 (en) | 1997-04-11 | 2002-01-22 | The Brodia Group | Smart electronic receipt system |
US6999936B2 (en) | 1997-05-06 | 2006-02-14 | Sehr Richard P | Electronic ticketing system and methods utilizing multi-service visitor cards |
US6085976A (en) | 1998-05-22 | 2000-07-11 | Sehr; Richard P. | Travel system and methods utilizing multi-application passenger cards |
JP3791131B2 (en) | 1997-07-14 | 2006-06-28 | 富士ゼロックス株式会社 | Electronic ticket system |
US6119096A (en) | 1997-07-31 | 2000-09-12 | Eyeticket Corporation | System and method for aircraft passenger check-in and boarding using iris recognition |
US6146272A (en) | 1997-08-15 | 2000-11-14 | Walker Digital, Llc | Conditional lottery system |
JP2001519571A (en) | 1997-10-03 | 2001-10-23 | シティバンク,エヌ.エイ. | Method for electronically delivering specific financial services for large mobile passenger vehicles |
BR9815619A (en) | 1997-11-19 | 2000-10-24 | Robert A Sarno | Process, apparatus and system for lottery games |
US6223166B1 (en) | 1997-11-26 | 2001-04-24 | International Business Machines Corporation | Cryptographic encoded ticket issuing and collection system for remote purchasers |
US6082620A (en) | 1997-12-24 | 2000-07-04 | Bone, Jr.; Wilburn I. | Liquid crystal dynamic barcode display |
US6101477A (en) | 1998-01-23 | 2000-08-08 | American Express Travel Related Services Company, Inc. | Methods and apparatus for a travel-related multi-function smartcard |
US6154172A (en) | 1998-03-31 | 2000-11-28 | Piccionelli; Gregory A. | System and process for limiting distribution of information on a communication network based on geographic location |
US6415269B1 (en) | 1998-05-29 | 2002-07-02 | Bidcatcher, L.P. | Interactive remote auction bidding system |
US7069243B2 (en) | 1998-05-29 | 2006-06-27 | Dinwoodie David L | Interactive remote auction bidding system |
US6216227B1 (en) | 1998-06-29 | 2001-04-10 | Sun Microsystems, Inc. | Multi-venue ticketing using smart cards |
US6539080B1 (en) | 1998-07-14 | 2003-03-25 | Ameritech Corporation | Method and system for providing quick directions |
US6845361B1 (en) | 1998-07-21 | 2005-01-18 | Eric M. Dowling | Virtual-wait queue for mobile commerce |
DE69932294T8 (en) | 1998-08-12 | 2007-10-25 | Nippon Telegraph And Telephone Corp. | A recording medium with electronic ticket definitions recorded thereon and methods and apparatus for processing electronic tickets |
US6230146B1 (en) | 1998-09-18 | 2001-05-08 | Freemarkets, Inc. | Method and system for controlling closing times of electronic auctions involving multiple lots |
US7152043B2 (en) | 1999-02-19 | 2006-12-19 | Ariba, Inc. | Method and system for dynamically controlling overtime in electronic auctions |
US6192349B1 (en) | 1998-09-28 | 2001-02-20 | International Business Machines Corporation | Smart card mechanism and method for obtaining electronic tickets for goods services over an open communications link |
GB2359173A (en) | 1998-11-07 | 2001-08-15 | Identalink Uk Ltd | Identity system |
US6522875B1 (en) | 1998-11-17 | 2003-02-18 | Eric Morgan Dowling | Geographical web browser, methods, apparatus and systems |
US6308159B1 (en) | 1998-12-11 | 2001-10-23 | At&T Corporation | Method and apparatus for ticket turn-back capability |
US6470451B1 (en) | 1999-02-25 | 2002-10-22 | International Computers Limited | Cancellation method for an automatic ticket system |
US6963854B1 (en) | 1999-03-05 | 2005-11-08 | Manugistics, Inc. | Target pricing system |
JP2002541602A (en) | 1999-04-07 | 2002-12-03 | スイスコム モービル アーゲー | Methods and systems for ordering, loading, and using admission tickets |
US6847969B1 (en) | 1999-05-03 | 2005-01-25 | Streetspace, Inc. | Method and system for providing personalized online services and advertisements in public spaces |
US6704489B1 (en) | 1999-05-06 | 2004-03-09 | Matsushita Electric Industrial Co., Ltd. | Resource management system and digital video reproducing/recording apparatus |
KR101145534B1 (en) | 1999-05-19 | 2012-06-01 | 디지맥 코포레이션 | Methods and systems for controlling computers or linking to internet resources from physical and electronic objects |
US7093130B1 (en) | 2000-01-24 | 2006-08-15 | The Regents Of The University Of California | System and method for delivering and examining digital tickets |
US6983313B1 (en) * | 1999-06-10 | 2006-01-03 | Nokia Corporation | Collaborative location server/system |
EP1208504A4 (en) | 1999-07-02 | 2002-08-21 | Zebrapass Inc | System and method for provisioning ticket purchases over global or local networks |
US6477503B1 (en) | 1999-07-08 | 2002-11-05 | Robert O. Mankes | Active reservation system |
US20020095383A1 (en) | 1999-09-17 | 2002-07-18 | International Business Machines Corporation | Method and apparatus for secure sale of electronic tickets |
US6910627B1 (en) | 1999-09-29 | 2005-06-28 | Canon Kabushiki Kaisha | Smart card systems and electronic ticketing methods |
US6662230B1 (en) | 1999-10-20 | 2003-12-09 | International Business Machines Corporation | System and method for dynamically limiting robot access to server data |
US6351776B1 (en) | 1999-11-04 | 2002-02-26 | Xdrive, Inc. | Shared internet storage resource, user interface system, and method |
US20020023955A1 (en) | 1999-11-29 | 2002-02-28 | Leonard Frank | Electronic delivery of admission tickets direct to a purchaser |
AU1939101A (en) | 1999-12-02 | 2001-06-12 | Ultimate Markets, Inc. | Service contracts and commodities market for trading service contracts |
US6322446B1 (en) | 1999-12-10 | 2001-11-27 | Elot, Inc. | System and a method for operating on-line state lottery games |
US6850901B1 (en) | 1999-12-17 | 2005-02-01 | World Theatre, Inc. | System and method permitting customers to order products from multiple participating merchants |
IL150220A0 (en) | 1999-12-17 | 2002-12-01 | World Theatre Inc | Centralized telephone order and distribution system |
AU2018501A (en) | 1999-12-23 | 2001-07-09 | Nokia Corporation | Mobile lotto |
US6446045B1 (en) | 2000-01-10 | 2002-09-03 | Lucinda Stone | Method for using computers to facilitate and control the creating of a plurality of functions |
WO2001052139A1 (en) | 2000-01-13 | 2001-07-19 | Justarrive, Inc. | A system and method for electronic ticketing |
DE10001762A1 (en) | 2000-01-18 | 2001-07-19 | Schmitz Werke | Bracket for attaching the support tube of an articulated arm awning |
AU2001227934A1 (en) | 2000-01-19 | 2001-07-31 | Cyberlocator, Inc. | Method and system for controlling access to and taxation of gaming and other activities over a communitations network |
US8781940B2 (en) | 2000-01-26 | 2014-07-15 | Ebay Inc. | Method and apparatus for facilitating user selection of a category item in a transaction |
US6910019B2 (en) | 2000-01-26 | 2005-06-21 | Robert C. Dorr | Countdown on-line auction clock |
US20020035605A1 (en) | 2000-01-26 | 2002-03-21 | Mcdowell Mark | Use of presence and location information concerning wireless subscribers for instant messaging and mobile commerce |
CA2399155A1 (en) | 2000-02-07 | 2001-08-16 | Ita Investments, Llc | Computer controlled event ticket auctioning system |
US20040205065A1 (en) | 2000-02-10 | 2004-10-14 | Petras Gregory J. | System for creating and maintaining a database of information utilizing user opinions |
US20020072999A1 (en) | 2000-02-17 | 2002-06-13 | International Business Machines Corporation | System and method for providing integrated inventory control of time-sensitive inventory |
US7092892B1 (en) | 2000-03-01 | 2006-08-15 | Site59, Inc. | System and method for grouping and selling products or services |
US6952737B1 (en) | 2000-03-03 | 2005-10-04 | Intel Corporation | Method and apparatus for accessing remote storage in a distributed storage cluster architecture |
DE10011655B4 (en) | 2000-03-10 | 2004-07-01 | Siemens Ag | Method and arrangement for allocating resources in a communication system |
US6383078B1 (en) | 2000-03-17 | 2002-05-07 | Elottery, Inc. | On-line lottery game system |
US20040006497A1 (en) | 2001-03-22 | 2004-01-08 | Nestor Tod A. | Entertainment event ticket purchase and exchange system |
WO2001077962A2 (en) | 2000-04-05 | 2001-10-18 | Ods Properties, Inc. | Interactive wagering systems and methods for restricting wagering access |
KR20010097451A (en) | 2000-04-22 | 2001-11-08 | 유완상 | pre-sale system using internet |
US6604107B1 (en) | 2000-04-24 | 2003-08-05 | Ebay Inc. | Generic attribute database system for storing items of different categories having shared attributes |
US6688976B1 (en) | 2000-05-01 | 2004-02-10 | Walker Digital, Llc | Systems and methods wherein a lottery number combination is associated with a limited number of occurrences |
US7127404B1 (en) | 2000-05-11 | 2006-10-24 | Ebay, Incorporated | Method and apparatus for a dual online registration contact information system |
US7133848B2 (en) | 2000-05-19 | 2006-11-07 | Manugistics Inc. | Dynamic pricing system |
US6603568B1 (en) | 2000-05-19 | 2003-08-05 | Pitney Bowes Inc. | System and method for issuing electronic tickets |
US6327628B1 (en) | 2000-05-19 | 2001-12-04 | Epicentric, Inc. | Portal server that provides a customizable user Interface for access to computer networks |
JP2001344453A (en) | 2000-05-31 | 2001-12-14 | Koichi Nakajima | Auction system |
EP1313535A4 (en) | 2000-06-02 | 2006-04-05 | Gtech Corp | Game of chance with multiple paths on a virtual scratch ticket |
WO2001097135A2 (en) | 2000-06-09 | 2001-12-20 | Manugistics Atlanta, Inc. | Event revenue management system |
US7149549B1 (en) | 2000-10-26 | 2006-12-12 | Ortiz Luis M | Providing multiple perspectives for a venue activity through an electronic hand held device |
JP2002024464A (en) | 2000-07-07 | 2002-01-25 | Nec Corp | System and method for selling ticket with ic card, and recording medium |
WO2002004977A2 (en) | 2000-07-12 | 2002-01-17 | Cyberlocator, Inc. | Geolocation of telecommunications devices by means of space-based signals processed in a networked computer architecture |
US7162454B1 (en) | 2000-07-24 | 2007-01-09 | Donner Irah H | System and method for reallocating and/or upgrading and/or selling tickets, other even admittance means, goods and/or services |
US7177945B2 (en) | 2000-08-04 | 2007-02-13 | Avaya Technology Corp. | Non-intrusive multiplexed transaction persistency in secure commerce environments |
US7099841B1 (en) | 2000-08-04 | 2006-08-29 | Sports Securities, Inc. | Methods and systems for trading permanent seat licenses |
US6820201B1 (en) | 2000-08-04 | 2004-11-16 | Sri International | System and method using information-based indicia for securing and authenticating transactions |
US20020052786A1 (en) | 2000-08-09 | 2002-05-02 | Lg Electronics Inc. | Informative system based on user's position and operating method thereof |
US7333943B1 (en) | 2000-08-11 | 2008-02-19 | The Prudential Insurance Company Of America | Method and system for managing real property transactions having internet access and control |
AU2001288293A1 (en) | 2000-08-16 | 2002-02-25 | Omead Amidi | Scannable barcode display and methods for using the same |
US7058602B1 (en) | 2000-08-18 | 2006-06-06 | Luckysurf.Com, Inc. | Enhanced auction mechanism for online transactions |
US6434398B1 (en) | 2000-09-06 | 2002-08-13 | Eric Inselberg | Method and apparatus for interactive audience participation at a live spectator event |
US6944599B1 (en) | 2000-09-13 | 2005-09-13 | Ebay Inc. | Monitoring and automatic notification of irregular activity in a network-based transaction facility |
US6523037B1 (en) | 2000-09-22 | 2003-02-18 | Ebay Inc, | Method and system for communicating selected search results between first and second entities over a network |
US20020040346A1 (en) | 2000-09-27 | 2002-04-04 | Kwan Khai Hee | Computer system and method for on-line generating a password protected and barcode prepaid instrument of entitlement and activating said instrument on presentation over a computer network |
JP4645928B2 (en) | 2000-09-29 | 2011-03-09 | ヤマハ株式会社 | Admission authentication method and system |
KR100397813B1 (en) | 2000-09-29 | 2003-09-13 | 주식회사 시큐베이 | The integrated customer management system using wireless barcode |
JP2002183769A (en) | 2000-10-02 | 2002-06-28 | Kobelco Systems Corp | Electronic ticket system using binary code |
JP2002189933A (en) | 2000-10-10 | 2002-07-05 | Sharp Corp | Related information providing system for specific electronic information |
US7660740B2 (en) | 2000-10-16 | 2010-02-09 | Ebay Inc. | Method and system for listing items globally and regionally, and customized listing according to currency or shipping area |
US20020052758A1 (en) | 2000-10-26 | 2002-05-02 | Arthur Roland Bushonville | Method and apparatus for providing rights for event tickets |
TW581955B (en) | 2000-10-27 | 2004-04-01 | Manugistics Inc | Supply chain demand forecasting and planning |
US7035932B1 (en) | 2000-10-27 | 2006-04-25 | Eric Morgan Dowling | Federated multiprotocol communication |
US6965914B2 (en) | 2000-10-27 | 2005-11-15 | Eric Morgan Dowling | Negotiated wireless peripheral systems |
US6901429B2 (en) | 2000-10-27 | 2005-05-31 | Eric Morgan Dowling | Negotiated wireless peripheral security systems |
US6877665B2 (en) | 2000-11-20 | 2005-04-12 | Ecrio, Inc. | System, method, and apparatus for communicating information encoded in a light-based signal using a fob device |
US6685093B2 (en) | 2001-09-25 | 2004-02-03 | Ecrio, Inc. | System, method and apparatus for communicating information between a mobile communications device and a bar code reader |
US6736322B2 (en) | 2000-11-20 | 2004-05-18 | Ecrio Inc. | Method and apparatus for acquiring, maintaining, and using information to be communicated in bar code form with a mobile communications device |
KR20020042028A (en) | 2000-11-29 | 2002-06-05 | 윤종용 | Method for providing and using ticket and system thereof |
US7299206B2 (en) | 2000-11-30 | 2007-11-20 | Ebay Inc. | Method and system to implement seller authorized buying privileges within a network-based shopping facility |
US20020082969A1 (en) | 2000-12-21 | 2002-06-27 | O'keeffe Gerard M. | Event ticket pricing and distribution system |
US20020091555A1 (en) | 2000-12-22 | 2002-07-11 | Leppink David Morgan | Fraud-proof internet ticketing system and method |
US7555361B2 (en) | 2000-12-25 | 2009-06-30 | Sony Corporation | Apparatus, system and method for electronic ticket management and electronic ticket distribution authentication |
US20020087456A1 (en) | 2000-12-29 | 2002-07-04 | Daniel Abeshouse | Method, apparatus, and system for synchronizing timing of an auction throug a computer network |
GB2370888B (en) | 2001-01-09 | 2003-03-19 | Searchspace Ltd | A method and system for combating robots and rogues |
JP4307747B2 (en) | 2001-01-25 | 2009-08-05 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Connection reception system, reception server, client terminal, connection reception management method, storage medium, computer program |
WO2002069107A2 (en) | 2001-02-28 | 2002-09-06 | Musicrebellion Com, Inc. | Digital online exchange |
JP2002279113A (en) | 2001-03-22 | 2002-09-27 | Fujitsu Ltd | Event participation invitation method |
US7080328B1 (en) | 2001-03-28 | 2006-07-18 | Ebay, Inc. | Graphical user interface for filtering a population of items |
US6987734B2 (en) | 2001-04-20 | 2006-01-17 | Clear Channel Wireless, Inc. | Provision of digital data via multiple broadcasts |
US20030003984A1 (en) | 2001-04-30 | 2003-01-02 | Petruzzi Anthony J. | Method and system for globally accessible offshore lottery game |
US7018292B2 (en) | 2001-05-25 | 2006-03-28 | Scientific Games Royalty Corporation | Methods and systems for metered raffle-style gaming |
EP1401546A4 (en) | 2001-06-15 | 2006-11-02 | Walker Digital Llc | Method and apparatus for planning and customizing a gaming experience |
US20030013530A1 (en) | 2001-07-12 | 2003-01-16 | Telecents Communications Inc. | Lottery club system |
US7716126B2 (en) | 2001-07-26 | 2010-05-11 | U-Pickit.Com, Inc. | Method of facilitating participation in lotteries |
US20030060264A1 (en) | 2001-09-21 | 2003-03-27 | Chilton Ward W. | Gaming device providing tournament entries |
US7085818B2 (en) | 2001-09-27 | 2006-08-01 | International Business Machines Corporation | Method, system, and program for providing information on proximate events based on current location and user availability |
US8032442B2 (en) | 2001-09-27 | 2011-10-04 | Stubhub, Inc. | System and method for providing logistics for a sale of goods |
US7044362B2 (en) | 2001-10-10 | 2006-05-16 | Hewlett-Packard Development Company, L.P. | Electronic ticketing system and method |
US6824464B2 (en) | 2001-11-09 | 2004-11-30 | Scientific Games Corporation | Prepaid account lottery system and method |
US6920428B2 (en) | 2001-11-19 | 2005-07-19 | The Friday Group Llc | Method of selling and distributing articles associated with live events |
US7076558B1 (en) | 2002-02-27 | 2006-07-11 | Microsoft Corporation | User-centric consent management system and method |
US7213754B2 (en) | 2002-02-27 | 2007-05-08 | Digonex Technologies, Inc. | Dynamic pricing system with graphical user interface |
JP2003331171A (en) | 2002-05-10 | 2003-11-21 | Nec Soft Ltd | Booking server, method for sale by subscription, and program |
US6671633B2 (en) | 2002-05-13 | 2003-12-30 | Entek Ird International Corporation | Modular monitoring and protection system with automatic device programming |
US7139916B2 (en) | 2002-06-28 | 2006-11-21 | Ebay, Inc. | Method and system for monitoring user interaction with a computer |
US6854651B2 (en) | 2002-07-01 | 2005-02-15 | Wildseed Ltd. | Non-persistently displayed bar code based data input method and apparatus |
US7403993B2 (en) | 2002-07-24 | 2008-07-22 | Kasenna, Inc. | System and method for highly-scalable real-time and time-based data delivery using server clusters |
US7083081B2 (en) | 2002-10-08 | 2006-08-01 | First Data Corporation | Electronic card and ticket and methods for their use |
US7035626B1 (en) | 2002-11-14 | 2006-04-25 | Sierra Design Group | Remote gaming using cell phones with location and identity restrictions |
US20040111369A1 (en) | 2002-11-20 | 2004-06-10 | Lane Kathleen Heila | Method to associate the geographic location of a participant with the content of a communications session |
JP2004295197A (en) | 2003-03-25 | 2004-10-21 | Nec Corp | Electronic ticket vending system and method |
EP1618486A4 (en) | 2003-03-27 | 2008-10-08 | Univ Washington | Performing predictive pricing based on historical data |
CA2426236A1 (en) | 2003-04-22 | 2004-10-22 | Daniel Bartozzi | Wireless gaming system |
US7191147B2 (en) | 2003-06-12 | 2007-03-13 | Adpay, Inc. | Facilitating the sale of ad items via the internet |
US7127408B2 (en) | 2003-06-13 | 2006-10-24 | Rosen Michael J | Method of creating season ticket package |
US7305398B2 (en) | 2003-06-15 | 2007-12-04 | Mordechai Teicher | Apparatus and method for managing social games |
US7817013B2 (en) | 2003-09-05 | 2010-10-19 | Honeywell International Inc. | Distributed stand-off ID verification compatible with multiple face recognition systems (FRS) |
US20050071417A1 (en) | 2003-09-29 | 2005-03-31 | Jeffrey Taylor | Method and apparatus for geolocation of a network user |
US7124062B2 (en) | 2003-12-30 | 2006-10-17 | Sap Ag | Services search method |
US8086591B2 (en) | 2004-01-23 | 2011-12-27 | Microsoft Corporation | Combining domain-tuned search systems |
US7635304B2 (en) | 2004-01-27 | 2009-12-22 | Integrated Group Assets Inc. | Multiple levels of participation in a lottery jackpot |
US20070060358A1 (en) | 2005-08-10 | 2007-03-15 | Amaitis Lee M | System and method for wireless gaming with location determination |
US8616967B2 (en) | 2004-02-25 | 2013-12-31 | Cfph, Llc | System and method for convenience gaming |
US7584123B1 (en) | 2004-04-06 | 2009-09-01 | Ticketmaster | Systems for dynamically allocating finite or unique resources |
US7395257B2 (en) | 2004-06-14 | 2008-07-01 | Ebay Inc. | Automated method and system to calculate the surface distance between two geographical locations, and to filter a data set based on the calculation |
US20060025222A1 (en) | 2004-07-27 | 2006-02-02 | Aruze Corp. | Gaming machine, service providing system, server and mobile device |
US7630313B2 (en) | 2004-09-30 | 2009-12-08 | Alcatel-Lucent Usa Inc. | Scheduled determination of network resource availability |
US9152651B2 (en) | 2004-10-15 | 2015-10-06 | Celeritasworks, Llc | Ticket entry systems and methods |
US7577847B2 (en) | 2004-11-03 | 2009-08-18 | Igt | Location and user identification for online gaming |
US7890376B2 (en) | 2004-11-05 | 2011-02-15 | Ebay Inc. | System and method for location based content correlation |
US8346843B2 (en) | 2004-12-10 | 2013-01-01 | Google Inc. | System and method for scalable data distribution |
US7080882B2 (en) | 2004-12-14 | 2006-07-25 | Douglas Stitt | Seat lock |
US20060136969A1 (en) | 2004-12-22 | 2006-06-22 | Patton David L | Ordering promotional materials during motion picture showing |
US20060155857A1 (en) | 2005-01-06 | 2006-07-13 | Oracle International Corporation | Deterministic session state management within a global cache array |
EP1866885A4 (en) | 2005-03-22 | 2011-12-21 | Ticketmaster | Apparatus and methods for providing queue messaging over a network |
US20140379390A1 (en) | 2013-06-20 | 2014-12-25 | Live Nation Entertainment, Inc. | Location-based presentations of ticket opportunities |
US20070055439A1 (en) | 2005-04-27 | 2007-03-08 | Dennis Denker | Methods and systems for selectively providing a networked service |
KR100767025B1 (en) | 2005-05-04 | 2007-10-17 | 김미영 | Method of selling tickets in advance in regular sequence and apparatus thereof |
WO2007044500A2 (en) | 2005-10-06 | 2007-04-19 | C-Sam, Inc. | Transactional services |
US7634503B2 (en) | 2005-11-21 | 2009-12-15 | Amadeus S.A.S. | Method and system for selecting answers in answer set using a customizable table |
US20080015983A1 (en) * | 2005-12-21 | 2008-01-17 | Spikes Stacy G | System and method for subscription-based mobile electronic movie ticketing |
AU2007212489B2 (en) | 2006-02-07 | 2013-01-31 | Ticketmaster | Methods and systems for reducing burst usage of a networked computer system |
WO2007109099A2 (en) * | 2006-03-17 | 2007-09-27 | Sports & Leisure Enterprises, Llc. | System and method for exchanging event tickets |
US20080021998A1 (en) | 2006-07-20 | 2008-01-24 | Rachel Wentink | Presence-based resource locator |
JP4857066B2 (en) * | 2006-10-03 | 2012-01-18 | 株式会社日立製作所 | Data processing method and storage demand system in storage on demand system |
US8056129B2 (en) | 2007-04-19 | 2011-11-08 | International Business Machines Corporation | Validating active computer terminal sessions |
US8090603B2 (en) * | 2007-05-11 | 2012-01-03 | Fansnap, Inc. | System and method for selecting event tickets |
US20090276364A1 (en) | 2008-05-05 | 2009-11-05 | Vito Iaia | Process control system |
US8438612B2 (en) | 2007-11-06 | 2013-05-07 | Varonis Systems Inc. | Visualization of access permission status |
US20090282045A1 (en) | 2008-05-09 | 2009-11-12 | Business Objects, S.A. | Apparatus and method for accessing data in a multi-tenant database according to a trust hierarchy |
US8255288B1 (en) | 2009-02-03 | 2012-08-28 | Amazon Technologies, Inc. | High demand sale processing |
KR101146538B1 (en) | 2010-02-25 | 2012-05-25 | 조덕용 | Method for producing cushion member using polyurethane form and fabric |
CN102884548A (en) | 2010-03-02 | 2013-01-16 | 易快私人有限公司 | System and process for managing sale of one or more items |
US20110231913A1 (en) | 2010-03-17 | 2011-09-22 | State of Oregon acting by and through the State Board of Education on Behalf of Portland State | System and methods of determining computational puzzle difficulty for challenge-response authentication |
WO2011146859A1 (en) * | 2010-05-21 | 2011-11-24 | Matthew David Wells | System and method for presenting events |
US8528054B2 (en) | 2010-08-31 | 2013-09-03 | Yahoo! Inc. | Multi-step challenge-response test |
US8694401B2 (en) | 2011-01-13 | 2014-04-08 | Lenddo, Limited | Systems and methods for using online social footprint for affecting lending performance and credit scoring |
US9105034B2 (en) | 2011-03-23 | 2015-08-11 | International Business Machines Corporation | Implementing computer interaction response tests |
US8776173B2 (en) | 2011-03-24 | 2014-07-08 | AYAH, Inc. | Method for generating a human likeness score |
AU2011202182B1 (en) | 2011-05-11 | 2011-10-13 | Frequency Ip Holdings, Llc | Creation and presentation of selective digital content feeds |
KR20130020385A (en) * | 2011-08-19 | 2013-02-27 | 하종수 | Method and system for providing event ticketing service by using mobile terminal |
WO2013093209A1 (en) | 2011-12-21 | 2013-06-27 | Ssh Communications Security Oyj | Automated access, key, certificate, and credential management |
US20140278610A1 (en) | 2013-03-15 | 2014-09-18 | Live Nation Entertainment, Inc. | Abuse tolerant ticketing system |
WO2013152311A1 (en) | 2012-04-06 | 2013-10-10 | Live Nation Entertainment, Inc. | Methods and systems of inhibiting automated scripts from accessing a ticket site |
US20130346226A1 (en) | 2012-06-25 | 2013-12-26 | Robert F. Nunes | Systems and methods for event planning and participation and a ballot platform for transactions for goods and services |
US8874770B2 (en) | 2013-01-09 | 2014-10-28 | Evernym, Inc. | Systems and methods for access-controlled interactions |
JP2016519806A (en) | 2013-03-14 | 2016-07-07 | オントミクス, インコーポレイテッド | System and method for a personalized clinical decision support tool |
US9407620B2 (en) | 2013-08-23 | 2016-08-02 | Morphotrust Usa, Llc | System and method for identity management |
US20150294335A1 (en) | 2014-04-10 | 2015-10-15 | Mastercard International Incorporated | Geo-level consumer purchase penetration data mart |
WO2015191647A2 (en) | 2014-06-11 | 2015-12-17 | Live Nation Entertainment, Inc. | Dynamic filtering and precision alteration of query responses responsive to request load |
US9489787B1 (en) * | 2014-08-08 | 2016-11-08 | Live Nation Entertainment, Inc. | Short-range device communications for secured resource access |
DE102014018449B3 (en) | 2014-12-12 | 2016-06-09 | Audi Ag | Electric machine |
US9466035B2 (en) | 2015-01-13 | 2016-10-11 | Songkick.Com B.V. | Systems and methods for leveraging social queuing to facilitate event ticket distribution |
US10078851B2 (en) | 2015-01-13 | 2018-09-18 | Live Nation Entertainment, Inc. | Systems and methods for leveraging social queuing to identify and prevent ticket purchaser simulation |
US10171437B2 (en) | 2015-04-24 | 2019-01-01 | Oracle International Corporation | Techniques for security artifacts management |
US10567479B2 (en) | 2015-08-05 | 2020-02-18 | Facebook, Inc. | Managing a device cloud |
US20170061509A1 (en) * | 2015-08-07 | 2017-03-02 | Stubblr Inc. | System for providing location services in facilitating in-person exchange of goods or services |
-
2014
- 2014-06-03 US US14/295,033 patent/US20140379390A1/en not_active Abandoned
- 2014-06-20 WO PCT/US2014/043357 patent/WO2014205320A1/en active Application Filing
-
2016
- 2016-12-30 US US15/395,539 patent/US10299189B2/en active Active
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030216973A1 (en) * | 1999-03-02 | 2003-11-20 | Walker Jay S. | System and method for reselling a previously sold product |
US6732080B1 (en) * | 1999-09-15 | 2004-05-04 | Nokia Corporation | System and method of providing personal calendar services |
US20060095344A1 (en) * | 2000-06-09 | 2006-05-04 | Nakfoor Brett A | System and method for fan lifecycle management |
US20060173781A1 (en) * | 2000-07-24 | 2006-08-03 | Donner Irah H | System and method for interactive messaging and/or allocating and/or upgrading and/or rewarding tickets, other event admittance means, goods and/or services |
US20040260605A1 (en) * | 2003-06-17 | 2004-12-23 | Eastman Kodak Company | Method for promoting entertainment event attendance to networked users using demographic profile data |
US20060168592A1 (en) * | 2004-12-14 | 2006-07-27 | Intrado Inc. | System and method for many-to-many information coordination and distribution |
US20060155591A1 (en) * | 2005-01-10 | 2006-07-13 | Faheem Altaf | Systems, methods, and media for managing a travel itinerary |
US20080189147A1 (en) * | 2007-02-02 | 2008-08-07 | Bartlett Daniel H | Methods and systems for sharing season tickets with multiple owners and managing season tickets over a communication network |
US20110137692A1 (en) * | 2008-08-06 | 2011-06-09 | Shaun Beheruz Sethna | System and method for boarding passengers based on valuation data |
US20110082714A1 (en) * | 2009-10-03 | 2011-04-07 | International Business Machines Corporation | Dynamic Reallocation of Seats in Rail Travel Using RFID Technology |
US20120078667A1 (en) * | 2010-06-15 | 2012-03-29 | Ticketmaster, Llc | Methods and systems for computer aided event and venue setup and modeling and interactive maps |
Cited By (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10185918B2 (en) * | 2000-11-06 | 2019-01-22 | Gtj Ventures, Llc | Apparatus and method for selling a ticket to an event and/or to a portion of an event or venue |
US11622017B2 (en) | 2005-04-27 | 2023-04-04 | Live Nation Entertainment, Inc. | Location based task execution for enhanced data access |
US10862983B2 (en) | 2005-04-27 | 2020-12-08 | Live National Entertainment, Inc. | Location-based task execution for enhanced data access |
US10299189B2 (en) | 2005-04-27 | 2019-05-21 | Live Nation Entertainment, Inc. | Location-based task execution for enhanced data access |
US20150051928A1 (en) * | 2008-12-01 | 2015-02-19 | Ebay Inc. | System and methods for variable distribution and access control for purchased event tickets |
US9911086B2 (en) * | 2008-12-01 | 2018-03-06 | Ebay Inc. | System and methods for variable distribution and access control for purchased event tickets |
US20150154571A1 (en) * | 2013-12-04 | 2015-06-04 | Kamal Zamer | Systems and methods for dynamic event attendance management |
US11328269B2 (en) * | 2013-12-04 | 2022-05-10 | Stubhub, Inc. | Systems and methods for dynamic event attendance management |
US20150286984A1 (en) * | 2014-04-04 | 2015-10-08 | LoungeBuddy, Inc. | Systems and methods for managing airport lounges |
US20190138982A1 (en) * | 2014-04-04 | 2019-05-09 | LoungeBuddy, Inc. | Systems and methods for managing airport lounges |
US10248928B2 (en) * | 2014-04-04 | 2019-04-02 | LoungeBuddy, Inc. | Systems and methods for managing airport lounges |
US10621617B2 (en) | 2014-08-21 | 2020-04-14 | Verizon Patent And Licensing Inc. | Providing on-demand audience based on network |
US9396480B2 (en) * | 2014-08-21 | 2016-07-19 | Verizon Patent And Licensing Inc. | Providing on-demand audience based on network |
US10740718B2 (en) * | 2014-12-01 | 2020-08-11 | Curbside, Inc. | Limited location tracking of a user device for local pickup |
US20160155088A1 (en) * | 2014-12-01 | 2016-06-02 | Curbside, Inc. | Limited location tracking of a user device for local pickup |
US10719786B1 (en) * | 2015-01-09 | 2020-07-21 | Facebook, Inc. | Event ticketing in online social networks |
US20170053217A1 (en) * | 2015-08-11 | 2017-02-23 | Arif Pardesi | System and method for increasing utilization of capacity limited and perishable events |
US10580023B2 (en) | 2015-11-06 | 2020-03-03 | International Business Machines Corporation | Event attendee origin prediction and impact analysis |
US20180322550A1 (en) * | 2016-04-25 | 2018-11-08 | Flip Tix, Inc. | System and Method for Resale of a Right to Occupy A Vacated Seat |
US20180268323A1 (en) * | 2016-04-25 | 2018-09-20 | Fliptix, Llc | System and Method for Resale of a Right to Occupy A Vacated Seat |
US20180374134A1 (en) * | 2016-04-25 | 2018-12-27 | Fliptix, Inc. | System and Method for Resale of a Right to Occupy A Vacated Seat |
US20170364941A1 (en) * | 2016-06-20 | 2017-12-21 | Target Brands, Inc. | Dynamic in-store barcode promotions |
US11223627B2 (en) | 2017-06-13 | 2022-01-11 | Live Nation Entertainment, Inc. | Systems and methods for big-data resource management |
US10298593B2 (en) * | 2017-06-13 | 2019-05-21 | Live Nation Entertainment, Inc. | Systems and methods for big-data resource management |
WO2020046899A1 (en) * | 2018-08-27 | 2020-03-05 | The Anschutz Corporation | Secure payments by third parties using a processing platform in live entertainment industries |
US20200242684A1 (en) * | 2019-01-28 | 2020-07-30 | Mercari, Inc. | Item resale management |
Also Published As
Publication number | Publication date |
---|---|
US20170230894A1 (en) | 2017-08-10 |
US10299189B2 (en) | 2019-05-21 |
WO2014205320A1 (en) | 2014-12-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20140379390A1 (en) | Location-based presentations of ticket opportunities | |
US20220180255A1 (en) | Biased ticket offers for actors identified using dynamic assessments of actors' attributes | |
US9251518B2 (en) | Centralized and device-aware ticket-transfer system and methods | |
US8700447B2 (en) | Systems and methods to present search results of business listings | |
US20160148122A1 (en) | Collaborative event preview management system | |
EP2836979A1 (en) | Methods and systems of inhibiting automated scripts from accessing a ticket site | |
US20110010244A1 (en) | Sponsored application launcher suggestions | |
US20150095073A1 (en) | Facilitating passenger to manage airline reservation within electronic message | |
US20140040040A1 (en) | Systems and methods for delivering message-based advertising and providing charitable fundraising | |
US20180053227A1 (en) | Establishing communications with optimal electronic device | |
EP2866176A1 (en) | Tiered oversubscription | |
US20130046580A1 (en) | Computerized, pull based, event scheduling apparatus and method | |
US20160042445A1 (en) | System and Method for Recurrent Rental Vehicle Location and Rate Selection Using Network Based Data | |
AU2014263193B2 (en) | Systems and methods for minimizing travel costs for multi-night stays | |
WO2017205214A1 (en) | Location-based activity computer systems | |
US20150058136A1 (en) | Attribute based coupon provisioning | |
JP6949577B2 (en) | Information processing equipment, information processing methods and programs | |
US20220237664A1 (en) | Personalized mobile application re-engagement | |
US20120239741A1 (en) | Inducement server, user inducement system and user inducement method | |
US20130226698A1 (en) | System, method and program for embedding in line advertisements during a multi-factor authentication session | |
US9858589B2 (en) | Measuring search lift resulted by online advertisement | |
US10891649B1 (en) | Automatic virtual phone number pool management | |
US20150051964A1 (en) | Providing offers for local discounted goods and services | |
US20120323742A1 (en) | Method and system for brokering services with time-dependent labor rates | |
JP6983184B2 (en) | Information processing equipment, advertisement distribution methods, and programs |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: LIVE NATION ENTERTAINMENT, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SCARBOROUGH, DAVID;REEL/FRAME:033022/0397 Effective date: 20140523 |
|
AS | Assignment |
Owner name: JPMORGAN CHASE BANK, N.A., AS COLLATERAL AGENT, DELAWARE Free format text: SECURITY AGREEMENT;ASSIGNORS:LIVE NATION ENTERTAINMENT, INC.;LIVE NATION WORLDWIDE, INC.;REEL/FRAME:040521/0186 Effective date: 20161031 Owner name: JPMORGAN CHASE BANK, N.A., AS COLLATERAL AGENT, DE Free format text: SECURITY AGREEMENT;ASSIGNORS:LIVE NATION ENTERTAINMENT, INC.;LIVE NATION WORLDWIDE, INC.;REEL/FRAME:040521/0186 Effective date: 20161031 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |