US20140379390A1 - Location-based presentations of ticket opportunities - Google Patents

Location-based presentations of ticket opportunities Download PDF

Info

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
Application number
US14/295,033
Inventor
David Scarborough
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Live Nation Entertainment Inc
Original Assignee
Live Nation Entertainment Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Live Nation Entertainment Inc filed Critical Live Nation Entertainment Inc
Priority to US14/295,033 priority Critical patent/US20140379390A1/en
Assigned to LIVE NATION ENTERTAINMENT, INC. reassignment LIVE NATION ENTERTAINMENT, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SCARBOROUGH, DAVID
Priority to PCT/US2014/043357 priority patent/WO2014205320A1/en
Publication of US20140379390A1 publication Critical patent/US20140379390A1/en
Priority to US15/223,114 priority patent/US9762685B2/en
Assigned to JPMORGAN CHASE BANK, N.A., AS COLLATERAL AGENT reassignment JPMORGAN CHASE BANK, N.A., AS COLLATERAL AGENT SECURITY AGREEMENT Assignors: LIVE NATION ENTERTAINMENT, INC., LIVE NATION WORLDWIDE, INC.
Priority to US15/395,539 priority patent/US10299189B2/en
Priority to US16/415,109 priority patent/US10862983B2/en
Priority to US17/114,133 priority patent/US11622017B2/en
Priority to US18/175,478 priority patent/US20230283682A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W48/00Access restriction; Network selection; Access point selection
    • H04W48/02Access restriction performed under specific conditions
    • H04W48/04Access restriction performed under specific conditions based on user or terminal location or mobility data, e.g. moving direction, speed
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0601Electronic shopping [e-shopping]
    • G06Q30/0639Item locations
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Administration; Management
    • G06Q10/02Reservations, e.g. for tickets, services or events
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02Services making use of location information
    • H04W4/023Services 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

Location-based information is used 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) are tracked (e.g., by tracking a user device or determining whether the user has redeemed other related tickets, such as a parking voucher), and 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, 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 to another user selected based on the user's location and/or relationship to the initial ticket provider.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • 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.
  • BACKGROUND
  • 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.
  • SUMMARY
  • 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.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • 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.
  • DETAILED DESCRIPTION
  • 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 a ticket interaction system 100 is shown. Users 105 and event providers 115 (e.g., a sports team manager or a vendor operator) can interact with a ticket management system 150 via respective devices 110 and 120 and a network, such as the Internet 140 or a wide area network (WAN), local area network (LAN) 114 or other backbone. In some embodiments, ticket management system 150 is made available to one or more of users 105 and/or event providers 115 via an app (that can be downloaded to and executed on a portable electronic device) or a website. It will be understood that, although only two users 105 and one event provider 115 are shown, system 100 can include different numbers of users 105 and/or event providers 115.
  • Using the ticket management system 150, an event provider 115 can identify an event, a price of attending the event, a date or dates of the event, a location or locations of the event, etc. Examples of events for which tickets can be obtained include sporting events, concerts, meals, shows, movies, 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 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 of ticket management system 150 and/or first user 105-1.
  • Referring next to FIG. 2, a block diagram of an embodiment of ticket management system 150 is shown. Ticket management system 150 can be, in part or in its entirety, in a cloud. In some instances, at least part of ticket management system 150 is present on a device, such as a user device 110 and/or event-provider device 120. For example, a payment 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 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. 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 accesses system 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 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). 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, 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). 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), 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. 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 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). 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 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).
  • 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 from system 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, 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.
  • 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 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. Using this information, 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. 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 from ticket 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 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.
  • 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. For a given ticket holder of the identified 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.). 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.
  • 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 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. Specifically, 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.
  • At block 540, 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). (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 at block 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 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.).
  • 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. At block 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 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. 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) 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).
  • 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 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. At block 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. At block 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 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. However, at block 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 at block 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 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.).
  • 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 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.
  • 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 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.
  • 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 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). In this case, e.g., 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.
  • Referring next to FIG. 12, an exemplary environment with which embodiments can be implemented is shown with a computer system 1200 that can be used by a designer 1204 to design, for example, electronic designs. 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. In one embodiment, software implementing the systems and methods described herein can be stored on a storage medium in server 1210. Thus, the software can be run from the storage medium in server 1210. In another embodiment, software implementing the systems and methods described herein can be stored on a storage medium in computer 1202. Thus, 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.
  • 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 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. 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 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. To support computer-program product 1305, 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.
  • 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. 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 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.
  • Software instruction sets that provide the functionality of the present invention 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.
  • 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)

1. A ticket management system for estimating user locations and presenting location-sensitive ticket offers, the ticket management system comprising:
a ticket database that 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 that identifies a location and a time of the event;
a locator that:
accesses the offer database to identify the location of an event and the time of the event,
receives a signal from each of a plurality of transmitters, each of the plurality of transmitters including a global positioning satellite, a Wi-Fi access point or a cell phone tower; and
estimates, at a time prior to the time of the event, a current location of a mobile device of a user based on the signals from the plurality of transmitters;
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 that:
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,
generates the offer, the offer indicating that acceptance of the offer will cause an assignment of a ticket of the set of tickets for the event to change,
presents the offer to the user; and
detects an acceptance of the offer from the user; and
a ticket assigner that, in response to the detection of the acceptance, changes the assignment of the ticket in the ticket database.
2. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 1, wherein:
the offer engine comprises a surrender-offer engine that determines that the offer is to be presented to the user when the attendance predictor predicts that the user will not be able to attend the event,
the ticket is, prior to the acceptance, assigned to the user,
the offer is an offer to surrender the ticket, and
the ticket assigner changes the assignment of the ticket by removing the assignment.
3. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 2, further comprising:
a ticket-offer engine that:
generates a second offer,
presents the second offer to a second user, and
detects a second acceptance of the second offer from the second user,
wherein the ticket assigner, in response to the detection of the second acceptance, assigns the ticket to the second user in the ticket database.
4. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 2, wherein the detected acceptance of the offer is a conditioned acceptance, the acceptance being conditioned upon another user agreeing to purchase the ticket, and wherein the assignment is only changed upon occurrence of the another user agreeing to purchase the ticket.
5. (canceled)
6. (canceled)
7. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 1, further comprising an account database including a plurality of accounts, wherein:
each account corresponds to a respective user,
at least one account of the plurality of accounts includes a variable indicating that the respective user is to serve as a back-up ticket holder for the event,
the offer engine queries the account database for an account with the variable indicating that the respective user is to serve as a back-up ticket holder for the event,
the user is identified based on the query,
the offer is an offer to have a right to use the ticket, and
the ticket assigner changes the assignment of the ticket by assigning the ticket to the user.
8. A method for estimating user locations and presenting location-sensitive ticket offers, the method comprising:
accessing an offer database that identifies a location and a time of an event;
identifying, based on the access to the offer database, the location and time of the event;
receiving a signal from each of a plurality of transmitters, each of the plurality of transmitters including a global positioning satellite, a Wi-Fi access point or a cell phone tower;
estimating, at a time prior to the time of the event, a current location of a mobile device of a user based on the signals from the plurality of transmitters;
predicting 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;
determining, 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,
generating the offer, the offer indicating 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 identifying, for each ticket in the set of tickets for the event, an assignment indicating whether the ticket has been assigned and an identifier of any user to whom the ticket is assigned;
presenting the offer to the user;
detecting an acceptance of the offer from the user; and
changing, in response to the detection of the acceptance, the assignment of the ticket in the ticket database.
9. The method for estimating user locations and presenting location-sensitive ticket offers as recited in claim 8, wherein:
determining that the offer is to be presented comprises determining that the offer is to be presented to the user when the attendance predictor predicts that the user will not be able to attend the event,
the ticket is, prior to the acceptance, assigned to the user,
the offer is an offer to surrender the ticket, and
changing the assignment comprises removing the assignment.
10. The method for estimating user locations and presenting location-sensitive ticket offers as recited in claim 9, further comprising:
generating a second offer;
presenting the second offer to a second user;
detecting a second acceptance of the second offer from the second user; and
assigning, in response to the detection of the second acceptance, the ticket to the second user in the ticket database.
11. The method for estimating user locations and presenting location-sensitive ticket offers as recited in claim 9, wherein the detected acceptance of the offer is a conditioned acceptance, the acceptance being conditioned upon another user agreeing to purchase the ticket, and wherein the assignment is only changed upon occurrence of the another user agreeing to purchase the ticket.
12. (canceled)
13. (canceled)
14. The method for estimating user locations and presenting location-sensitive ticket offers as recited in claim 8, further comprising:
querying an account database for an account from amongst a plurality of accounts with the variable indicating that a respective user of the account is to serve as a back-up ticket holder for the event; and
identifying the user based on the query,
wherein the offer is an offer to have a right to use the ticket, and
wherein changing the assignment of the ticket comprises assigning the ticket to the user.
15. A ticket management system for estimating user locations and presenting location-sensitive ticket offers, the ticket management system comprising:
one or more processors; and
one or more memories coupled with the one or more processors, wherein the one or more processors and one or more memories are configured to:
access an offer database that identifies a location and a time of an event;
identify, based on the access to the offer database, the location and time of the event;
receive a signal from each of a plurality of transmitters, each of the plurality of transmitters including a global positioning satellite, a Wi-Fi access point or a cell phone tower;
estimate, at a time prior to the time of the event, a current location of a mobile device of a user based on the signals from the plurality of transmitters;
predict 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;
determine, 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;
generate the offer, the offer indicating 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 identifying, for each ticket in the set of tickets for the event, an assignment indicating whether the ticket has been assigned and an identifier of any user to whom the ticket is assigned;
present the offer to the user;
detect an acceptance of the offer from the user; and
change, in response to the detection of the acceptance, the assignment of the ticket in the ticket database.
16. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 15, wherein:
determining that the offer is to be presented comprises determining that the offer is to be presented to the user when the attendance predictor predicts that the user will not be able to attend the event;
the ticket is, prior to the acceptance, assigned to the user;
the offer is an offer to surrender the ticket; and
changing the assignment comprises removing the assignment.
17. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 16, wherein the one or more processors and one or more memories are further configured to:
generate a second offer;
present the second offer to a second user;
detect a second acceptance of the second offer from the second user; and
assign, in response to the detection of the second acceptance, the ticket to the second user in the ticket database.
18. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 16, wherein the detected acceptance of the offer is a conditioned acceptance, the acceptance being conditioned upon another user agreeing to purchase the ticket, and wherein the assignment is only changed upon occurrence of the another user agreeing to purchase the ticket.
19. (canceled)
20. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 15, wherein the one or more processors and one or more memories are further configured to:
query an account database for an account from amongst a plurality of accounts with the variable indicating that a respective user of the account is to serve as a back-up ticket holder for the event; and
identify the user based on the query,
wherein the offer is an offer to have a right to use the ticket, and
wherein changing the assignment of the ticket comprises assigning the ticket to the user.
21. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 1, wherein the attendance predictor predicts whether the user will be able to attend the event, at least in part by:
identifying a distance between the current location and the location of the event; or
estimating a commute time between the current location and the location of the event.
22. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 1, wherein the attendance predictor predicts whether the user will be able to attend the event at a defined time prior to the time of the event.
23. The method for estimating user locations and presenting location-sensitive ticket offers as recited in claim 8, wherein predicting whether the user will be able to attend the event includes:
identifying a distance between the current location and the location of the event; or
estimating a commute time between the current location and the location of the event.
24. The method for estimating user locations and presenting location-sensitive ticket offers as recited in claim 8, wherein the predicting whether the user will be able to attend the event occurs at a defined time prior to the time of the event
25. The ticket management system for estimating user locations and presenting location-sensitive ticket offers as recited in claim 15, wherein predicting whether the user will be able to attend the event includes:
identifying a distance between the current location and the location of the event; or
estimating a commute time between the current location and the location of the event.
US14/295,033 2005-04-27 2014-06-03 Location-based presentations of ticket opportunities Abandoned US20140379390A1 (en)

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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

Patent Citations (11)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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