SYSTEMS AND METHODS FOR RETURNING TICKETS FOR AN EVENT

专利摘要:
A method comprising: determining, based on a rights database storing rights allocation information, that a first right has been allocated to a first party; receiving by a server, from a client device controlled by a second party, a request that can be at least partially granted by reassigning the first party's first right to the second party; calculating by the server a probability that the request will be granted; providing the client device with an indication of the calculated probability; and registering, in a request database storing rights request information, a reference of the request.
公开号:BE1022651B1
申请号:E2014/5130
申请日:2014-12-19
公开日:2016-06-27
发明作者:Jean-Sébastien Gosuin
申请人:SMART SEATS IP besloten vennootschap met beperkte aansprakelijkheid；
IPC主号:

专利说明:

SYSTEMS AND METHODS FOR RETURNING TICKETS FOR AN EVENT
Technical domain
The present explanation relates to systems and methods for improving relations with fans and the sale of tickets. In particular, the present disclosure relates to systems and methods for managing relations with fans and for redistributing tickets for events, whereby redistributing allows fans to use tickets that might otherwise remain unused.
Background
As a rule, for events such as major sporting events, live music performances and other entertainment events, a ticket is required to enter and experience the event. Because for every event only a finite number of seats are available, it is possible that a fan will not be able to get attractive seats or blocks of seats. Empty seats during events, caused by ticket owners not showing up, can result in a loss of income for the organizers of the event and for the establishment where the event takes place in the form of missed concession sales and also dissatisfaction with sponsors, which can in turn lead to the revision or cancellation of sponsor contracts, since the sponsor's image is connected to the event. For example, it is undesirable that empty places appear on the screen of an event shown on television.
Ticket holders who do not show up can also create frustration for people who wanted to attend the event but did not succeed, for example because the event was sold out. People who fail to purchase a ticket for an event from the organizer or at the establishment of an event can resort to a secondary market for tickets for the event. However, those markets are quite inefficient, which is reflected in ticket prices that are higher than those originally offered by the organizer or the establishment of the event.
Brief summary
Using the systems and methods described here, unused tickets for sold-out events can be redistributed in real time to people who will use the tickets.
In some aspects, the explanation relates to a method of determining, based on a rights database in which information about the allocation of rights is stored, that a first right has been granted to a first party, and receiving an application that can be at least partially be granted by reassigning the first right of the first party to a second party. For example, in some embodiments, the request is received by a server from a client device controlled by the second party. The method then involves calculating, for example by the server, a probability that the request will be granted, and providing, for example to the client device, an indication of the calculated probability. In some embodiments, the method also includes registering, in a request database in which information about requesting rights, a reference of the request. For example, in some embodiments, the method includes adding, in response to receiving a request, an identifier for a second party to a queue, ie, at a position in the queue, and calculating the probability that the request will be granted , at least based on the position of the identifier in the queue (e.g., based on the number of other people in the queue before the second party).
In some embodiments, the method includes determining, after registering the request reference, that the first party has released the first right, and updating the rights database to reassign the first right of the first party to the second party . The method means that, in response to the successful updating of the rights database, the first party is informed that the first right has been revoked and the second party is informed that the first right has been assigned to the second party. In some embodiments, the method means that a ticket held by the first party is invalidated. In some embodiments, the method means that the second party is notified by ticket information being forwarded to a client device controlled by the second party.
In some embodiments, the method determines that the first party has released the first right based on receiving from the first party an express indication that the first party has released the first right. In some such embodiments, the first party may designate one or more possible other parties to receive the first right. In some embodiments, the method involves sending a request to the first party for confirmation that the first party will exercise the first right at a specified time, and it is determined that the first party has released the first right when the first party after the the first right has not yet been exercised after the specified time. The specific time can be, for example, the start time of an event, or a certain time after the start of the event. For example, without limitation, a few minutes after the event has started or when part of the event is over (for example, the end of a specific game period or turn of a sporting event). The specific time can be, for example, a time between opening the doors of the establishment where the event takes place and the start of the event. For example, without limitation, 15 minutes before the event starts.
In some aspects, the explanation relates to a system comprising at least one computer processor, one or more memory elements in which a rights database with rights-granting information is stored, and / or a request database in which rights-requesting information is stored, and a a computer-accessible memory in which instructions are stored which, upon execution by the computer processor, cause the computer processor to determine, on the basis of the database in which information about the allocation of rights is stored, that a first right has been assigned to a first party; to receive a request from a client device controlled by a second party that can be granted at least in part by reassigning the first right of the first party to the second party; to calculate a probability that the application will be granted; to provide an indication of the calculated probability to the client device; and to register a reference of the request in the request database. For example, in some embodiments, the instructions cause the processor (s), in response to receiving the request, to add a second party identifier to a queue, ie, at a position in the queue, and to increase the probability to calculate that the request will be granted, at least based on the position of the identifier in the queue (for example, on the basis of the number of other people in the queue before the second party).
In some embodiments, instructions are stored in the computer-accessible memory which, upon execution by the computer processor, cause the computer processor to determine, after registering the reference of the request, that the first party has released the first right, and to update the rights database to reassign the first right of the first party to the second party. In response to successfully updating the rights database, the system notifies the first party that the first right has been revoked, and informs the second party that the first right has been assigned to the second party. In some embodiments, the system declares a ticket held by the first party invalid. In some embodiments, the system notifies the second party by forwarding ticket information to a client device controlled by the second party.
In some embodiments, the system determines that the first party has released the first right on the basis of receiving from the first party an express indication that the first party has released the first right. In some such embodiments, the first party may designate one or more possible other parties to receive the first right. In some embodiments, instructions are stored in the computer-accessible memory which, upon execution by the computer processor, cause the computer processor to send a request to the first party for confirmation that the first party will exercise the first right at a specific time, and to determine that the first party has released the first right if the first party has not yet exercised the first right after the specified time. The specific time can be, for example, the start time of an event, or a certain time after the start of the event. For example, without limitation, a few minutes after the event has started or when part of the event is over (for example, the end of a specific game period or turn of a sporting event). The specific time can be, for example, a time between opening the doors of the establishment where the event takes place and the start of the event. For example, without limitation, 15 minutes before the event starts.
The details of various embodiments of the invention are set forth in the accompanying illustrations and the following description.
Brief description of the figures
The foregoing, as well as other objects, aspects, features and advantages of the explanation, will become clearer and more understandable by reading the following description, in combination with the accompanying illustrations, wherein: FIG. 1 is a block diagram showing an embodiment of a network environment in which the described systems and methods operate; FIG. 2 is a flow chart of an embodiment of a method for queuing a person looking for tickets to an event; FIG. 3 is a flow chart of an embodiment of a method for obtaining confirmation that the owner of a ticket will be present; FIG. 4 is a flow chart of an embodiment of a method for determining that a ticket owner will not be present and accepting a ticket reassignment; FIG. 5 is a timing diagram of exemplary interactions in an embodiment of a ticket reassignment method; FIG. 6A-6C are flow charts of an embodiment of a method for determining that a ticket owner will not be present and reassigning a ticket; FIG. 7A-7C are examples of views of a user interface for an exemplary embodiment; FIG. 8 is a block diagram of an exemplary computer system that may be used in some embodiments.
The features and examples of the present invention will become more apparent from the detailed description set forth below, in combination with the illustrations, wherein the same reference characters everywhere identify corresponding elements. In the illustrations, the same reference characters generally indicate identical, functionally corresponding, and / or structurally similar elements.
Detailed description
If we now look at FIG. 1 there is shown an embodiment of a network environment. Briefly summarized, the network environment comprises one or more client devices 102a-102n (generally client devices 102) that are in communication with one or more remote devices via a network 104. As shown in FIG. 1, remote devices may include a primary ticket market 106, a tertiary ticket market 108, and a Web server 110.
Although FIG. 1 shows a single network 104 between the client devices 102 and the remote devices 106, 108 and 110, the network can be formed by multiple connected networks 104. The network 104 can be a local area network, such as a corporate intranet, an urban network (Metropolitan Area Network, MAN), or a vast network (Wide Area Network, WAN), such as the internet. In some embodiments, the network 104 may include a private network. In some embodiments, the network 104 may include a public network. In some embodiments, the network 104 may include a private network and a network and a public network. The network 104 can be any type and / or form of network and can include any of the following: a point-to-point network, a broadcast network, an extended network, a local network, a telecommunications network, a data communication network , a computer network, an Asynchronous Transfer Mode network (ATM) network, a SONET (Synchronous Optical Network) network, an SDH (Synchronous Digital Hierarchy network) network, a wireless network, and a wired network. The network may include mobile device networks using any protocol or protocols used for communication between mobile devices, including AMPS, TDMA, CDMA, GSM, GPRS, LTE, or UMTS. The network 104 may exhibit any network topology known to those of ordinary skill in the art capable of supporting the operations described herein.
Although they are depicted as single devices in FIG. 1, each of the primary ticket market 106, the tertiary ticket market 108 and / or the web servers 110 may comprise multiple, logically grouped devices remotely. In one of these embodiments, the grouped devices can be geographically spaced apart. The remote devices within each group site may be heterogeneous, that is, one or more of the remote devices or devices may operate on one type of operating system (e.g., WINDOWS NT, produced by Microsoft Corp. in Redmond, Washington), while one or more more of the other devices can work remotely according to another type of operating system pattern (for example Unix or Linux). In some embodiments, the remote devices include a hypervisor or virtual machine layer. In some embodiments, the devices are remotely controlled by a third party cloud service provider.
In one embodiment, devices may be stored remotely in high-density rack systems, with associated storage systems, and located in a business data center. In this embodiment, bringing the remote devices together in this way can lead to an improvement of the manageability of the system, the security of data, the physical security of the system, and the performance of the system by remote devices and high performance storage systems to place on localized, high-performance networks. Centralizing the remote devices and storage systems and linking them to advanced management tools enables more efficient use of server resources.
Client devices 102 and remote devices can be deployed as and / or executed on any type and form of computer device, such as a computer, network device or device that is capable of communicating on any type or form of network and to perform the operations described here. Computer devices are described below with reference to FIG. 8, described in more detail.
A ticket can take many different forms and include various features, which are usually specified by the ticket seller and / or applicable local laws. In general, a ticket is a license, permit or contract that grants the owner of the ticket one or more rights. For example, without limitation, a ticket may include a right of access to an event, a right to use a certain seat during the event, and the right to attend an alternative event if the event is canceled (for example, a right to a 'credit ticket'). The rights may be structured in the form of a permit, a contract, a lease, or any other acceptable settlement. An event can be anything where entrance or access is limited, including, for example, concerts, plays, sports events, or any other event with a live audience (such as dance performances, theater, films, competitions, conferences, seminars, studio recordings, shows, etc.), or any other occasion for which tickets can be used. In some cases, the rights granted through possession of a valid ticket may include one or more of a right of access to an establishment where an event is taking place, a right to enter a controlled access area, a right to park a car to park a car park, a right to use one or more specified seats during a specified period of time, a right to obtain additional rights (for example a voucher), a right to receive an item, and / or a right to purchase a specified purchase to do. Similarly, a ticket can also be used to grant rights that are not specifically associated with an event. In some embodiments, a ticket may be a voucher representing, for example, a right to a future opportunity (for example, a right to purchase a limited edition product when it becomes available, or a right to purchase a ticket for a not yet or provisional programmed event). For example, a company may offer a limited edition item to the first N people who perform a particular act that makes them eligible; however, if a person who is eligible to receive the item is unable to receive the item (for example, by providing an invalid address) or chooses not to receive the item, someone who has the action to to be eligible after the first N people has performed, be eligible to receive it. In some embodiments, a ticket may represent a reservation, such as a reservation for a hotel room, a table in a restaurant, a seat of a means of transport (plane, train, bus, ferry, etc.) or a rental vehicle. For example, a person may want to get a last-minute reservation for a popular restaurant, which may become available if someone with a reservation does not show up. In that sense, the reservation was a retractable right to a table in the restaurant, which can be represented in the form of a ticket. In general, a ticket grants or represents a right to do or own something such as, without limitation, attending an event, buying something when it becomes available, or sitting at a table in a popular restaurant.
The rights granted by a ticket can be revocable. In some cases, a ticket can be withdrawn by invalidating a ticket. In such cases, the possession of an invalidated ticket generally does not grant the holder any rights. In some embodiments, a party whose ticket has been invalidated may receive a refund, a partial refund, a credit on a new ticket, or some other allowance.
In some embodiments, the ticket can be a physical ticket (with or without a separate strip). In some embodiments, the ticket may be an electronic document with ticket information displayed thereon that can be used to confirm the validity of the ticket. For example, without limitation, the electronic document can include one or more of a bar code, a QR code, a scannable image, a serial number, an encrypted string, or any other data element that can be displayed at the entrance of an establishment where the event takes place. In some embodiments, a ticket owner may have an electronic device (e.g., a mobile smartphone) in communication with a ticket server, e.g., through a direct wired connection, a radio connection (e.g., Bluetooth®), or near-field communication. Such an electronic device may provide ticket identification information to a suitable reader in communication with the ticket server, and the ticket server may then declare the ticket identification information valid. In some such embodiments, the device is an RFID chip that, when activated, provides the reader with an identifier. The ticket identification information, associated with the identifier, can be stored in a database such that the ticket server receives the identifier and then retrieves the associated ticket identification information from the database. In some such embodiments, the identifier issued by the activated RFID chip is encrypted, and the ticket server decrypts the identifier. A ticket, as the term is used in this document, can be any of the above-mentioned items or mechanisms for presenting ticket information, or any other suitable item or mechanism therefor. FIG. 2 shows a flow chart of one embodiment of the steps being taken to queue a person looking for tickets to an event. As can be seen in FIG. 2, a client device 102 sends a ticket request to a primary ticket market (step 202). The primary ticket market determines the availability of seats for the identified event (step 204) and sends a notification to the client device 102 (step 206) that the requested seats are not available, for example because the event is sold out, offering a mechanism for join a queue with a view to obtaining unused tickets. The mechanism is selected at the client device 102 (step 208) and a message is sent to the tertiary ticket market 108 (step 210). The tertiary ticket market creates a confirmation message (step 212) and transmits it to the client device 102 (step 214), where it can be displayed by the client device (step 216). The communication and transmission of messages in FIG. 2 can, for example, take place via a network 104.
Still with reference to FIG. 2, and in more detail, a client request 102 sends a ticket request to a primary ticket market (step 202). For embodiments in which the client device 102 is a mobile device, such as a mobile phone, smartphone or tablet, the request can be sent directly from a proprietary application, ie an application designed to function under control of the device's operating system (e.g., Android) , iOS, Windows Phone or Ubuntu Touch). In other embodiments, the request may be generated by the client device 102 as a result of a user's interaction with a web page displayed in a browser. For example, a webpage identifying an event may be shown to a user along with an active element that, when selected, sends a request to the primary ticket market 106.
In some embodiments, the request may include an identification of the event and the desired number of tickets. In other embodiments, the request may also include a date. In still other embodiments, the request may include a ticket category in which the user is interested, for example, the balcony chair, stalls, balcony, lodge, best available ticket, cheapest ticket, most expensive ticket, etc. In some embodiments, the request may be encrypted by the client device 102 before shipment to the primary ticket market 106.
Still with reference to FIG. 2, the primary ticket market determines the availability of seats for the identified event (step 204). In some cases, tickets for the event identified by the ticket application may be sold out. In some embodiments, the primary ticket market determines that an event is sold out by consulting a local database that stores data identifying available tickets for the event. In other embodiments, the primary ticket market 106 sends a request for available tickets corresponding to user-provided parameters to the establishment where the event is taking place or the organizer of the event, and receives a response to that question. For example, if an application specifies that a user is only interested in tickets for armchairs, the primary ticket market 106 may determine that the tickets for that application are sold out, even though balcony seats are available. In some embodiments, the user indicates a desired block or number of connecting seats, and the primary ticket market 106 can determine that the request cannot be granted with the available seats.
The primary ticket market 106 sends a response to the client device 102 (step 206) regarding the availability of tickets. If the primary ticket market 106 has determined that the tickets for the event are sold out, or that the desired tickets are not available, the primary ticket market 106 may include in its response a mechanism for entering a queue with a view to obtaining unused tickets tickets. For embodiments in which communication between the client device 102 and the primary ticket market 106 is conducted via the web, this mechanism may be in the form of an Active X control or a JAVA code that can be embedded in the response page. For embodiments in which the client device 102 uses a specific application program to communicate with the primary ticket market 106, the ticket market 106 may send a message to the application to display the mechanism to the user of the client device 102. The mechanism can be a button, a pop-up window, an embedded notification, a text message, or an e-mail message encouraging the user to join an unused ticket queue. In still other embodiments, the mechanism may be a redirect message that causes the client device 102 to access the tertiary ticket market directly without requiring any further action from the user of the client device 102.
The user of the client device 102 can select the mechanism. If the mechanism is a button that is displayed in a web page, the user can simply click on the button. If the mechanism is a pop-up window, the user can provide any information requested by the pop-up window before sending. The pop-up window may, for example, request the user's address information or credit card information. A text message or e-mail message may require a specific answer for the user to continue.
The tertiary ticket market 106 receives an indication that the mechanism has been selected (step 212). In some embodiments, the tertiary ticket market 106 adds the user to a queue. In some embodiments, a single queue is used for the event. In other embodiments, a separate queue is used for each ticket category. For embodiments where multiple queues are used, the tertiary ticket market may add the user to all queues when the user has selected "best available ticket" or a similar ticket category.
The tertiary ticket market creates a confirmation message and sends it to the client device 102 (step 214), whereafter this confirmation message is displayed by the client device 102 (step 216). In some embodiments, the confirmation message includes an indication of how likely it is that the user will be selected to receive an unused ticket. In some of these embodiments, this indication is indicated by a color. For example, in some embodiments, green means "very likely", yellow "not sure" and red "unlikely."
The indication to be displayed to a user can be determined with the aid of a number of algorithms. In one embodiment, presence data for the past establishment is used as an aid to identify whether it is likely that a user placed in the queue will receive a ticket. For example, if an establishment accommodates 12,000 people and had an absence rate of 4% in the past, it is logical to assume that the number of absences for an event could be 4% of 12,000, which is 480. In this example, the first people to join the queue can get a "likely" message (for example, up to 300 people), the following people can get a "not sure" message (for example, up to the remaining 180 of the predicted 480 tickets that become available due to absences) and later users may receive an 'unlikely' message. In some embodiments, the percentages other than the 5 / 8th "probable" and the 3 / 8th "not sure" used in this example.
In some embodiments, users who have purchased tickets for an event may be asked to confirm their intention to attend the event. In some such embodiments, at a time prior to the event (e.g., a few hours before the event starts), users receive a message asking for confirmation. In some such embodiments, users confirm their intention without question. Users can be offered an incentive to confirm their intention to attend the event. For example, a user who confirms can receive a discount for a future event, vouchers for use during the event (for example, at concessions), or points in a loyalty reward system. In some embodiments, a user who fails to confirm his intention to attend an event runs the risk that his ticket will be canceled and given to another party. In some embodiments, a user who confirms his intention to be present but is not present is punished. For example, a user may be charged a non-show-up fine, or the user may lose points in a loyalty reward system. In some embodiments, a non-show-up fine is included in the original ticket purchase price; that is, a user may receive a refund of a portion of the ticket price when that user enters the establishment where the event is taking place. FIG. 3 shows a flow chart of the steps taken in one embodiment for indicating by a user that he intends to use his ticket for an event. As can be seen in FIG. 3, and in summary, a user uses a client device 102 to identify a ticket (step 302). The user also identifies himself or proves his identity (step 304). Using the client device 102, the user indicates that he intends to attend the event, and a message announcing that intention is sent to the tertiary ticket market 108 (step 306). The message is received by the tertiary ticket market (step 322) and the tertiary ticket market 108 stores the ticket identifier and status (e.g., "I am sure") in a database reference associated with the event (step 340). The communication and sending of messages in FIG. 3 can, for example, take place via a network 104.
Still with reference to FIG. 3, and in more detail, a client device 102 is used to identify a ticket (step 302) and to identify itself (step 304). These events can take place in any order. For embodiments in which the client device 102 is a mobile device, such as a mobile phone, smartphone or tablet, the user may use a proprietary application, ie an application designed to function under the control of the device's operating system (e.g., Android, iOS, Windows Phone or Ubuntu Touch). In other embodiments, the identification may take place via interaction by a user with a web page displayed in a browser. For example, a user can open a webpage where the user logs in (or is logged in automatically, for example, using cookies) in a user account for a ticket management service. The ticket management service then provides the user (or rather the web browser of the user's client device) a web page with a list of upcoming events for which the user has purchased tickets. The user selects an event. For example, the user can select an active element such as a check box or a button. In some embodiments, the user identifies a ticket using an image of the ticket. For example, a client device 102 may be provided with a camera, and the user may take a photo of a physical ticket. The ticket may include a visual identifier such as a bar code or a QR code. In some embodiments, the user identifies multiple tickets. In some embodiments, the multiple tickets have a ticket group identity. For example, the tickets may have been sold as a block. In some embodiments, the user only identifies a subset of tickets sold in a block of tickets. For example, a user may have purchased four tickets for an event, but intend to use only two. In some embodiments, the user provides identification information for the tickets to a ticket management service, and the ticket management service then asks the user to confirm that he is the purchaser of these tickets, for example by a purchase account password, the latest digits of a credit card used to purchase the tickets, or to provide the answer to an identity confirmation question.
Still with reference to FIG. 3, and in more detail, a client device 102 is used to send an intention to attend an event (step 306). The client device 102 generates an "I come" message and sends this message to a ticket management service, for example at the tertiary ticket market 108. In some embodiments, the "I come" message comprises an identifier for the ticket (s) identified in step 302 ). In some embodiments, the "I come" message includes an identifier for the user identified in step 304. In some embodiments, a user may generate and send the "I come" message at any time prior to the event. In some embodiments, a user can only send the "I come" message within a specific time frame, for example, during the week just before the event. In some embodiments, a user may not send the "I come" message later than a time before the event (for example, 30 minutes before the event starts). In some embodiments, a ticket that has not been confirmed can be canceled and reissued. In some of these embodiments, a user who sends the "I am coming" message after the ticket has been canceled and issued to another party is placed in a priority queue for receiving replacement tickets. In some embodiments, a user who sends the "I am" message after the ticket has been canceled receives a notification that the ticket has been canceled due to non-check-in.
Still with reference to FIG. 3, and in more detail, the "I come" message is received by the tertiary ticket market (step 322) and the tertiary ticket market 108 stores the identifier and status (e.g., "I am sure") of the ticket in a event associated database reference (step 340). In some embodiments, the database reference is used to prevent the identified ticket (s) from being canceled. The database reference can be stored in a database (or any other data file). The database can be copied. In some embodiments, a copy of the database is stored at the establishment. In some embodiments, a copy of the database is retained by an entrance administrator for use in admitting event visitors to the event location. FIG. 4 shows a flow chart of the steps taken in one embodiment for indicating by a user that the user will not be present and that the user wishes to transfer his or her ticket (or tickets) to a friend. As can be seen in FIG. 4, and in summary, a user uses a client device 102 to identify a ticket (step 402) and to identify himself or prove his identity (step 404). Using the client device 102, the user indicates that he does not intend to attend the event, and a message stating that intention is sent to the tertiary ticket market 108 (step 408). The tertiary ticket market 108 receives the message (step 412) and identifies a list of social contacts for the user (step 414). The tertiary ticket market 108 sends the list to the client device 102 (step 416). The client device 102 receives the list and presents an interface to the user for selecting the person to whom the ticket is to be transferred (step 422). The client device may receive a selection from an individual from the list as the ticket recipient (step 424). The tertiary ticket market 108 receives the identification message (step 432) and stores the identification of the person, together with the ticket identifier, in a database reference associated with the event (step 440). The communication and sending of messages in FIG. 4 can, for example, take place via a network 104.
Still with reference to FIG. 4, and in more detail, a client device 102 is used to identify a ticket (step 402) and to identify itself (step 404). These events can take place in any order. These events are equivalent to the above with reference to FIG. 3, steps 302 and 304 described.
Still with reference to FIG. 4, a user device 102 is used by a user to send an intention not to attend an event (step 408). The client device 102 generates an "I am not coming" message and sends this message to a ticket management service, for example at the tertiary ticket market 108. In some embodiments, the "I am not coming" message comprises an identifier for the ticket identified in step 402 (s). In some embodiments, the "I am not coming" message includes an identifier for the user identified in step 404. In some embodiments, a user may generate and send the "I am not coming" message at any time prior to the event. In some embodiments, a user can only send the "I am not coming" message within a specific time frame, for example, during the week just before the event. In some embodiments, a user may send the "I come" message within the same time frame that also applies to sending an "I come" message, as described above with reference to FIG. 3.
Still with reference to FIG. 4, the "I am not coming" message is received by the tertiary ticket market (step 412) and the tertiary ticket market 108 proceeds to redistribute the ticket (s) identified by the "I am not coming" message. In some embodiments, the tickets are canceled and new tickets are issued to other users waiting in a queue. In some embodiments, as shown in FIG. 4, the tertiary ticket market 108 offers the original buyer the option to transfer the tickets to a friend.
Still with reference to FIG. 4, the tertiary ticket market identifies a list of social contacts for the user (step 414). In some embodiments, the user has an account at the tertiary market and the account is linked to one or more other accounts, thereby forming a social network of friends to whom the user could transfer tickets. In some embodiments, the tertiary market consults connection data provided by an external social networking platform (e.g., Facebook "friends", Linkedln "contacts" or Google + - "circles"). Many social networking platforms offer a program application interface (API) for obtaining connection data for a user. In some embodiments, the tertiary market consults connection data provided by an e-mail provider. Many email providers offer an API to consult a user's contact list. In some embodiments, the tertiary ticket market forms a selection list of the user's connections, the selection list being a subset of all possible connections. Connections can be selected for inclusion in the selection list based on one or more priority factors, and / or randomly. For example, the tertiary ticket market can present a user with ten initial options and an option for more suggestions. The ten initial options may include people to whom the user has previously transferred tickets, people with whom the user is associated in multiple social networking platforms, people with whom the user interacts most frequently, and / or people who are also users of the tertiary ticket market and who occur in the user's social connections or email contacts.
The tertiary ticket market 108 then sends the list (or a portion of the list) to the client device 102 (step 416). In some embodiments, the list is sent to a customized application that is executed by the client device 102. In some embodiments, the list is formatted as a web page and sent to a web browser. In some embodiments, only a portion of the list is sent, for example, a selection list. In some such embodiments, the user may request the sending of an additional list. In some embodiments, the user can indicate how many friends are to be proposed. In some embodiments, the list is empty. For example, in some embodiments, the list represents single friends to whom the user has previously transferred tickets, and / or from whom the user has previously received tickets. Initially, a user who has never participated in a ticket transfer (for example a new user) would have an empty friend list.
Still with reference to FIG. 4, the list is received by the client device 102 and provides the user with an interface to select to whom the ticket is to be transferred (step 422). In some embodiments, the list is sent to a customized application that is executed by the client device 102. In some embodiments, the interface includes an option for the user to specify a person who is not in the list. For example, the user can enter an email address or telephone number of a person. In some embodiments, after receiving an e-mail address or telephone number from a person not known to the tertiary market, the tertiary market contacts that person and invites that person to join the market. The tertiary ticket market can, for example, generate an email with a link to a web page or application store, generate a text message, or generate an automated telephone call.
Still with reference to FIG. 4, the client device receives a selection from an individual from the list as a receiver for transferring the user's ticket (s) (step 424). In some embodiments, the selection is made in response to the submission of the list in step 422. In some embodiments, the user may select the recipient by interacting with a friend list displayed by the client device 102. For example, in some embodiments, a user selects a button or check box associated with the intended recipient. In some embodiments, a user enters the number of tickets to be transferred. In some embodiments, each ticket in a group of tickets is transferred independently. In some embodiments, all tickets in a group of tickets are transferred as a block.
Still with reference to FIG. 4, the identification of the selected receiver is sent from the client device 102 back to the tertiary ticket market 108 (step 426). The tertiary ticket market 108 receives the identification message (step 432) and processes the selection. In some embodiments, the tertiary ticket market 108 generates a message to the identified recipients to accept or reject the transfer. In some embodiments, when the identified recipients are already waiting in a queue for the event, the tickets are transferred without waiting for the recipient to agree to the transfer. In some embodiments, when the identified recipients do not have an account with the ticket management service, the service invites the identified recipients to create an account.
Once the transfer has been determined, the tertiary ticket market 108 stores the identification of the new receiver together with the ticket identifier in a database reference associated with the event (step 440). In some embodiments, the database reference is used to prevent the identified ticket (s) from being canceled. The database reference can be stored in a database (or any other data file). The database can be copied. In some embodiments, a copy of the database is stored at the establishment. In some embodiments, a copy of the database is retained by an entrance administrator for use in admitting event visitors to the event location. In some embodiments, once the tickets have been transferred, the ticket manager sends a message to the recipient asking for confirmation of an intention to be present. FIG. 5 is a timing diagram of exemplary interactions in an embodiment of a ticket reassignment method. Broadly summarized, the timing diagram 500 shows a sequence of events that starts at the top and progresses downwards through time. Five participants are shown in the timing diagram 500: a first buyer 502, a second buyer 504, a ticket seller 505, a queue manager 507 and an event entry service 509. These participants are involved in a series of events: a first purchase interaction 520, a second purchase interaction 530, a queue interaction 540, a cancellation action 550, a ticket revocation 560, a tickether issue action 570 and an entrance action 580.
With reference to FIG. 5, in more detail, a first buyer 502 enters into a first purchase interaction 520 with a ticket seller 505. In some embodiments, the first buyer 502 is a user of a client device 102. In some embodiments, the ticket seller 505 is an official ticket dealer for an event . For example, the ticket seller 505 may be the ticket office of the establishment where the event takes place. If tickets are available for an event that meets the demand of the first buyer 520, the ticket seller issues 505 tickets to the first buyer 502.
In some embodiments, physical tickets are provided (e.g., sent by mail) to the first buyer 502. In some embodiments, virtual tickets are issued. In some embodiments, a virtual ticket is a serial number or identifier of a ticket, possibly provided to the user in a graphical form, for example as a bar code or QR code. In some embodiments, nothing is provided to the first buyer. The first buyer can, for example, have an account and the ticket can be issued to the account in such a way that the buyer only needs to show proof of identity to gain access to the event. In some embodiments, an identification issued by the government is used as identification. In some embodiments, a bank card or credit card (e.g., a card used for the purchase) is used as proof of identity. In some embodiments, a customized identification is used as proof of identity, for example a card with an RFID chip on it issued by the establishment. Regardless of the form of delivery, when the first buyer 502 buys a ticket for an event (at interaction 520), the first buyer has an ownership interest in a right to attend the event.
In some embodiments, when a buyer buys a ticket for an event, the buyer is invited (by the ticket seller) to register the ticket with a ticket manager. In some embodiments, there is an incentive to register the ticket with the ticket manager. In some embodiments, all tickets issued by ticket seller 505 must be registered with the ticket manager. In some embodiments, the buyer 502 may register the ticket with the ticket manager without prompting by the ticket seller 505.
With reference to FIG. 5, in more detail, a second buyer 504 enters into a first purchase interaction 520 with a ticket seller 505. In some embodiments, the second buyer 504 is a user of a client device 102. As can be seen in FIG. 5, the second buyer 504 fails to purchase a ticket. For example, the event may be sold out, or tickets may not be available in the number requested by the buyer 504 or the location requested by the buyer 504. The second buyer 504 is therefore unable to purchase a ticket. However, it is possible that the second buyer 504 may be interested in tickets sold to the first buyer 502. The second buyer 504 is offered the option to join a queue.
The second buyer 504 interacts with a queue manager 507. In some embodiments, the queue manager 507 is the tertiary market 108 described above. In some embodiments, the queue manager 507 is controlled by a party other than the ticket seller 505. During the interaction 540, the queue manager 507 may provide the second buyer 504 with an indication of the buyer's place in the queue. In some embodiments, the queue manager 507 gives the second buyer 504 a prediction of how likely the second buyer will receive tickets. In some embodiments, during the interaction 540 with the queue manager 507, the second buyer provides bank or credit card data and the queue manager 507 places a credit block for the purchase price of a ticket. The blocking facilitates a quick payment in the event of a ticket transfer. In some embodiments, the second buyer is only asked to provide bank or credit card information if the location of the second buyer in the queue is above a probability threshold for obtaining a ticket.
With reference to FIG. 5, in more detail, the first buyer 502 later indicates that he will not attend the event. The queue manager 507 determines in interaction 550 that the first buyer 502 will not attend the event and releases the tickets belonging to the first buyer 502 (which were purchased during interaction 520, for example). The released tickets can then be redistributed to the next interested party in the queue, for example the second buyer 504. In some embodiments, the queue manager 507 determines that the first buyer 502 will not attend the event because the first buyer 502 will not attend message, for example as described above with reference to FIG. 4. In some embodiments, the queue manager 507 determines that the first buyer 502 will not attend the event because the first buyer 502 has not confirmed an intention to come with an "I come" message, e.g. as described above with reference to FIG. 3. In some embodiments, the queue manager 507 determines that the first buyer 502 will not attend the event because the first buyer 502 has not entered the establishment where the event is taking place at a time relative to the start time of the event. In some embodiments, queued buyers with a high probability of getting tickets are encouraged to stay at a location in the vicinity of the establishment.
With reference to FIG. 5 then the queue manager 507 cancels the tickets sold to the first buyer 502, and the event entry service 509 is notified that access may not be granted with the withdrawn tickets (interaction 560). In some embodiments, the event entry service operates on the basis of an authorized ticket database. This database can be provided by the ticket seller 505. In some embodiments, the event entry service is the same entity as the ticket seller 505. In some embodiments, the event entry service is a third party that is not directly associated with the establishment (e.g., Ticketmaster does not benefit) the rooms for which it sells tickets). In some embodiments, the event entry service 509 shares the database with the queue manager 507 and the queue manager 507 can change the database directly. When the queue manager 507 cancels or releases tickets sold to the first buyer 502, the queue manager 507 interacts with the event entry service to ensure that the withdrawn tickets cannot be used to enter the establishment. The seats associated with the withdrawn tickets are again associated with a new ticket (or ticket serial number) and the new ticket can then be distributed to a new ticket recipient.
The second buyer 504 is notified in interaction 570 by the queue manager 507 that the second buyer 504 is eligible to receive, or has received, event tickets. In some embodiments, the second buyer 504 must confirm the transfer. For example, it is possible that the second buyer 504 is no longer in the ability to be present or cannot reach the establishment in time. In some embodiments, the second buyer 504 agrees to receive the tickets in advance such that the transfer can be fully automatic and (during the interaction 570) the queue manager 507 simply notifies the second buyer 504 of the fact that the tickets have been transferred. In some embodiments, buyers in the queue with a high probability of getting tickets are encouraged to go to a secondary establishment. In some embodiments, the secondary establishment has televisions or projection screens on which the event is screened. In some embodiments, people in the queue who are in a secondary establishment are checked in at the secondary establishment to confirm that they are available to quickly leave the secondary establishment and to enter the main establishment if they manage to get tickets . In some embodiments, checking in at the secondary establishment increases the chance of getting tickets. For example, the check-in event can be used to improve the position of the buyers in the queue, or to transfer them to a priority queue.
The second buyer 504 then attempts to enter the establishment with the transferred ticket (interaction 580). The second buyer 504 displays a ticket (e.g., a bar code or QR code displayed on a smartphone or other client device, or an identity document as described above) to the event entry service 509. The event entry service 509 grants access based on the displayed ticket if the ticket corresponds to the re-issued ticket agreed with the queue manager 507. FIG. 6A-6C are flow charts of an embodiment of a method for determining that a ticket owner will not be present and reassigning a ticket. In method 602, illustrated in FIG. 6A, a ticket seller receives a request to obtain a ticket for an event (step 620). The ticket seller determines whether tickets are available to grant the request (step 630). If tickets are available, the ticket seller issues the requested tickets (step 634). If no tickets are available, the ticket seller offers to queue the party looking for tickets (step 636).
With reference to FIG. 6A, in more detail, a ticket vendor receives a request to obtain a ticket for an event (step 620). If a cost is attached to the ticket, the request to obtain the ticket can be a request to purchase the ticket. The ticket seller may be associated with the establishment where the event is taking place, may be associated with a ticket queue manager, or may be an unassociated third party. The received request identifies an event. The request received by the ticket seller can indicate a desired number of seats, a desired location within the establishment, and / or a desired price range. In some embodiments, the request includes an identifier for a user submitting the request. In some embodiments, the ticket seller determines whether the user is registered with the ticket queue manager.
The ticket seller determines whether tickets are available to grant the request (step 630). The event may be sold out, with no tickets available. The available tickets may be in a blocked state, for example when they are reserved for VIPs but have not actually been purchased. Tickets can be held in a blocked state for a variety of reasons, including, for example, if tickets are reserved for guests of the artists or players, tickets that are provided to sponsors for redistribution by other means, or tickets that are withheld to account for problems at the last minute. It is also possible that available tickets do not meet the request. For example, it can be a request for four consecutive tickets, and no four adjacent seats can be available for the event. In some embodiments, seats may be offered in close proximity to, but not exactly adjacent to, each other to accommodate a request for adjacent seats. For example, two seats in a first row that are located behind two seats in a second row may be appropriate to accommodate adjacent seats. Alternatively, the request may be a request for tickets in a specific part of the establishment - no tickets may be available in the requested part, even though the event itself is not sold out.
If tickets are available, the ticket seller issues the requested tickets (step 634). In some embodiments, a serial number and / or a ticket group number is assigned to the tickets. The ticket series numbers (or the ticket group number) are then registered in a database reference for sold tickets (or assigned tickets), associated with the event and the seats. In some embodiments, the database reference includes information by which the party acquiring the tickets (e.g., the ticket buyer) is identified, or the tickets are associated with this party in some other way, e.g. via the buyer's account with the ticket queue manager. In some embodiments, the ticket seller advises or requests that the party receiving the tickets register the seats with the ticket with the ticket queue manager, for example, in the event that this party is later unable to attend the event. In some embodiments, the party receiving the tickets is required to register the tickets with the ticket queue manager.
If no tickets are available, the ticket seller offers to queue the party looking for the tickets (step 636). If the party looking for the tickets has an account with the ticket queue manager, the party can be transferred to the ticket queue manager and immediately redirected to a queue entry interface. If the party looking for the tickets does not have an account with the ticket queue manager, the party can be referred to an account creation interface at the ticket queue manager.
In method 604, illustrated in FIG. 6B, a queue manager requests that a ticket owner confirms an intention to attend an event (step 640). Either the queue manager then receives confirmation (step 644) or determines that the owner of the ticket will not be present (step 646). If the owner of the ticket will not be present, the queue manager issues the ticket again to a second party, for example from the queue (step 658). In method 606, illustrated in FIG. 6C, an establishment's ticket inspector determines that a ticket owner is not present (step 660) and again issues the ticket to a second party, e.g. from the queue (step 668).
With reference to FIG. 6B, in more detail, a ticket owner is requested by a queue manager to confirm an intention to attend an event (step 640). The owner of the ticket has tickets for the event that have been registered in advance, and in step 640 the ticket queue manager checks whether the owner still intends to attend the event. In some embodiments, the queue manager sends the request via one or more of e-mail, SMS, automated telephone call, or via a notification system of a customized application.
Either the queue manager then receives confirmation (step 644) or determines that the owner of the ticket will not be present (step 646). In some embodiments, the queue manager receives confirmation via a reply message from the ticket owner, for example the "I come" message described above. In some embodiments, the queue manager receives confirmation from the establishment or from an access entry authority at the establishment when the owner of the ticket enters the establishment. If the queue manager does not receive confirmation, it is likely that the owner of the ticket will not be present. In some embodiments, the ticket queue manager determines that the owner of the ticket will not be present (step 646) by receiving an "I am not coming" message as described above. In some embodiments, the ticket queue manager determines that the owner of the ticket will not be present (step 646) due to lack of action from the owner of the ticket after one or more attempts to obtain information. In some embodiments, it is assumed that a tacit owner of a ticket "does not arrive" after a deadline has elapsed, for example, briefly (e.g., 15 to 30 minutes) before or after the start of an event.
If the owner of the ticket will not be present, the queue manager issues the ticket again to a second party, for example from the queue (step 658). In some embodiments, the original ticket is canceled and a new ticket is issued to the party selected from the queue. For example, a ticket can be canceled by invalidating the serial number of the ticket at the access authority of the establishment such that the ticket cannot be used to access the event. For example, a new ticket can be issued by generating a new serial number, updating the access authority of the establishment to allow access for a ticket associated with the new serial number, and issuing a ticket with the serial number. The ticket can be issued by printing a physical ticket with a bar code or QR code with the serial number. The ticket can be issued by e-mailing (or otherwise sending) an electronic version of the ticket to the recipient, to be printed or displayed on an electronic device.
In method 606, illustrated in FIG. 6C, an establishment's ticket inspector determines that a ticket owner is not present (step 660) and again issues the ticket to a second party, e.g. from the queue (step 668). In some embodiments, if a ticket holder does not show up for an event and fails to request that his or her ticket be kept for late arrival, the ticket may be canceled and the seat released for use by another party. In some embodiments, after a certain period of time after the doors of the establishment have been opened to allow ticket holders, or after the event has started, the queue manager obtains a list of tickets that have not been used to access. The queue manager can, for example, consult the database of the access authority of the establishment, or a copy of the database. The unused tickets can be canceled (or, alternatively, be marked as used without permission to regain access). New tickets can be generated for unused seats and (in step 668) issued to people waiting in the queue. In some embodiments, people are removed from the queue in a sequence determined by additional factors such as VIP status, loyalty bonuses, willingness to pay more, or presence in a secondary establishment in the immediate vicinity of the primary primary establishment.
In some embodiments, the owner of a ticket may choose to release one or more tickets for redistribution. In some such embodiments, the owner of the ticket may designate one or more people to be given priority for receiving tickets. For example, the owner of the ticket may want to give clients, customers, friends or family members the opportunity to take over or buy the tickets before they are released to other people. In some embodiments, the owner of a ticket only releases the ticket if it is distributed to someone designated by the owner of the ticket as the recipient. The identified people receive a message inviting them to receive or purchase the ticket. In some embodiments, the message is an electronic message that is sent via e-mail, text message, a notification in an application, or an automated telephone call. The recipients of the message do not have to be in the queue. If none of the identified people responds within a threshold time period, the ticket is released for the queue. In some cases, for example when the event is not sold out or when all ticket requests are granted, there is no queue. In such cases, the owner of a ticket may not have the option to release the ticket, or the ticket may be released for distribution in response to a future request. If the ticket is sold, the owner of the ticket can receive a proceeds from the sale, the proceeds being a partial refund of the original ticket price paid by the owner, a full refund of the original ticket price, or more than the original ticket price can be. The owner of the ticket can receive the full proceeds from the resale or part of the proceeds.
In some embodiments, a ticket owner may have rights that can be subdivided into individual tickets. For example, a ticket owner may have a season ticket that gives access to multiple events over several days (for example, season tickets for a sports team, season tickets for the theater, tickets for each day of a multi-day conference, or a season pass for a ski lift). The owner of the ticket can release part of the rights covered by the season ticket, for example tickets for one match played by the sports team, tickets for one screening in the theater, tickets for one day of the congress, or lift tickets for one weekend of the ski season. New tickets that represent the released part of the season ticket are then available for distribution. In some embodiments, the owner of a ticket may designate one or more people to be given priority for receiving the tickets. For example, the owner of the ticket may wish to give clients, customers, friends or family members the opportunity to purchase the. take over or buy tickets before they are released to other people. In some embodiments, the owner of a ticket only releases the ticket if it is distributed to someone designated by the owner of the ticket as the recipient. The identified people receive a message inviting them to receive or purchase the ticket. In some embodiments, the message is an electronic message that is sent via e-mail, text message, a notification in an application, or an automated telephone call. The recipients of the message do not have to be in the queue. If none of the identified people responds within a threshold time period, the ticket is released for the queue. In some cases, for example when the event is not sold out or when all ticket requests are granted, there is no queue. In such cases, the owner of a ticket may not have the option to release the ticket, or the ticket may be released for distribution in response to a future request. If the ticket is sold, the owner of the ticket can receive all or part of the proceeds from the sale. In some embodiments, the owner of a seasonal ticket may have received a discount when purchasing the ticket, but the original seller may require that each resale take place at a higher, non-discounted price, with the seller receiving the difference. In some embodiments, the owner of a seasonal ticket makes one or more tickets available to a private list of people, with only people in the private list having the option of taking over the tickets. The owner of the season ticket can then view the status of each ticket to see if it has been taken over by someone on the list. For example, the owner of the ticket can have a collection of tickets for a multi-day event and offer them to a private list of partners, friends or family members. The owner of the ticket can then see how many of the tickets in the collection have been accepted by people in the private list.
In some embodiments, a season ticket holder sells one or more tickets that are part of a season ticket package. The owner of the ticket uses a user device to connect to server of a tertiary ticket market and identifies for the server one or more tickets for resale belonging to the seasonal ticket. For example, the server may present an interface showing a list of tickets held by the season ticket holder (e.g., a list of dates and seats of events included in the season ticket), and the ticket owner then selects specific tickets from the displayed list using the control elements of the interface. In some embodiments, the holder also identifies an account with an external financial institution for receiving any proceeds (e.g., a credit card or bank account, etc.). The owner of the ticket can check and confirm the selected tickets and account information, and any other configurations. In some versions, the ticket owner also reads and confirms applicable terms and conditions. After confirmation, the indicated tickets are made available for redistribution, for example to waiting people in a queue.
In some embodiments, a season ticket holder offers one or more tickets that are part of a season ticket package to a specific group of people, e.g., partners, friends, or family members. The owner of the ticket uses a user device to connect to the server of a tertiary ticket market and identifies for the server one or more tickets for resale that are part of the seasonal ticket. For example, the server may present an interface showing a list of tickets held by the season ticket holder (e.g., a list of dates and seats of events included in the season ticket), and the ticket owner then selects specific tickets from the displayed list using the control elements of the interface. In some embodiments, the holder also identifies an account with an external financial institution for receiving any proceeds (e.g., a credit card or bank account, etc.). The owner of the ticket selects or identifies a group of people who are eligible to receive the tickets. In some embodiments, the ticket owner provides contact information (e.g., an email address or mobile phone number) for each eligible person. The server creates a hidden list or private list that the identified people can join. The server creates a uniform resource locator (URL) for the private list and sends it to the identified people with an invitation to join the queue and access the tickets. The invitation includes the URL. The invitation is sent, for example, via e-mail, via text message (to the mobile telephone number) or via a customized application. In some embodiments, anyone with the URL can join the private queue. In such embodiments, people who receive the invitation can forward it to other friends or share the URL via social media. The owner of the ticket can check and confirm the selected tickets and account information, and any other configurations. In some versions, the ticket owner also reads and confirms applicable terms and conditions. After confirmation, the indicated tickets are made available for redistribution via the private queue. In some embodiments, the ticket owner may later delete a ticket that has been made available if no one has claimed it. FIG. 7A-7C are examples of representations of a user interface for an exemplary embodiment. FIG. 7A illustrates an exemplary client device 102 on which a ticket 702 is displayed for an event that is sold out. An interface is presented to the user of the client device 102 offering the option 710 to join the queue. In some embodiments, the user may need multiple tickets, and the illustrated interface provides a field 716 for entering the desired number of tickets. FIG. 7B illustrates an exemplary client device 102 on which a ticket 702 is displayed for an event and confirmation is requested that a buyer will attend the event. For example, the user can select the "will be present" option 730 to indicate that he / she intends to come to the event. For example, the user can select the 'will be late' option 734 to indicate that he / she intends to come to the event but does not expect to be there by the time the event starts (or a preferred arrival time, for example 15 minutes before the event starts). In some embodiments, selecting option 730 "will be present" or option 734 "will be late" generates an "I come" message as described above. For example, the user can select the option 736 for "will not be present." Selecting this option may result in a cancellation of the user's tickets. In some embodiments, as described above with reference to FIG. 4, the user can be given the option to transfer the tickets to a friend. FIG. 7A illustrates an exemplary client device 102 on which is displayed a menu for selecting a friend 740 for receiving the displayed ticket 720. The user may select a check box or radio button 744 to select the receiver. If the user has multiple tickets for the event, the user can select a number of tickets to be transferred 746. The data shown in FIG. 7A-7C are preview views. Other interfaces fall within the scope of this explanation. FIG. 8 is a block diagram of a computer system 810 suitable for executing the computer-realizable components described herein. The elements of a computer system typically include a processor for performing actions in accordance with instructions, and one or more memory devices for storing instructions and data. The illustrative computer system 800 includes one or more processors 850 that are in communication with one or more network interface controllers 920 via a bus 815 (e.g., for communicating with an external network device 824 via a network interface 822), optional I / O interfaces 930 (e.g., for entering into interaction with a user or manager), and memory 870. Typically, a processor 850 receives instructions and data from a permanent memory (read-only memory) or a freely accessible memory (random-access memory) or both. The illustrated processor 850 includes or is directly connected to additional cache memory 875. In some applications, additional other components 880 are in communication with the computer system 810, e.g., external devices connected via a universal serial bus (USB). In some applications, the I / O interface 830 supports an input device and / or an output device (not shown). In some applications, the input device and the output device are integrated in the same hardware, for example, in a touch screen.
In some applications, the ones shown in FIG. 1 illustrated client devices 102 similarly constructed as the computer system 810 of FIG. 8. For example, a user interacts with an input device such as I / O interface 830, e.g., a keyboard, mouse, or touch screen, on a client device 102 to access an interface, e.g., a web page, via the network 104. The interaction is received at the network interface 822 of the client device, and responses are performed via an output device such as 1 / O interface 830, for example, a display, display, touch screen, or speakers for display to the user.
In some applications, one or more of the ones shown in FIG. 1 illustrated servers and markets constructed in a similar manner to the computer system 810 of FIG. 8. In some embodiments, a server may be comprised of multiple computer systems 810. In some embodiments, a server may be a virtual server, for example, a cloud server. A server can be composed of multiple computer systems 810 that share a location or that are distributed across multiple locations. The multiple computer systems 810 that form a server may be in communication via the network 104 accessible to a user (which may include multiple network devices 824).
The processor 850 may be any logic circuit that processes instructions, for example, instructions retrieved from the memory 870 or cache 875. In many embodiments, the processor 850 is a microprocessor unit, such as the models manufactured by Intel Corporation in Mountain View. California; the models manufactured by Motorola Corporation in Schaumburg, Illinois; the models manufactured by Transmeta Corporation in Santa Clara, California; the RS / 6000 processor, the models manufactured by International Business Machines in White Plains, New York; or the models manufactured by Advanced Micro Devices in Sunnyvale, California. The computer device 810 may be based on any of these processors, or any other processor that is capable of functioning as described herein. The processor 850 can be a processor with one core or with multiple cores. The processor 850 can be multiple processors.
Additional interfaces 880 allow connection of additional peripheral equipment to the computer system 810. The peripheral devices can be physically connected, for example via FireWire or Universal Serial Bus (USB), or wirelessly, for example via Bluetooth. Examples of peripherals are keyboards, pointing devices, display devices, braille devices, audio devices, hubs, printers, media reading devices, storage devices, hardware accelerators, sound processors, graphic processors, antennas, signal receivers, sensors, measuring devices, and data conversion devices. In some applications, the peripheral devices comprise a network interface and are connected to the computer system 810 via the network interface 822. For example, a printer may be a printer accessible via a network.
The computer device 810 may include a network interface 822 to connect to the network 104 via various connections, including, but not limited to, standard telephone lines, LAN or WAN connections (e.g., 802.11, T1, T3, 56kb, X.25, SNA, DECNET), broadband connections (for example ISDN, Frame Relay, ATM, Gigabit Ethernet, Ethernet-over-SONET), wireless connections, or a combination of any or all of the techniques mentioned here. Connections can be established using various communication protocols (for example, TCP / IP, IPX, SPX, NetBIOS, Ethernet, ARCNET, SONET, SDH, Fiber Distributed Data Interface (FDDI), RS232, IEEE 802.11, IEEE 802.11a, IEEE 802.11 b, IEEE 802.11g, CDMA, GSM, WiMax and direct asynchronous connections). The interface 822 may comprise an antenna and / or a radio transmitter and receiver.
The computer devices usually operate under the control of operating systems that are responsible for scheduling tasks and accessing system resources. The computer device can work with any operating system, such as any of the versions of the Microsoft Windows operating systems, the different releases of the Unix and Linux operating systems, any version of the MAC / OS for Macintosh computers, any embedded operating system, any real-time operating system, any open source operating system, any proprietary operating system, any operating system for mobile computing devices (e.g.
Android or iOS), or any other operating system that is able to function on the computer device and perform the operations described here. Typical operating systems include, but are not limited to: Windows 3.x, Windows 95, Windows 98, Windows 2000, Windows NT 3.51, Windows NT 4.0, Windows CE, Windows MOBILE, Windows XP, and Windows Vista, all of which are manufactured by Microsoft Corporation from Redmond, Washington; MAC OS, manufactured by Apple Computer from Cupertino, California; OS / 2, manufactured by International Business Machines from Armonk, New York; and Linux, a freely available operating system that is distributed by Caldera Corp. from Salt Lake City, Utah, or any other kind and / or form of a Unix operating system, among others.
The computer system can be any workstation, telephone, desktop or notebook computer, server, handheld computer, mobile phone or other portable telecommunication device, media player, game system, mobile computer device, or any other kind and / or form of computer, telecommunications or media device that is able to communicate. The computer system has sufficient processor power and memory capacity to perform the operations described here. For example, the computer system may include a device from the iWatch, iPod, iPad, or iPhone device families manufactured by Apple Computer from Cupertino, California; a device of type Playstation 2, Playstation 3 or Playstation Portable (PSP), manufactured by Sony Corporation of Tokyo, Japan, a device of the type Nintendo DS, Nintendo Gameboy, Nintendo Gameboy Advanced or Nintendo Revolution, manufactured by NintentoCo., Ltd from Kyoto, Japan, or an Xbox or Xbox 360 device manufactured by Microsoft Corporation of Redmond, Washington.
In some embodiments, the computer device is a digital audio player. In one of these embodiments, the computer device is a digital audio player such as the Apple devices from the iPod, iPod Touch, iPod Nano, and Ipod Shuffle ranges, manufactured by Apple Computer from Cupertino, California. In another of these embodiments, the digital audio player can function as a portable media player and as a mass storage device. In other embodiments, the computer device is a digital audio player such as the MP3 players of the DigitalAudioPlayer Select model, manufactured by Samsung Electronics America, from Ridgefield Park, NJ, or the Motorola m500 or m25 Digital Audio Players, manufactured by Motorola Ine. from Schaumburg, IL. In still other embodiments, the computer device is a portable media player such as the Zen Vision W, the Zen Vision series, the devices of the Zen Portable Media Center model, or the MP3 players from the Digital mp3 range manufactured by Creative Technologies Ltd. In still other embodiments, the computer device is a portable media player or digital audio player that supports file formats including, but not limited to, the audio file formats mp3, wav, m4a / aac, wma Protected aac, aiff, Audible audiobook, Apple lossless, and the Video file formats .mov ,, m4v and, mp4 MPEG-4 (H.264 / MPEG-4 AVC).
Examples
The following examples are intended to be illustrative and in no way restrictive of the inventions described in this document. In this section, user reports and example scenarios are presented on how people can experience the systems and practices explained.
In one example, a user downloads and installs an application on a mobile device, such as a smartphone or tablet. When the application is first opened, two buttons are shown: "in possession of a ticket" and "looking for a ticket". The user can select "in possession of a ticket" to indicate that the user has one or more tickets for an event. After selecting 'in possession of a ticket', the user is directed to an 'I come' page where the user can confirm an intention to attend the event, or inform the ticket manager that the user does not intend to attend the event. Alternatively, the user can select the "looking for a ticket" option to join a queue and wait for released or canceled tickets. In some embodiments, the application displays these two options before identifying the user or an event in which the user is interested. When the user selects "in possession of a ticket", the user may be requested to identify the event, for example by scanning the ticket or entering a ticket serial number. When the user selects "looking for a ticket", the user may be requested to enter details of the event that the user wishes to attend. If tickets are available for the event, the user can be directed to a purchase interface. If no tickets are available for the event, the user may be offered the opportunity to join the queue and the user may be asked for bank or credit card information. In some embodiments, a block is placed on the user's credit card for the transaction amount associated with a ticket transfer.
In some embodiments, the user begins interactions with the user interface before providing a login ID. The user may already have an account with the ticket manager, which may be associated with the user's client device. The user may be requested to create an account when the user reaches a decision point for which identification of the user is required. An account may be associated with user identification information (e.g., name, address, etc.), user contact information (e.g., email address, phone number, or mobile phone number), and billing information (e.g., credit card number and expiration date). The user may be asked to verify the registration information.
In some embodiments, when the user opens the application, a list is shown to the user with upcoming events for which the user has already purchased / registered / requested tickets, as a ticket owner or looking for a ticket.
In some embodiments, the user is directed to a portal with a page with three buttons: "I am new and in possession of a ticket", "I am new and looking for a ticket" and "already registered " The first two exhibit the behavior described above. The option "already registered " Leads the user to a login page with links "sign in" and "forgot password". In some embodiments, web browser cookies allow the user's client device to be associated with the login data and the user session is opened immediately, if possible, without a password. When the user logs in, the user is directed to a page with a list of upcoming events for which the user has tickets or is waiting for tickets in the queue. In some embodiments, the user is shown a list of upcoming events in the vicinity of the user, or events that resemble events that the user has attended in the past.
When the event starts, the holders of tickets that have registered their tickets and have not yet arrived or have checked in beforehand will be notified that their tickets will be canceled at a specific time unless they have the "I come". activate option. In some embodiments, the user is presented with the option of submitting the "I come" message through the customized application, via a website, by sending an SMS message with a specific code to a specific number, or by calling a telephone number and entering into an interaction with a telephone operator or telephone user interface (TUI).
In some embodiments, a user whose tickets have been canceled receives an invitation to a secondary establishment in the vicinity of the main establishment. The secondary establishment may be equipped with a television or projection view of the event and may include additional attractions to simulate attending the main event. In some embodiments, attendees in a secondary establishment are queued to receive passes for the main event. In some embodiments, attendees in a secondary establishment may receive passes with a discount or free of charge after the event has started.
In some embodiments, the user may attempt to confirm his intention to be present before an acceptable date. For example, users may be required to confirm an intention to be present not earlier that one week before the event, or the day of the event. If the acceptable time has not yet arrived, the user can receive feedback regarding the event and a message that an intention to be present has not been confirmed.
In some embodiments, it is possible for a user in the queue to request removal from the queue. For example, a user may no longer be able to attend the event. In some embodiments, a user leaving the queue without receiving a ticket is not charged. In some embodiments, a user is charged a small amount of administration fee to join the queue, and this amount is not reimbursed, but tickets that the user has not received are not charged to the user.
In some embodiments, a user whose ticket has been canceled and subsequently resold receives a full or partial refund of the original ticket price. For example, a user determines that she is unable to attend an event and submits an "I am not coming" message as described above. The ticket is then sold to another user, for example a user in the queue. The original owner of the ticket will then receive a certain amount as a refund. The amount reimbursed can be the original ticket price, with or without associated transaction costs. The amount reimbursed may be higher than the original ticket price, for example if the ticket was sold for an amount higher than the original ticket purchase price. The amount reimbursed can be lower than the original ticket price, for example if the ticket was sold for a lower amount than the original ticket purchase price.
In some embodiments, a user placed in a queue can specify a range for the desired number of tickets and / or the price that the user is willing to pay. In some such embodiments, the user may enter a price that is higher than the original ticket purchase price. In some embodiments, if a user is willing to pay a higher price, this user may be prioritized in the queue. The user is never charged more than the user indicates that he wants to pay. In some embodiments, a user may indicate that they are not willing to pay the full price and the ticket may be sold to the user at the discounted price if this is necessary to fill the establishment. That is, in some embodiments, an event organizer may give priority to filling the establishment over charging the full ticket price.
In some embodiments, when a user is placed in a ticket queue, the user may receive an indication of where the user is in the queue and how likely it is that the user will receive tickets. In some embodiments, the user receives an indication of how likely it is that the user will receive tickets before a start time of the event and / or how likely it is that the user will receive tickets after the start time of the event.
In some embodiments, the probability that a user in the queue will receive a ticket is determined as follows. The ticket manager is configured with a history of prior events, on the basis of which a value for expected available seats is calculated. For example, in some embodiments, the value for expected available seats is a percentage (e.g., 50%) of the average number of empty seats at past similar events in history. A similar event can be an event of the same type (for example, sports, concert, theater, etc.), in the same establishment (or an establishment of a similar size, at a similar location, or both), at the same time of the year or the same day of the week. The number of people in the queue below the value for expected available seats (or slightly less, for example 95% of the value for expected available seats) receives an indication that they have a high chance of gaining access to the event. The other people in the queue receive an indication that they are less likely to gain access to the event. In some embodiments, the indications are colors, for example green for very likely, yellow for likely (e.g. within 120% of the value for expected available seats, but not green) and red for 'unlikely' (e.g. further back in the queue than green or red.
In some embodiments, a person looking for a ticket may see a list of upcoming events, showing each event with an indication of the respective queue. In some embodiments, the list is a list of events for which the user has joined the queue. In some embodiments, the list is a list of events that the user might be interested in. In some embodiments, a user in a queue is offered the option of withdrawing from the queue.
In some embodiments, a user with a high probability of obtaining a ticket may have a different experience than a user with a low probability of obtaining a ticket. For example, if the probability is above a threshold value, the system can determine that the user is likely to get a ticket and it will provide additional features to make that process run smoothly. If the probability is below the threshold, the system can determine that the user will not get a ticket, and identify alternative options to address the user. For example, a user who fails to get a ticket for an event that includes a performance by a specific artist might be a fan or that specific artist, and might be interested in getting tickets to other events that include performances of the specific artist. The system can provide the user with early access to tickets for a later event as comfort for not being able to get tickets for the first event.
In some embodiments, a user in a queue who has a large (or reasonable) chance of receiving a ticket is notified (via the application, via e-mail, via text message, and / or via an automated telephone call) ) with the message that his or her position in the queue offers a good chance of getting a ticket, and that the user can now best safeguard that possibility by providing billing information (for example credit card or PayPal information) for use with purchasing a ticket as soon as one is available for this user. A block can be placed with the billing information provided. The user is warned that he or she will not be able to leave the queue after confirmation, and that the ticket will be purchased as soon as it becomes available, with no possibility to refuse it. If the user looking for a ticket refuses to confirm (or does not respond after one or more attempts that cover the confirmation period) the user is removed from the queue (or downgraded to a lower position in the queue). In some embodiments, the user receives a confirmation email or notification.
In some embodiments, a user (someone "looking for a ticket") to whom a ticket is awarded is notified on his / her smartphone (and via SMS or e-mail, depending on the preferences stored in a profile setting) the user) that the ticket is available to him / her in the application. In some versions, the ticket is displayed with a bar code or QR code that can be scanned at the entrance of the establishment. In some embodiments, an image or document is emailed to the user with the ticket embodied therein. In some versions, the user can print the ticket image or document.
In some embodiments, a user who did not receive a ticket for an event is notified that no tickets are available. In some embodiments, the user is invited to a secondary establishment. In some embodiments, the secondary establishment is an addition to the establishment of the main event. The additional establishment may, for example, be a nearby space where a video screening of the event is organized.
If a person in the additional establishment manages to get a ticket for the primary establishment, the proximity makes it easier to quickly reach the primary establishment. In some embodiments, the secondary establishment for another event is at a different time, whether or not with one or more artists of the primary event.
In some embodiments, a user may receive offers related to the event in a queue. For example, a user in a queue for attending an event that includes a performance by a particular artist may receive offers to attend other performances by that particular artist, offers to attend performances by artists similar to that particular artist, offers to buy media with that particular artist, offers to join a mailing list, or offers to buy clothing, bags, or other souvenirs concerning that particular artist. In some embodiments, a user in a queue may receive a coupon for early access to tickets for another event, for example, a future edition of the event.
In some embodiments, a user may join a queue for receiving restricted items. For example, a company may offer to deliver over-produced items to users who are in a queue. The company may not know how many excess copies of the item will be available when users join the queue, but may provide a prediction that users entering the queue below the predicted threshold may receive an indication of a high probability that they will article will receive, while users entering the queue above the predicted threshold may receive an indication of a low likelihood that they will receive the article. In some embodiments, the prediction can be updated. When the forecast is updated, users can receive an updated indication of their respective odds. In some embodiments, the over-produced items are retail items, limited-edition items, giveaway items, gift items, time-limited items, or corporate identity items.
In some embodiments, users can join a queue to secure a reservation for a hotel, restaurant, means of transport (plane, train, bus, ferry, etc.) or rental vehicle. For example, a user can request a room in a hotel that meets certain criteria (for example, with two beds). If the reservation request cannot be granted, the user can be placed in a queue in the event that a reservation is canceled, making a suitable room available. In some such embodiments, a user in the queue may receive offers to accept an alternative reservation. For example, a user waiting for a room with two beds may receive an offer for two rooms with one bed each, at the same or a comparable price. Alternatively, a user waiting for a room in a first hotel may receive an offer for a similar room in a nearby hotel.
In some embodiments, an event organizer can distribute tickets through multiple channels. For example, a sponsor of an event may receive a package of tickets for distribution separately from other tickets for the event. A sponsor can then invite people to join a queue for receiving the tickets allocated to the sponsor, regardless of whether the event is sold out or not. For example, a company can sponsor a course at a concert and organize a giveaway for tickets for seats in that course. People request tickets in the sponsored box and are placed in a queue with a certain chance of receiving the tickets. Alternatively, a company may make tickets available to employees by setting up a private queue for employees.
In some embodiments, a user may request tickets for an event before tickets for the event are made available to the public. The organizer of the event can then distribute a given number of tickets through the queue. An event organizer may prefer this as the queue shows a certain question for the event. People who are willing to join the queue can receive a reward, such as a reduced cost of tickets, preferred seats for the event, or additional material such as t-shirts, bags, or headwear on which the event is advertised.
It should be understood that the systems described above can provide multiple of any or each of these components, and that these components can be provided on a stand-alone device or, in some embodiments, multiple devices in a distributed system. The systems and methods described above can be implemented in the form of a method, device or production item using programming or manufacturing techniques for producing software, firmware, hardware or any combination thereof. In addition, the systems and methods described above may be provided as one or more computer readable programs embodied on or in one or more production items. The term "production item" as used herein is intended to include code or logic that is accessible from and embedded in one or more computer-readable devices, firmware, programmable logic, memory devices (e.g., EEPROMs, ROMs, PROMs, RAMs , SRAMs, etc.), hardware (e.g. integrated circuit chip, Field Programmable Gate Array (FPGA), Application Specific Integrated Circuit (ASIC) etc.), electronic devices, a computer-readable non-volatile storage unit (e.g. CD-ROM , floppy disk, hard disk etc.). The production item can be accessed from a file server, providing access to computer-readable programs via a network communication line, wireless communication media, signals propagating through space, radio waves, infrared signals, etc. The production item can be a flash memory card or magnetic tape . The production item includes both hardware logic and software or programmable code embedded in a computer readable medium that is executed by a processor. In general, computer readable programs can be executed in any programming language such as LISP, PERL, C, C ++, C #, PROLOG, or in any byte code language such as JAVA. The software programs can be stored as object code in one or more production items.
Now that certain embodiments have been described, it will be clear to those skilled in the art that other embodiments can be used in which the concepts of the explanation are incorporated. Therefore, the explanation is not to be limited to certain embodiments, but is only limited by the spirit and scope of the following claims.

权利要求:
Claims (40)
[1]
Conclusions
A method comprising: determining, on the basis of a rights database in which information about the allocation of rights is stored, that a first right has been assigned to a first party; receiving from a server, from a client device controlled by a second party, a request that can be granted at least in part by reassigning the first right of the first party to a second party (202); calculating, by the server, a probability that the request will be granted (204); providing the client device with an indication of the calculated probability (206); and registering, in a request database in which information about requesting rights is stored, a reference of the request.
[2]
The method of claim 1, wherein the first right comprises one or more of: a right of access to an establishment where an event is taking place; a right to attend an event; a right to enter an area with controlled access; a right to park a car in a parking lot; a right to use one or more specified seats for a limited period of time; a right to obtain additional rights; a right to receive an item; and / or a right to make a specified purchase.
[3]
The method of claim 1 or 2, comprising: adding, in response to receiving the request, an identifier for the second party to a queue at a position in the queue (208); and calculating the probability, at least based on the position in the queue.
[4]
The method of any one of the preceding claims, comprising receiving from the client device a confirmation that the second party intends to exercise the first right.
[5]
The method of claim 4, comprising assigning, in response to receiving the confirmation, a second right to the second party, the second right comprising one or more of a right of access to an additional establishment, a right to obtain additional rights ,, a right to receive an item, a right to make a specified purchase, and a consolation right that is subject to the condition that the application is not granted.
[6]
The method according to any of the preceding claims, comprising: determining, after registering the reference of the request, that the first party has released the first right (412); updating the rights database to reassign the first right of the first party to the second party; notifying the first party, in response to successfully updating the rights database, that the first right has been revoked; and notifying the second party, in response to successfully updating the rights database, that the first right has been assigned to the second party.
[7]
The method of claim 6, wherein the first right is assigned to the first party in the form of a ticket, the method comprising invalidating the ticket.
[8]
The method of claim 6 or claim 7, wherein determining that the first party has released the first right comprises: receiving from the first party an express indication that the first party has released the first right (412).
[9]
The method of claim 6, 7 or 8, wherein determining that the first party has released the first right comprises: sending a request to the first party for confirmation that the first party will exercise the first right at a specified time (640); and determining that the first party has not yet exercised the first right after the specified time (646).
[10]
The method of claim 9, wherein the first right comprises an access right to an event with an event start time, and the specified time is at or after the start time of the event.
[11]
The method of claim 9 or 10, wherein the first right comprises an access right to an event with a time for earliest access and a subsequent event start time, and the specified time is between the time for earliest access and the start time of the event.
[12]
The method for any of claims 6-11, comprising: determining that the calculated probability is above a threshold value; requesting, in response to determining that the calculated probability is above a threshold value, that the second party grants an authorization to execute a financial transaction upon selection to receive the first right; and executing the financial transaction before updating the rights database to reassign the first right from the first party to the second party.
[13]
The method of any one of claims 6-12, wherein notifying the first party comprises one or more of: calling a telephone number associated with the first party and playing a pre-recorded message ; sending an electronic message to an e-mail address associated with the first party; sending a text message to a telephone number associated with the first party; and sending a notification event to an application running on a client device controlled by the first party.
[14]
The method of any one of claims 6-13, wherein determining that the first party has released the first right comprises receiving a transfer request from the first party to re-grant the first right of the first party to the second party.
[15]
The method of any one of claims 6-14, wherein determining that the first party has released the first right comprises receiving a transfer request from the first party to re-grant the first right of the first party to a specified group of people, including the second party.
[16]
The method of any one of claims 6-15, wherein notifying the second party comprises sending ticket information to the client device (102) controlled by the second party.
[17]
The method of claim 16, wherein the first right comprises a right of access to the establishment, the method comprising accepting the presentation of the ticket information from the client device at an access point for the establishment.
[18]
A system comprising: a computer processor configured for network communication; one or more memory elements accessible to the computer processor, wherein a memory database with rights-granting information is stored in the memory elements, as well as a request database in which rights-requesting information is stored; and a computer-accessible memory in which instructions are stored which, upon execution by the computer processor, cause the computer processor to: determine, on the basis of the database in which information about the allocation of rights is stored, that a first right has been assigned to a first party; receive a request from a client device controlled by a second party that can be granted at least in part by reassigning the first right of the first party to the second party; calculate a probability that the application will be granted; provide the client device with an indication of the calculated probability; and to register a reference of the request in the application database.
[19]
The system of claim 18, wherein the first right comprises one or more of: a right of access to an establishment where an event is taking place; a right to attend an event; a right to enter an area with controlled access; a right to park a car in a parking lot; a right to use one or more specified seats for a limited period of time; a right to obtain additional rights; a right to receive an item; and / or a right to make a specified purchase.
[20]
The system according to claim 18 or 19, wherein instructions are further stored in the memory accessible to a computer which, upon execution by the computer processor, cause the computer processor to: in response to receiving the request, an identifier for the second add batch to a queue, at a position in the queue; and calculate the probability, at least based on the position in the queue.
[21]
The system according to any of claims 18-20, wherein the computer-accessible memory further contains instructions that, upon execution by the computer processor, cause the computer processor to receive a confirmation from the client device that the second party intends to exercise the first right.
[22]
The system of claim 21, wherein the computer-accessible memory further includes instructions that, upon execution by the computer processor, cause the computer processor, in response to receiving the acknowledgment, to grant a second right to the second party, where the second right comprises one or more of a right of access to an additional establishment, a right to obtain additional rights, a right to receive an item, a right to make a specified purchase, and a right of consolation this is subject to the condition that the application is not granted.
[23]
The system according to any of claims 18-22, wherein the computer-accessible memory further contains instructions that, upon execution by the computer processor, cause the computer processor to: after registering the reference of the request that the first party has released the first right; update the rights database to reassign the first right of the first party to the second party; to inform the first party, in response to the successful updating of the rights database, that the first right has been withdrawn; and to notify the second party, in response to successfully updating the rights database, that the first right has been assigned to the second party.
[24]
The system according to claim 23, wherein the first right is granted to the first party in the form of a ticket, wherein in the memory accessible to a computer instructions are further stored which, upon execution by the computer processor, cause the computer processor to invalidate the ticket.
[25]
The system of claim 23 or 24, wherein the computer-accessible memory further includes instructions that, upon execution by the computer processor, cause the computer processor to determine that the first party has released the first right in response to the receive from the first party an explicit indication that the first party has released the first right.
[26]
The system of any of claims 23-25, wherein the computer-accessible memory further includes instructions that, upon execution by the computer processor, cause the computer processor to determine that the first party is the first has released the right by: sending a request to the first party for confirmation that the first party will exercise the first right at a specified time; and determining that the first party has not yet exercised the first right after the specified time.
[27]
The system of claim 26, wherein the first right comprises an access right to an event with an event start time, and the specified time is at or after the start time of the event.
[28]
The system of claim 26 or 27, wherein the first right comprises an access right to an event with a time for earliest access and a subsequent event start time, and the specified time is between the time for earliest access and the start time of the event.
[29]
The system of any one of claims 23 to 28, wherein the computer-accessible memory further includes instructions that, upon execution by the computer processor, cause the computer processor to: determine that the calculated probability exceeds a threshold value; to request, in response to determining that the calculated probability is above a threshold value, that the second party grants an authorization to execute a financial transaction upon selection to receive the first right; and execute the financial transaction before updating the rights database to reassign the first right from the first party to the second party.
[30]
The system according to any of the claims 23-29, wherein furthermore, instructions are stored in the memory accessible to a computer which, upon execution by the computer processor, cause the computer processor to inform the first party by one or more of: calling a telephone number associated with the first party and playing a pre-recorded message; sending an electronic message to an e-mail address associated with the first party; sending a text message to a telephone number associated with the first party; and sending a notification event to an application running on a client device controlled by the first party.
[31]
The system according to any of claims 23-30, wherein the computer-accessible memory further contains instructions which, upon execution by the computer processor, cause the computer processor to determine that the first party has the first right has released in response to receiving a transfer request from the first party to reassign the first right of the first party to the second party.
[32]
The system according to any of claims 23-30, wherein further stored in the computer-accessible memory are instructions which, upon execution by the computer processor, cause the computer processor to determine that the first party has released the first right in response to receiving a transfer request from the first party to re-grant the first right of the first party to a specified group of people, including the second party.
[33]
The system of any of claims 23-32, wherein the computer-accessible memory further includes instructions that, upon execution by the computer processor, cause the computer processor to notify the second party by sending ticket information to the client device controlled by the second party.
[34]
The system of claim 33, wherein the first right comprises a right of access to the establishment, wherein in the memory accessible to a computer instructions are further stored which, upon execution by the computer processor, cause the computer processor to present the accept ticket information from the client facility at an access point to the establishment.
[35]
A method comprising: receiving from a server, from a client device controlled by a first party, a first request that can be at least partially granted by granting the first party a right of access to an event that includes a third party performance, the request being received by the server during a request time period; determining that the first application cannot be granted during the application time period; calculating by the server a probability that the first request will be granted during a second time period following the request time period; and providing the client device with an indication of the calculated probability, wherein the indication comprises a commitment request if the calculated probability is at or above a threshold value, and wherein the indication comprises a comfort message if the calculated probability is below the threshold value.
[36]
The method of claim 35, wherein the event is a first event and the consolation message includes an offer to purchase an access right for a second event that includes a third party performance.
[37]
The method of claim 35 or 36, wherein the commitment request comprises a second request to pre-authorize a financial transaction associated with the condition that the first request is granted.
[38]
The method according to claim 37, comprising responding a refusal of the commitment request with the consolation message by the server.
[39]
39. A system comprising: a computer processor configured for network communication; a computer-accessible memory in which instructions are stored which, when executed by the computer processor, cause the computer processor to: receive from a client device controlled by a first party a first request that can be at least partially granted by sending it to the grant first party a right of access to an event that includes a third party performance, the request being received by the server during a request time period; determine that the first application cannot be granted during the application time period; calculate a probability that the first request will be granted during a second time period following the request time period; and providing the client device with an indication of the calculated probability, wherein the indication comprises a commitment request if the calculated probability is at or above a threshold value, and wherein the indication comprises a comfort message if the calculated probability is below the threshold value.
[40]
The system of claim 39, wherein the commitment request comprises a second request to pre-authorize a financial transaction associated with the condition that the first request is granted.

类似技术:

---

公开号 | 公开日 | 专利标题

---

BE1022651B1|2016-06-27|SYSTEMS AND METHODS FOR RETURNING TICKETS FOR AN EVENT

---

US9202180B2|2015-12-01|Methods and systems for computer aided event and venue setup and modeling and interactive maps

---

US20140095229A1|2014-04-03|Method and system for network-enabled venue booking

---

JP6570642B2|2019-09-04|Online product reservation system

---

US20150324400A1|2015-11-12|Interest Collection and Tracking System and Method of Use

---

CN105745673A|2016-07-06|Social media product reservation

---

US20100235240A1|2010-09-16|Automatic vending apparatus for providing advertisement and method thereof

---

US20140310030A1|2014-10-16|System and method for processing establishment reservation

---

US20160005012A1|2016-01-07|Consolidated platform for selling tickets

---

US20200167699A1|2020-05-28|Event management and coordination platform

---

US10455290B2|2019-10-22|Method and system for distance based video advertisement reward system with instant dynamic price generation for digital media propagation

---

JP2012088841A|2012-05-10|Coupon provision device

---

AU2012101126A4|2012-08-30|Method and System for Managing Hospitality Information and Services

---

JP6923891B1|2021-08-25|Reservation management server and reservation management method

---

JP6723589B1|2020-07-15|Service system, computer program used therefor, and control method

---

RU2699059C1|2019-09-03|Method for attracting customers to sales offices of goods and services

---

JP6893617B2|2021-06-23|Equipment, programs, systems for providing point services

---

US20150006269A1|2015-01-01|System for Facilitating Deals Including the Management of Commissions Associated With Referrals

---

JP6214021B1|2017-10-18|Issuing apparatus, issuing method and issuing program

---

JP2021135768A|2021-09-13|Ticket sales method, ticket sales program, and information processing device

---

JP2019057004A|2019-04-11|Authentication system, authentication method and information processor

---

US9940602B1|2018-04-10|Item purchase, redemption and delivery including user-defined parameters

---

US20180096336A1|2018-04-05|Payment parsing management services systems and methods

---

JP2018026078A|2018-02-15|Electronic ticket vending machine, electronic ticket vending method, and electronic ticket vending program

同族专利:

---

公开号 | 公开日

---

WO2015092552A2|2015-06-25|

---

BE1022651A1|2016-06-27|

---

US20160321568A1|2016-11-03|

---

WO2015092552A3|2015-10-22|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

US20080109296A1|2006-09-08|2008-05-08|Leach Andrew K|Contingent rights exchange associated with a social network|

---

US10304110B2|2013-12-26|2019-05-28|Ebay Inc.|Ticket listing triggered by URL links|

---

JP2015127899A|2013-12-27|2015-07-09|株式会社ソニー・コンピュータエンタテインメント|Information processing device and information processing system|

---

JP2015127900A|2013-12-27|2015-07-09|株式会社ソニー・コンピュータエンタテインメント|Information processing device, server system, and information processing system|

---

JP2015127898A|2013-12-27|2015-07-09|株式会社ソニー・コンピュータエンタテインメント|Information processing device and information processing system|

---

US9690968B2|2015-05-17|2017-06-27|William A. Wadley|Authenticated scannable code system|

---

US20170344913A1|2016-05-29|2017-11-30|Confirm Ticket Online Solutions Private Limited|System and method for detecting effective travel option and tickets between a source and destination with different modes of transports|

---

US20180018593A1|2016-07-15|2018-01-18|International Business Machines Corporation|Expedited identification verification and biometric monitoring|

---

US20180053260A1|2016-08-16|2018-02-22|Samuel Richard Barlow|Digital method for facilitating the organisation ofan event or project|

---

CN108206789A|2016-12-20|2018-06-26|英业达科技有限公司|The SiteServer LBS and its method of segmented processing request|

---

TWI735519B|2017-01-24|2021-08-11|香港商阿里巴巴集團服務有限公司|Distributed environment coordinated consumption queue method and device|

---

US20180357572A1|2017-06-13|2018-12-13|Amazon Technologies, Inc.|Contiguous Event Seating Across Temporal Ticketing Intervals|

---

US10671945B2|2017-10-17|2020-06-02|Amazon Technologies, Inc.|Exchanging encumbrances across multiple ticket holders|

---

US11223596B2|2018-11-19|2022-01-11|Stubhub, Inc.|Generation of composite messages using qualifying events and actions|

---

WO2020145835A2|2019-01-09|2020-07-16|Al Qebaisi Rooda Omran|System and method of smart seating management|

法律状态:

优先权:

---

申请号 | 申请日 | 专利标题

---

US201361919544P| true| 2013-12-20|2013-12-20|

---

US61/919,544|2013-12-20|

---