Methods and systems for computer aided event and venue setup and modeling and interactive maps.

(54) Title: METHOD AND SYSTEMS FOR CONFIGURATION AND MODELING BY COMPUTER OF EVENT SITES AND INTERACT MAPS.

(54) Title: METHODS AND SYSTEMS FOR COMPUTER AIDED EVENT AND VENUE SETUP AND MODELING AND INTERACTIVE MAPS.

(57) Summary

Systems and methods are described for designing certain aspects of an event center and for communicating information about the event and the event location to other people. Certain embodiments provide a dynamic map through which an operator can assign certain characteristics to specific seats and / or seating sections. Certain embodiments generate interactive maps for users through which information from a plurality of sources can be integrated and displayed visually. The user can specify certain criteria, and the interactive map can identify user seats and / or sections that meet those criteria. Certain embodiments provide an interactive seat map through which users can select seats and share information.

(57) Abstract

Described are systems and methods for designing certain aspects of an event venue and for communicating Information regarding the event and the event venue to others. Certain embodiments provide a dynamic seat map via which an operator can assign certain characteristics to specific seats and / or seating sections. Certain embodiments generate Interactive maps for users, via which Information from a plurality of sources may be integrated and visually displayed. The user may specify certain criteria, and the Interactive map may identify to the user seats and / or sections that match such criteria. Certain embodiments provide an Interactive seat map via which users can select seats and share information.

I Μ Ρ I% · · '*' ί Mu ···)

PATENT TITLE No. 350182

Owner (s): TICKETMASTER LLC

Address: 8800 Sunset Boulevard, 6th Floor, West Hollywood, California, 90069, USA

Name: METHODS AND SYSTEMS FOR CONFIGURING AND MODELING BY COMPUTER OF EVENT SITES AND INTERACTIVE MAPS.

Classification: CIP: G06Q10 / 02; G06Q30 / 06

CPC: G06Q10 / 02; G06Q30 / 06; G06Q30 / 0643

Inventor (s): SCOTT STENBACK; DENNIS DENKER; BRADFORD J. BENSEN; JAMES PAUL

CALLAGHAN; RAYMOND YUNG-CHIEN LEW; DEBBIE HSU

REQUEST

Number: International Presentation Date:

MX / a / 2012/014818 June 15, 2011

PRIORITY

Country: Dates Number:

US June 15, 2010 61/355000

Validity: Twenty years

Maturity Date June 15, 2031

Issue Date: August 8, 2017

The reference patent is granted based on articles Γ, 2nd section V, 6 section III, and 59 of the Industrial Property Law.

In accordance with article 23 of the Industrial Property Law, this patent is valid for twenty years, renewable, counted from the filing date of the international application and will be subject to detailed payment to keep the rights in force.

Whoever signs this title does so based on the provisions of articles 6^or Sections III and 7 bis 2 of the Industrial Property Law (Official Gazette of the Federation (DO F.) 06/27/1991 amended on 08/02/1994, 10/25/1996, 12/26/1997. 05/17/1999, 01/26/2004, 06/16/2005, 01/25/2006, 05/06/2009, 06/01/2010, 06/18/2010, 06/28/2010, 27 / 01/2012 and 09/04/2012); items 1^or, 3^or Vinciso fraction a), 4^or and 12^or Sections I and III of the Regiamente of the Mexican Institute of Industrial Property (DOF 12/14/1999, amended on 07/01/2002, 07/15/2004, 07/28/2004 and 09/07/2007); items 1^or, 3^or, 4^or, 5th section V subsection a), 16 sections I and III and 30 of the Organic Statute of the Mexican Institute of Industrial Property (DOF 12/27/1999, amended on 10/10/2002, 07/29/2004. 08/2004 and 09/13/2007), 1 ', 3 ° and 5 »subsection 8) of the Agreement that delegates powers to the Deputy General Directors, Coordinator, Divisional Directors, Holders of the. Regional Offices Divisional Subdirectors, Departmental Coordinators and other subordinates of the Mexican Institute of Industrial Property. (DOF 12/15/1999, amended on 02/04/2000, 07/29/2004, 08/04/2004 and 09/13/2007).

This document is signed with an advanced electronic signature (FIEL), based on articles 7 BIS 2 of the Industrial Property Law; 3 of its Regulations, and 1 section III, 2 section V, 26 BIS and 26 TER of the Agreement establishing the guidelines for the use of the Payment and Electronic Services Portal (PASE) of the Mexican Institute of Industrial Property, in the procedures indicated.

THE DIVISIONAL DIRECTOR OF PATENTS

NAHANNY CANAL REYES

<img file="MX350182B_D0001.tif" />

Original string:

NAHANNY MARISOL CANAL REYES | 00001000000403252793 | Administration Service

Tnbutaria | 1695 || MX / 2017/70626 | MX / a / 2012/014818 | PCT patent title | 1027 | RGZ | Page (s) | DRoyF9WwDPRJ8B56Q0X9IEiKFkc =

Digital stamp:

kl + u7sFQz846ksp9DIIJrpzenTRCFH9hhFql1Sx2ul + FJp7QdK86Vzie5lpPLRK3gEtS / 3IFQGsSZmqxe0auYbtKDb swqjWOjEIL1lhVwLjpy + kzz // Wkcx1 / + yZbv5vo5TbWB9f1wxNV1G7noH9eb5 / 7rmkQBN05sn6MnyiVTmxGBBVYQn7 rO / l2JDgB2ezt9BTASwxgZt1WKWAwWfOXHQZYTQkMQcOM / hTVGXCo2N erdCE3QzrUYu50EVolh9FOz57NdhVPjfWJ + a + GOWMORN / == OuiBMywWrPSG5KOHhGM7nl7ouaNZmQoV3AYW2MHeXJNuz4r6ntGOn4x6Qj4VQO

Arenal No 550, f ·., ^{* 1} i ·, 1 or -.>. · Ι m, Xochimilco, I6020. :. what iU

-, '7¡,. ·>: · '<L <' i iin p¡

<img file="MX350182B_D0002.tif" />

LN? Ri nt iv MfcxiCANi. Jh, Ü £ LA HUWIUaL »v \ J3lJy

METHODS AND SYSTEMS FOR CONFIGURATION AND MODELAWPOR ^²-¹^ INTERACTIVE MAPS AND EVENT LOCATION COMPUTER ....

Background of the Invention '

Field of the invention.

The present invention relates to computer design and electronic maps and, in particular, to the configuration of places and events by computer and interactive maps.

Description of the related art.

Selling tickets for events involves setting prices and selling tickets. Certain conventional techniques statically set the ticket price for an event. That is, once a price is set for a ticket or class of tickets or tickets with respect to an initial sale of the tickets, the price does not change. Furthermore, with the use of conventional techniques, prices are often based on insufficient information, resulting in ticket prices that are too high or too low given the actual demand for such tickets.

Additionally, an increasing number of event tickets are being sold online, rather than over the phone or through traditional means. However, conventional seating maps for venues that are featured in connection with such online sales tend to be static, and do not adequately provide the relevant dynamic data in real time. Furthermore, conventional seating maps cannot provide adequate interfaces to allow users to quickly locate the appropriate seats.

SUMMARY OF THE INVENTION

A simplified summary of one or more aspects is presented below in order to provide a basic understanding of those aspects. This summary is not a comprehensive overview of all aspects contemplated, and is not intended to identify key or critical elements of all aspects or to delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified way as a prelude to the more detailed description that follows. '

Methods and systems for creating ticketed events and ticketing or ticketing execution (for example, using interactive ticket maps) are described here. In particular, certain methods and systems described in this document are configured to create ticketed events, set ticket prices, and execute ticket sales through interactive dynamic user interfaces.

An exemplary ticketing system, configured to set ticket or ticket sales prices and / or sell tickets, is networked to box office systems, promoters, artist representatives, event support staff, social media systems, and / or potential ticket buyers.

Certain embodiments receive and use information, such as event ticket sales information, event timeline, attendance at competing attractions, and / or other information to establish an initial price and / or to adjust the previously established price of tickets or tickets to the event. Certain embodiments provide interactive maps configured to facilitate user understanding of available seats, prices, available discounts, seat packages, etc., providing a complete graphical view of what can be a complex set of prices and promotions.

Described herein is a system for providing an interactive seat map, comprising: computer equipment; a non-transitory medium that stores instructions that, when executed by the computer equipment, make it perform operations that consist of: accessing a seat map for a place, said seat map including a definition of a plurality of sections and of seats within the plurality of sections; optionally access price information associated with the plurality of sections and / or seats of the venue for a first event; provide the map to a user terminal to display it as an interactive seating map that includes sections and / or individual seats in association with one or more of the following elements: an interface using the

IMPIAS &lt;3 ^ which user can specify a price range with respectw ^ P'TOs seat tickets; an interface by which the user can view or select a first offer, wherein the first offer provides at least one of the following: a reduced price with respect to at least one seat ticket; a reduced price with respect to an ancillary product or service in association with at least one ticket purchase; a right to purchase seat tickets for a certain category of seats if a corresponding offer code is provided; receiving, via a data interface, reception relationship information with respect to the user, wherein the relationship information includes identifications of one or more friends of the user; where, at least in part in response to a user-specified price range and / or a user-specified offer, the interactive seat map emphasizes the sections and / or seats corresponding to the range of user-specified prices and / or user-specified offer; access seat information regarding one or more friends of the user, making, at least in part, the interactive seat map indicate sections and / or seats in which at least a part of the user's friends have tickets or tickets; and receiving and processing a ticket purchase request for at least one seat selected by the user through the interactive seat map.

Described herein is a method that comprises some or all of the following acts: accessing a seat map for a location, the seat map including a definition of a plurality of sections and of the seats within said plurality of sections; accessing the pricing information associated with the plurality of venue sections and / or venue seating for a first event; provide the map to a user terminal for viewing as an interactive seat map that includes individual sections and / or seats in association with: an interface by which a user can specify a price range with respect to seat tickets ; an interface by which the user can specify at least a first offer, where the first offer provides at least one of the following: a reduced price with respect to the menef $ * ¿üij &amp; w ^ seat; a reduced price with respect to an ancillary product or service in association with at least one ticket purchase; a right to purchase seat tickets for a certain category of seats if a corresponding offer code is provided; receiving, through a data interface, receiving relationship information regarding the user, wherein the relationship information includes identifications of one or more friends of the user, wherein, at least in part in response to a range price specified by the user and / or an offer specified by the user, the interactive seat map emphasizes sections and / or corresponding seats for the user-specified price range and / or the user-specified offer; access the seat information regarding one or more friends of the user, making, at least in part, the interactive seat map indicate the sections and / or seats in which at least a part of the user's friends have tickets or tickets; and receiving and processing a ticket purchase request for at least one seat selected by the user through the interactive seat map.

Described herein is a system for providing an interactive seat map, comprising: computer equipment; a non-transitory medium that stores instructions that, when executed by the computer equipment, make it perform operations consisting of: accessing a seating map for a location, the seating map that includes a definition of a plurality of sections and of the seats within said plurality of sections; accessing the pricing information associated with the plurality of venue sections and / or venue seats for a first event; transmitting the map to be displayed as an interactive seat map on a user terminal, in association with: an interface by which a user can specify a price range with respect to seat tickets; receiving, via a data interface, relationship information regarding the user, wherein the relationship information includes identifications of one or more friends of the user; access the seat information regarding one or more friends of the user; and in which, in response to a price range specified by the

IMPI

INSTmnV'MEXICANO

Of LA FRnwEl AD user, the interactive seat map emphasizes the ¿é'otWies jwHey seats that correspond to the specified price range ñor pI iisi inriCL v in which the interactive map indicates where the user's friend (s) are sitting; receive and process a ticket purchase request for at least one seat selected by the user through the interactive seat map.

Described herein is a method comprising some or all of the following acts: accessing a seat map for a location, the seat map includes a definition of a plurality of sections and of the seats within said plurality of sections ; accessing the information associated with the pricing of the plurality of venue sections and / or venue seating for a first event; transmitting the map to be displayed as an interactive seat map at a user terminal in association with: an interface by which the user can specify a price range with respect to seat tickets; receiving, via a data interface, relationship information regarding the user, wherein the relationship information includes identifications of one or more friends of the user; access seat information regarding one or more friends of the user, and in which, in response to a price range specified by the user, the interactive seat map emphasizes the sections and / or seats corresponding to the range price specified by the user, and where the interactive map indicates where one or more of the user's friends are sitting; receive and process a ticket purchase request for at least one seat selected by the user through the interactive seat map.

Described herein is a system for providing a seating map of the venue, comprising: computer equipment; a non-transitory medium that stores instructions that, when executed by the computer equipment, causes it to perform operations consisting of: accessing a seat map for a place, the seat map includes a definition of a plurality of seats; receiving, via a data interface, relationship information regarding a user, wherein the relationship information includes identifications of one or more friends of the user; access seat information regarding one or more friends of the user; and make '^ qj ^ j ^ fl ^ seats indicate where the user's friend (s) are seated.

Described herein is a method that conipreitúiralyuiiüs all of the following acts: accessing a seat map for a location, the seat map includes a definition of a plurality of seats; receiving, via a data interface, relationship information regarding a user, wherein the relationship information includes identifications of one or more friends of the user; access the seating information regarding one or more of the user's friends, and make the seat map indicate where the user's friend (s) are sitting.

Described herein is a system for providing an interactive seat map, comprising: computer equipment; a non-transitory medium that stores instructions that, when executed by the computer equipment, cause it to carry out operations consisting of: accessing a seat map for a place, the seat map includes a definition of a plurality of sections and of the seats within the plurality of sections; accessing the pricing information associated with the plurality of venue sections and / or venue seating for a first event; accessing status information regarding a plurality of seats at the venue, said status information indicating the availability of seats; transmitting the map to be displayed as an interactive seat map on a user terminal, wherein the interactive map indicates seat availability; provide a user interface through which: a user can select a seat whose ticket was previously purchased by another, and make an offer, including a user-specified price, to purchase the ticket for the selected seat from the holder of the ticket; if the user sends an offer to the ticket holder, transmit the offer to the ticket holder, and process the acceptance or rejection of the offer by the ticket holder.

Described herein is a method, comprising some or all of the following acts: accessing a seating map for a location, the seating map includes a definition of a plurality of sections and of the

IMPI ^ ins ητο'π »iv» £ xicanu

Uk LZ PRiJPIÍUAÜ seats within the plurality of sections; access JnformadtoW^TCle esraeBon a plurality of seats in the venue, the status information indicates the availability of seats; transmitting the map to be displayed on the screen as an interactive seat map in a user terminal where the interactive map indicates seat availability; provide a user interface through which: a user can select a seat whose ticket was previously purchased by another, and make an offer, including a user-specified price, to purchase the ticket for the selected seat from the holder of the ticket; if the user sends an offer to the ticket holder, transmit the offer to the ticket holder, and process the acceptance or rejection of the offer by the ticket holder.

Described herein is a system for providing a seat map, comprising: computer equipment; a non-transitory medium that stores instructions that, when executed by the computer equipment, cause it to perform operations consisting of: accessing a seat map for a location, the seat map includes a definition of a plurality of seats; access information on the purchase process, in which the information on the purchase process indicates: a first ticket for a first seat is going to be put on sale through a first type of purchase process and a second ticket for a second seat it is going to be put up for sale through a second type of buying process different from the first type of buying process; accessing the status information regarding a plurality of seats at the venue, wherein the status information indicates the availability of venues; transmit the seat map for display on a user terminal, where the seat map indicates the availability of seats, and where the seat map visually indicates that: the first ticket for the first seat available for purchase through of the first type of purchase process, and the second ticket for the second seat is available for purchase through the second type of purchase process; provide a user interface that allows a user to: select the first seat through the seat map and initiate a first ticket purchase transaction using the first type of purchase process, and / or choose the second seat through initiating a purchase operation for the second ticket with the second type of _I Πίΐ τ i ~ --- _ - ¹ - »· ι IH'i ·। । ·· ii · purchase process.

Described herein is a method comprising some or all of the following acts: accessing a seat map for a location, the seat map including a definition of a plurality of seats; access the information of the purchase process, in which the information of the purchase process indicates that: a first ticket for a first seat will be put on sale through a first type of purchase process and a second ticket for a second seat is going to be put up for sale through a second type of purchase process different from the first type of purchase process; accessing the status information relating to a plurality of seats at the venue, the status information indicating the availability of seats; transmit the seat map for display on a user terminal, where the map indicates seat availability, and where the seat map visually indicates that: the first ticket for the first seat is available for purchase through the first type of purchase process, and the second ticket for the second seat is available for purchase through the second type of purchase process; provide a user interface that allows the user to: select the first seat through the seat map and initiate a first ticket purchase transaction using the first type of purchase process, and / or choose the second seat through the seat map seats and initiate a purchase operation for the second ticket with the second type of purchase process.

Described herein is a system for providing a seat map, comprising: computer equipment; a non-transitory medium that stores instructions that, when executed by the computer equipment, causes it to perform operations consisting of: accessing a seat map for a location, where the seat map includes a definition of a plurality of seats; transmit the seat map for display on a terminal of a first user, where the map indicates seat availability, and provide a user interface that allows the first user to:

select the first seat through the asiebtaiVl map J? eleift &amp; í ^

INSTITUTO MEXICANO first offer to buy a corresponding first ticket'at ^ Wtor identify a second user; conditioning the offer to purchase the first ticket for the first seat upon the acceptance of a second offer from the second user to purchase a second ticket for a second seat; determine if the second offer to buy the second ticket for the second seat is acceptable; determining whether the first offer to buy the first ticket for the first seat is acceptable, at least in part, in response to determining whether the first offer to buy the first ticket for the first seat and the second offer to buy the second second seat tickets are acceptable, allowing the purchase of the first ticket to be completed.

Described herein is a method comprising some or all of the following acts: accessing a seat map for a location, the seat map including a definition of a plurality of seats; transmitting the seat map for display at a terminal of a first user, where the seat map indicates seat availability; and providing a user interface that allows the first user to: select the first seat through the seat map and submit a first offer to purchase a first ticket corresponding to the first seat; identify a second user; conditioning the offer to buy the first ticket for the first seat on the acceptance of a second offer by the second user to buy a second ticket for a second seat; determine if the second offer to buy the second ticket for the second seat is acceptable; determine whether the first offer to buy the first ticket for the first seat is acceptable, at least in part, in response to determining whether the first offer to buy the first ticket for the first seat and the second offer to buy the second ticket for the second seat are acceptable, allowing the purchase of the first ticket to be completed.

Described herein is a system for providing a seat map, comprising: computer equipment; a non-transitory medium that stores instructions that, when executed by computer equipment,

<img file="MX350182B_D0003.tif" />

causes it to perform operations consisting of: stopping a plurality of users is interfering with the provision, to úha ptorairdBd ^ user terminals, of substantially real-time updates to an interactive seating map, in which the interactive seating map allows a given user to select a specific seat through the interactive seat map and purchase a ticket for the seat selected by the user; at least in part in response to the determination that user activity is interfering with the provision, to the plurality of user terminals, of substantially real-time updates to the interactive seat map: prevent at least a portion of the plurality of users use the interactive seat map to purchase seats selected by the users; and allowing one or more users to purchase seat tickets through a first user interface in which the user cannot select specific seats to purchase tickets.

Described herein is a method comprising some or all of the following acts: determining whether activity by a plurality of users is interfering with the provision, to a plurality of user terminals, of substantially real-time updates to an interactive seat map, wherein the interactive seat map enables a user determined to select a specific seat through the interactive seat map and purchase a ticket for the seat selected by the user; at least in part in response to determining whether user activity is interfering with the provision, to the plurality of user terminals, of substantially real-time updates to the interactive seat map: prevent at least a portion of the plurality of users from using the interactive seat map to purchase user-selected seats, and allow one or more users to purchase seat tickets through a first user interface in which the user does not you can select specific seats to purchase tickets.

Described herein is a method of providing an interactive map of the location, comprising some or all of the following:

IΜ ρ I detect that a user is in the first place pafé'üií ^^Mr ^ ere \ ^^ make an interactive map of the first place to be displayed on a mobile user terminal; identify one or more friends of the user who attend the first event in the first place; identify the seat locations of one or more friends of the user; include an indication on the interactive map of the place of the seating positions of one or more friends within the first place for the first event.

Described herein is a system for providing a seat map, comprising: computer equipment; a non-transitory medium that stores instructions that, when executed by the computer equipment, causes it to carry out operations that consist of: detecting that a user is in the first place for a first event; allowing an interactive map of the first location to be displayed on a mobile user terminal; identify one or more friends of the user who attend the first event in the first place; identify the seat locations of one or more friends of the user; Include an indication on the interactive map of the location of the seating locations of one or more friends within the first venue for the first event.

Described herein is a method for providing an interactive map of the location, comprising some or all of the following acts: detecting that a user is in the first place of a first event; allowing an interactive map of the first location to be displayed on a mobile user terminal; receiving information of the current location of the mobile user terminal while the mobile user terminal is in the first place; estimating the online duration times for a plurality of destinations of a first type of destination, and transmitting to the mobile user terminal information regarding the estimated online duration times for at least one of the plurality of destinations of the first type of destination.

Described herein is a system for providing a seat map, comprising: computer equipment; a non-transitory medium that stores instructions that, when executed by the computer equipment, make it carry out operations that consist of: detecting that a user is in a first place for a prime event; allowing unmapgjut ^ pti place of first place to be displayed on a mobile user terminal; receive information of the current location of the terminal from usualItrrnúVll ΓΗΐεη! Γ35 * δΓ mobile user terminal is in the first place; calculating the online duration times for a plurality of destinations of a first type of destination, and transmitting to the mobile user terminal information regarding an estimated online duration time for at least one of the plurality of destinations of the first type of destination.

Described herein is a system for controlling the display or display of images on a remote device, comprising: a computer equipment; a non-transitory medium that stores instructions that, when executed by the computer equipment, make it perform operations that consist of: detecting the presence of the remote device at an event location, the event location includes a plurality of seats, identifying a first user associated with the remote device; determining what is displayed on the screen of the remote device associated with the first user; accessing relationship information for the first user, said relationship information identifying at least one second user with whom the first user has a relationship; identifying a seating location at the event venue that is associated with the second user; at least in part in response to determining whether the seat location associated with the second user is displayed on the screen of the remote device associated with the first user, causing computer generated data to be displayed in association with the seat location displayed , the computer generated data including an identifier of the second user and / or an indication that the first user has a relationship with the second user.

Described herein is a method comprising some or all of the following acts: detecting the presence of the remote device at an event venue, wherein the event venue includes a plurality of seats; identifying a first user associated with the remote device; determining what is displayed on the screen of the remote device associated with the first user;

IMPI ^{ΙΝ; ΓΠ}, Τ'7^υ Μ EX .cano V &lt;&lt; Lr ¿i

Ϊ> Ε LA v- * access relationship information for the first user, where the^orififbTmab? etot ^^ relationship identifies at least one second user with the qua pi first user has a relationship; identifying a seating location at the event venue that is associated with the second user; at least in part in response to determining whether the location of the seat associated with the second user is displayed on the screen of the remote device associated with the first user, causing computer generated data to be displayed in association with the location of the displayed seat , the computer generated data including an identifier of the second user and / or an indication that the first user has a relationship with the second user.

Described herein is a system for setting up a ticketed event, comprising: computer equipment; a non-transitory medium that stores instructions that, when executed by the computer equipment, make it perform operations that consist of: accessing a seat map for a place, the seat map including a definition of a plurality of sections and of seats within the plurality of sections; allow the seat map of the place to be displayed on a user terminal; accessing from memory and allowing an event name for a ticketing event being organized to be displayed, in association with the venue's seat map, with the venue's seating map; access from memory and allow a name associated with the place to be displayed on the screen, in association with the seat map of the venue; access from memory and allow a date of the event being organized to be displayed on the screen, in association with the seat map of the venue, using the map of the venue; accessing from memory and providing seat status information, wherein said seat status information indicates how many seats there are at the event venue and the tickets that will be offered for sale; access information of monetary value (for example, the value of the ticket and / or other fees related to the ticket (for example, service charges, commission charges, handling charges, shipping costs, etc.)) for the corresponding tickets to the seats whose tickets will be offered to the

IMPIOS sale; calculate the potential revenue for the event, based on the industrial monetary value information and the number of seats at the event venue whose tickets will be offered for sale; allow the ingieae puÍeiiiidFcalüUtaflcí '' for the event to be displayed on the user terminal; accessing from memory and allowing a list of a series of price levels to be viewed on the screen, in which a certain price level is related to a subset of seats whose tickets are to be offered for sale; allow a monetary value of tickets associated with seats to be displayed at the given price level; allow how many seats are associated with the determined price level to be displayed; calculate and show an income potential for the given price level; allowing a user interface to be displayed on the user terminal through which a user can alter: a count of seats associated with the determined price level; and the monetary value of the tickets associated with the seats at the determined price level; calculate and allow to show a new potential revenue for the determined price level based, at least in part, on the user's alteration of the monetary value of the tickets associated with the seats at the determined price level and / or on the user's alteration of the seat count for the given price level.

Described herein is a method comprising some or all of the following acts: accessing a seating map for a location, the seating map including a definition of a plurality of sections and of seats within the plurality of sections; allow the seat map of the place to be displayed on a user terminal; accessing from memory and allowing an event name for a ticketing event being organized to be displayed, in association with the venue's seat map, with the venue's seating map; access from memory and allow a name associated with the place to be displayed on the screen, in association with the seat map of the venue; access from memory and allow a date of the event being organized to be displayed on the screen, in association with the seat map of the venue, using the map of the venue; to access

WICKED

INSTITUTE MtXICANu from memory and provide information on the status of the agléW ^^ ti delcto ^ dP * said information on the status of the seats indicates how many seats there are at the event and the tickets that will be offered for sale; access information of monetary value (for example, ticket value and / or other ticket-related charges (for example, service charges, commission charges, handling charges, shipping costs, etc.)) for tickets corresponding to the seats whose tickets will be offered for sale; calculate the potential income for the event, based at least in part, on the monetary value information and the number of seats at the event venue whose tickets will be offered for sale; allowing the potential revenue calculated for the event to be displayed on the user terminal; accessing from memory and allowing a list of a series of price levels to be viewed on the screen, in which a certain price level is related to a subset of seats whose tickets are to be offered for sale; allow a monetary value of tickets associated with seats to be displayed at the given price level; allow how many seats are associated with the determined price level to be displayed; calculate and show an income potential for the given price level; allowing a user interface to be displayed on the user terminal through which a user can alter: a count of seats associated with the determined price level; and the monetary value of the tickets associated with the seats at the determined price level; calculate and allow to show a new potential revenue for the determined price level based, at least in part, on the user's alteration of the monetary value of the tickets associated with the seats at the determined price level and / or on the user's alteration of the seat count for the given price level.

Described herein is a system for setting up a ticket requiring event, comprising: computer equipment; a non-transitory medium that stores instructions that, when executed by the computer equipment, cause it to carry out operations that include some or all of the following acts: access a seat map of the place, where

INSTITUTO MEXICANO DE LA EKCHFDAD the seat map includes a definition of a plurality of sections of seats within the plurality of sections; allow sl.map Hp qg¡pntn. &amp; dai— place to be displayed on a user terminal; allow an identifier associated with an event that is defined using the site map to be displayed; allowing a user interface to be displayed through which a user can specify ticket prices for selected seats through the seat map; calculate a revenue potential for the event based, at least in part, on the specified ticket prices and the seats at the venue for which tickets will be offered for sale; allow the potential revenue calculated for the event to be displayed on the user's terminal; accessing from memory and allowing a list of a series of price levels to be displayed, in which a certain price level is associated with a subset of seats for the tickets to be offered for sale; allowing a ticket price associated with the seats to be displayed at a first price level; allow to see how many seats are associated with the first price level; calculate and allow a potential income from the price level to be visualized; allow a user interface to be displayed on the user terminal through which the user can modify a monetary value (for example, the value of the ticket and / or other charges related to the ticket (for example, service charges , commission charges, handling charges, shipping charges, etc.)) of tickets associated with seats at a second price level after one or more tickets to the event have been sold; calculating and allowing a new revenue potential to be displayed for the determined price level, based, at least in part, on an alteration by the user of the monetary value of the tickets associated with the seats in the second price level.

Described herein is a method comprising: accessing from memory a seat map for a location, wherein the seat map includes a definition of a plurality of sections and of seats within the plurality of sections; allow the seat map of the place to be displayed on a user terminal; allow senNVfeüaNzacRncS ^ identifier associated with an event that is defined to use the location map; allowing a user interface to be displayed through which a user can specify ticket prices for selected seats through the seat map; calculating, using a computing device, a potential revenue for the event based, at least in part, on the specified ticket prices and the number of seats at the event venue whose tickets are to be offered for sale; allow the potential revenue calculated for the event to be displayed on the user terminal; accessing the memory and allowing a list of a series of price levels to be displayed, in which a certain price level is related to a subset of seats whose tickets are to be offered for sale; allow a ticket price associated with seats to be displayed at a first price level; allow the display of how many seats are associated with the first price level; calculate and visualize an income potential for the first price level; allow a user interface to be displayed on the user terminal through which the user can modify the monetary value of tickets associated with seats at a second price level after one or more tickets for the event have been sold; calculating and allowing to show a new revenue potential for the determined price level, based, at least in part, on an alteration by the user of the monetary value of the tickets associated with seats in the second price level.

Described herein is a method comprising: accessing, through a computer system, a user interface including a seat map for a first place a first ticketed event, in which the first place includes a plurality of seats; defining a first plurality of price levels for the first ticketed event; select, through the seat map, one or more seats; associating the selected entries with a certain price level in the first plurality of price levels; assign monetary values ​​to the respective price levels in the first

<img file="MX350182B_D0004.tif" />

IMPI

INSTITUTO MEXICANO • E LA FROPIEDAD INDUSTRIAL plurality of price levels; make the nairniA rompíitarinra system a potential first income for the first ticketed event, in which the first potential income is based, at least in part, on the monetary values ​​assigned to the respective price levels and how many seats are associated with the respective price levels; changing a first of the monetary values ​​assigned to a first of the price levels to a second monetary value; and have the computer system calculate a second potential income for the first ticketed event, in which the second potential income is based, at least in part, on the monetary values ​​assigned to the respective price levels, including the second monetary value and how many seats are associated with the respective price tiers.

This document describes a method comprising some of the following acts: accessing a seat map for a location, wherein the seat map includes a definition of a plurality of sections and of seats within the plurality of sections; allow the seat map of the place to be displayed on a user terminal; allow an identifier associated with an event that is defined using the site map to be displayed; allowing a displayable user interface through which a user can specify ticket prices for selected seats through the seat map; calculate a potential income for the event based, at least in part, on the specified ticket prices and seats at the event venue that will be offered for sale; allowing the calculated potential revenue from the event to be displayed on the user terminal; accessing the memory and allowing a list of a plurality of price levels to be displayed, in which a certain price level is related to a subset of seats whose tickets are to be offered for sale; allow the display of a ticket price associated with the seats in a first price level; allow the visualization of how many seats are associated with the first price level; calculate and allow an income potential to be visualized for the first price level; allow a user interface to be displayed on the user terminal through which a user can modify a

IMPI

INSTIBITt? MEXICAN monetary value (for example, the value of the ticket and / or other charges télla ^ JWítbs the ticket (for example, service charges, commission charges, handling charges, shipping charges, etc.)) of the tickets associated with seats in a second price tier after one or more tickets to the event have been sold; calculating and allowing new revenue potential to be displayed for the determined price level based, at least in part, on an alteration by the user of the monetary value of the tickets associated with the seats in the second price level.

Described herein is a system for setting up a ticketed event, comprising: computer equipment; a non-transitory medium that stores instructions that, when executed by the computer equipment, cause it to carry out operations consisting of: providing a user interface through which a user can assign a first user an adviser or advisor role, a second user a decision-making role, and a third user an executor role, where the advisor has the right to provisionally change at least one adjustment in the ticket price and assess a corresponding impact on a potential income and present a proposal for the organization of the event corresponding to the decision-maker, however, the advisor it is not able to implement the change in the adjustment in the price of the ticket with respect to an event that is on sale; The decision-maker is empowered to review the advisor's proposal and approve or disapprove said proposal through the system; the executing agency has the ability to implement, through the system, the advisor's proposal if it is approved by the decision maker.

A method comprising some or all of the following acts is described herein: provide a user interface through which a user can assign a first user an adviser or advisor role, a second user a decision-making function, and a user an executor role, in which the advisor You have the right to provisionally change at least one ticket price adjustment and assess the corresponding impact on potential revenue and have a ticket proposal submitted.

IMPI

INSTITUTO MEXICANO Oí IA PROHtDA »> N» UST «l * l organization of the event corresponding to the one who makes the decisions, however, the advisor does not have the capacity to implement the change in the price adjustment of the ticket with respect to an event for sale; The decision maker is empowered to review the advisor's proposal and approve or disapprove it through the system; the executor has the power to put into practice, through the system, the advisor's proposal if it is approved by the decision maker.

BRIEF DESCRIPTION OF THE DRAWINGS

The aspects indicated above will be described hereinafter in conjunction with the accompanying drawings, provided to illustrate and not to limit the aspects described, in which identical designations point to the same elements.

Figure 1A illustrates an exemplary architecture based on a computer system.

Figure 1B illustrates an exemplary process.

Figure 2 illustrates an example user interface that allows a user to design an event and view a layout of the event.

Figure 3 illustrates an exemplary user interface that visually provides seat information.

Figure 4 illustrates an example of a user interface through which a user can vary ticket parameters and view projected results.

Figure 5 illustrates an example of a user interface that provides an event summary and a color-coded seating chart or map that provides seating and status information.

Figure 6 illustrates an example of a user interface that provides an event summary for multiple events and a color-coded seat map or graph that provides seat information and pricing information.

Figure 7 illustrates an example of a user interface of an event modeling tool 30.

<img file="MX350182B_D0005.tif" />

<img file="MX350182B_D0006.tif" />

Figure 8 illustrates an example of a user interface with a ____ tool — flex execution.

Figure 9 illustrates an example of a user interface with a distiller tool for sale.

Figure 10 shows an example of a price break report.

Figure 11 illustrates an example of a real-time sales map.

Figure 12 illustrates another example of a user interface, which provides, through a graph, substantially real-time information on the sales index.

Figure 13 shows an example of a price break report.

Figure 14 illustrates an example of a user interface for report specification.

Figures 15-19 illustrate examples of user interfaces for reports.

Figures 20, 21A-21Z, and 23-26 illustrate examples of interactive seating maps.

Figure 22 shows an example of a price matrix.

Figure 27 illustrates an example of an augmented reality user interface.

Figure 28 shows an example of a ticket sales process.

Figures 29A-H illustrate user interfaces for creating additional events.

Figure 30 shows an example of an event organization process.

DETAILED DESCRIPTION OF THE PREFERRED MODALITIES

Conventional methods of pricing tickets suffer from significant shortcomings. Conventional pricing techniques often set prices for certain tickets too low. That is, ticket buyers would have been willing to pay more than that price for the ticket. This undervaluation of the ticket therefore results in a loss of potential revenue for the ticket sellers, the performer / artist and the promoter. Often conventional systems for

<img file="MX350182B_D0007.tif" />

IMPI

INSTrn / TC MEXICANO DS LA »« OHEr> AD ΙΝΓ USTRIAL pricing of tickets overvalues ​​the price of tickets. That is, the ticket price is higher than what a sufficient number of ticket uuinpraduies are willing to pay out of the available ticket inventory or an adequate portion of the available ticket inventory. This overpricing of tickets, therefore, results in a loss of potential revenue for ticket sellers.

Also, conventional seating maps for venues that are presented in connection with ticketing tend to be static and do not allow important dynamic data in real time. Also, conventional seating maps do not consistently integrate or display relevant seating, ticket sales, and event information.

Certain embodiments described by way of example herein may address some or all of the shortcomings of the conventional techniques described above. Certain embodiments can be implemented by equipment, computer programs stored on some media, or a combination of equipment and programs. For example, certain embodiments may include software / program instructions stored on a tangible, non-transitory, computer-readable medium (e.g., magnetic drives / drives, optical drives / drives, RAM, ROM, or FLASH drives, other memory sticks). semiconductors, etc.), accessible by one or more computing devices configured to run the software (for example, servers or other computing device, including one or more processors, wired or wireless network interfaces (for example, cellular, WiFi, Bluetooth, IT, DSL, cable, optical or other interfaces that can be connected to the Internet), content databases, customer account databases, etc. ). Data storage media (for example, databases) may be used to store part or all of the information described in this document (for example, seat maps, price information, seat status, purchase information, information of tickets, etc.)

By way of example, a given computing device may optionally include user interface devices, such as some or all of the following:

IMPI INSTITUTO MEXICANO OSLA MONEDAD INDUSTRIAL one or more screens, keyboards, touch screens, speakers, microphones, mice, trackballs, touch mats, printers, etc. The computing device may optionally include a device read / write medium, such as a CD, DVD, Blu-Ray, tape, magnetic disk, semiconductor memory, or other optical, magnetic and / or state type communication medium. solid. A computing device, such as a user terminal, may be in the form of a general purpose computer, a personal computer, a laptop, a tablet, a mobile or landline phone, an interactive television, a set-top box attached to a screen. , etc.

Methods and systems for creating ticketed events and executing ticket sales are described here. In particular, certain methods and systems described in this document are configured to create ticketed events, set ticket prices, and implement ticket sales through interactive dynamic user interfaces.

An exemplary ticket system, configured to set ticket prices and / or sell tickets, is networked (e.g. via the Internet or other network) to the computer systems of ticket offices, promoters, artist representatives , event venue staff, social media systems, and / or potential ticket buyers. In this way, the ticket system can receive and / or allow information and / or instructions described herein to be displayed on the screen to one or more of the foregoing network systems and / or other systems.

Certain modalities receive and use information, such as event ticket sales information, event chronology, presence of other competing events, and / or other information to establish an initial price and / or to adjust the ticket price for the established event. previously. Certain modalities provide interactive seat maps configured to facilitate user understanding of available seats, prices, discounts, available seat packages, etc., allowing a unified view (including a graphical representation) of what can be a complex set of prices and promotions.

IMPJg

INSTITUTO MEXICANO (MEA HUMEDAD

With regard to the price of tickets, certain modalities of high granularity model in the pricing, optionally determine it, through statistical analysis and / or other model in combination with the flexibility / adjustment of the price level as a function of at least direct sales (percentage or number of tickets for the event actually sold). Such high granularity can be two or more times the conventional four pricing point granularity. For example, 8, 10, 16, 32, 64, or any other number of price levels can be used, where different seats or seat sections can be associated with different prices and where prices can be increased or decreased from a first price level. up to a second price level.

This increase in granular pricing levels allows ticket pricing to be set or adjusted to more precisely match user demand and / or anticipated user demand. However, certain modalities optionally set the granularity low enough to avoid or reduce operational inefficiencies and customer confusion (for example, no more than 64 price levels).

Certain modalities estimate demand and set ticket prices using pricing levels or event magnitude based on a number of characteristics that optionally include, but are not limited to, some or all of the following: the artist , activity of similar artists, recent activity in the metropolitan area or the day of the show or event. Certain modalities take into account the visibility in the place when setting the price of the tickets for a certain event in a certain place.

Furthermore, certain modalities combine events, such as sporting events, theater events, concerts or in a seasonal package or a partial season package. This package can include high- or medium-demand events and relatively low-demand events to improve ticket sales for lower-demand events. The conjunction can be selected to obtain a certain desired level of ticket sales for a given season. Demand can be measured by actual ticket sales for other events that

<img file="MX350182B_D0008.tif" />

IMPI

ΙΝΗΤΠΠΌ MEXICANO DE LA PROPIEDAD INDUSTRIAL involve a specific artist / performer (for example, a performer / musical artist, a sports team, a play, etc.) and / or involving a similar artist (for example, an interpreter in the same genre as the artist being offered).

For example, certain modalities perform models that are equivalent to sales indexes using automated tools that analyze the sales indexes of a certain event and current and / or previous comparable events to determine the probability that certain levels of seat / section prices may or cannot be fully sold at the current fixed price, and indicate if it is advisable not to change prices to exhaust the ticket or achieve other sales objectives and / or if certain events should be promoted together in packages. By way of example, an event can be determined to be comparable using one or more of the following factors and / or other factors:

The performer / artist (for example, is it the same artist?)

The genre (for example, is it the same genre of music?)

The places (for example, is it a place of similar size, is it an outdoor place, etc.)

Time of the year of the event;

Time of day of event;

Sales;

The existence of competing events or within a specified time interval and / or within a specified distance of the event (for example, a popular sporting event, a concert, a new blockbuster movie, etc.)

Furthermore, certain modalities address the challenge posed with respect to improving ticket sales, income and / or earnings represented by season tickets and retains (tickets for the artist, the promoter, or another entity, which are not available for sale to the general public). Subscriptions and tickets not offered for sale to the general public tend to consume a lot or most of the high-demand inventory in certain locations, and even

IMPI INSTITUTO MEXICANO OI LA PROPERTY traditionally, they are not appraised properly or put to the advantage at the right time. -Even in addition, certain modalities can be used to improve gross income, net income and / or the number of seats occupied / tickets sold. Certain embodiments may be used to reduce certain types of reselling activity (eg, reselling activities that might not be in the public interest, such as, in certain cases, ticket speculation).

Certain exemplary embodiments will now be described with respect to the figures.

Figure 1 illustrates an exemplary architecture. A computer system 102, which may be a ticketing system, may be in the form of a server hosting the program code configured to execute the processes described herein and to allow one or more of them to view it over a network. more terminals (eg, client computers 112, 114, 116, 118, 120) of some or all of the user interfaces described here. In addition, system 102 is configured to receive user requests or requests, instructions and / or data provided through the terminals, carry out user requests and / or instructions, and access data from and store the data in one or more data storage means (for example, location database 104, price database 106, ticket database 108, user account database 110, the database of the social network, etc.). System 102 may be coupled to terminals and / or other systems through one or more networks 112. By way of example, terminals may include some or all of the following:

A local operator terminal 112;

A ticket office terminal 114;

One terminal of promoter 116;

A ticket seller terminal 118;

A ticket buyer terminal 120.

<img file="MX350182B_D0009.tif" />

IMPI

INSTITUTO MEXICANO £> £ THE PROPERTY

System 102 allows a user to define a performance or move it to a location for an event (eg, to host the event). By ojomE as described in greater detail herein, various user interfaces are provided through which a user can define the price of tickets (e.g., price levels) for individual seats and / or groups of tickets. seats (for example, price discounts). In addition, certain modalities allow the user to model the impact that various ticket prices have on the sale of tickets and income for an event. For example, as described in more detail below, a user can change the price level for one or more groups of seats, and the system will calculate an expected effect on ticket sales and revenue (for example, from tickets). ticket sales and / or concessions). Then, the system will generate a report that is shown to the user that informs him about the projections.

The system can generate a detailed summary for executive review, which can then be transmitted to (and / or printed and provided to) one or more designated recipients (e.g., whose approval (s) is / are necessary in order to to implement the organization of the event or changes to it), whose approval or disapproval can be registered by the system. The system can also store and keep a record of certain or all changes made in the organization of the event. The approved detailed abstract may be physically and / or electronically stored with or in association with a related contract (eg, a contract between the ticket seller, venue, promoter and / or artist / team).

Certain modalities allow a user to designate and store a classification for each seat, block of seats, sections and / or other seating areas (for example, in which the user can select a seat displayed on a seat map and enter a classification code, such as a number, or when a formula can be applied for each seat that takes into account the distance from the seat to the stage or performer, the angle of view to the stage, seat height relative to floor / stage and / or other factors). The classification may correspond to a quality classification

<img file="MX350182B_D0010.tif" />

objective or subjective (for example, where a front row, a center seat, may have a rating of one, and where a more atfésrerret-'rrivettfe · seat higher seats may have a rank of 18,000). This ranking can be used to designate the order of sale of seats by the system (for example, in response to requests for best available seats, when a user requests a ticket for what is designated as the best available seat). The seat classification can also be used for classified seat auctions, as described elsewhere in this specification.

Additionally, system 102 receives essentially real-time ticket sales information for one or more ongoing events, and reports the information to a user (for example, reports a ticket sales index for the event, the number of tickets sold , the number of unsold seats, the number of occupied seats, the percentage of seats sold, a projected time for tickets sold out, visits to the event website, conversions of the event website in sales, cumulative sales per day as a percentage of original net capacity, gross cumulative audit per day, and / or other information described in this document). System 102 also has access to, and is configured to allow viewing of historical information on events that have concluded, including some or all of the types of information provided by current events.

System 102 optionally uses ticket and seating price information for the event to provide user interfaces for viewing by ticket buyers. For example, user interfaces can display a color-coded seating plan, with icons, and / or with text to indicate seat availability, prices, if seats are wheelchair accessible, if a special code is needed to purchase a ticket for a seat, if the user has already purchased a seat ticket for the event, etc. The ticket buyer UI can allow a control through which the user can specify filtering criteria (for example, ticket price, display quality, if a special offer is available, if the seat ticket price is carried by a friend of the user,

IMPI ^

MEXICAN INSTITUTE

Dfe PROPERTY etc.), in which entries m ^ M ^ ualesyTcT sections of entries that satisfy the filter criteria will be highlighted in the user interface. Opoionolmento, the user can select (for example, by pointing to or clicking) an individual seat and / or seat section, and the ticket buyer user interface will access and display additional information about the seat (for example, if requires a special password / offer code to purchase the seat tickets, a seat number, a seat row number, a seat section number, ticket price, Ticket related charges, ticket prices with charges included, sight information, if alcohol is allowed, if the seat is in the shade, etc.).

Optionally, system 102 has stored permissions for multiple users. Permits can be specified by a general system of the event promoter. Permissions can be, for example, specifying who is allowed to see certain information (as part or all of the information presented in this document), who is allowed to change the properties of one or more items (for example, the price of tickets, discounts, waits, seating configurations, and / or other parameters described in this document), who is allowed to propose changes to who makes decisions, and / or who is authorized to approve the changes.

System 102 may be connected, via the network, to a system of a social network site 122. The social network site system 122 may include a database that stores user information, photos, event information, and user and other pages, and the connections between users and articles, such as shared content, tags of photos / videos (where a tag can be metadata, such as a keyword (for example, a person's name) or a term assigned to an information item, such as a person in a photo), friendship relations, etc. The system 102 may obtain information about the users of the system from the social network site 122. For example, the system 102 may request and obtain the names, the photographs, the identifications and the photographs of the users' friends, the information about user events, social ads, etc. The 102 Mexican institute system

OF THE ΡΗΟΡΙΕΓ'Αϋ

INDUHKIAL can also create events, in which users can see announcements about events and receive invitations to events through the social sisterrra-rtd'sfhcrcte'ta'red '' 122. In certain modalities, if a user responds to an invitation or indicates in which seats the user and / or friends will sit at the event, the system 102 can construct a message and transmit it to the system of the social network site 122 for display on a web page or other interface.

In this way, the computer system 102 allows events to be configured, projections and models can be made, information can be obtained in real time from various sources, analyzed and reported, and / or ticket sales can be managed and made through of interactive seating maps.

Figure 1B illustrates an exemplary process that can be performed through system 102 or other configured computer systems. In state 150, a user selects an event and / or location to be configured (eg, from a menu, by typing the event name and / or location name in a corresponding field). In state 152, the system accesses and / or generates a seat map of the place, which is provided for display in a terminal of the user involved in establishing price discounts, where the seats with a discount given in the price are listed identically or substantially identically. The seating map can be coded using colors, icons, text and / or animation to indicate various attributes (status, price level, etc.) of the seats and / or seating areas.

In an exemplary embodiment, at state 154, the user can specify price discounts by selecting, using a mouse, touch screen, or user interface, a section or group of seats displayed through the seat map, and assign a price discount identifier for the section or group, (for example, group A, group B, or Group 0, Group 1, etc.). Optionally, a user interface is provided through which a user can textually enter user identifiers (e.g. section identifier, row identifier, individual seat identifier) ​​for a first seat and a last seat of a discount at

IMPI ^

MLXICANO INSTITUTE

FROM THE PROPERTY the price to thereby define a discount for the first and last seats, and intermediate seats. Optionally, the user can grant seats in or out of a price discount as “on hold” seats (not for sale to the general public). Examples of interfaces for setting price discounts are described in greater detail later herein. Optionally, a user may assign ratings to seats, seating blocks, sections, and / or other seating areas, which correspond to the quality or anticipated interest of the related seating block, sections, or seating areas.

In state 156, creation of the event is performed. In an example modality where several price discounts are to be established, an event is defined, in part, by price discounts, where a certain physical section and the price discount combination is assigned for an individual section . The number of sections (and the number of seats per section) can be used to estimate the available capacity of the event.

In state 158, a price matrix is ​​generated, establishing price levels for all or some of the discounts. Price levels can be generated, manually, automatically, or through a combination of manual and automated processes, based on preferences, historical information, and / or other parameters, such as some or all of the following:

Artist / performer preferences / experiences;

Promoter / organizer preferences / experiences;

Ticket seller preferences / experiences;

Media and / or ticket transfer. For example, some tickets may be transferable and other tickets cannot be transmitted. As a further example, in certain modalities, a ticket format may be configured to eliminate or restrict resales, such as when the ticket is a virtual / non-paper electronic ticket (for example, when an access right is assigned to a pre-existing document, the user must provide the credit card, debit card, driver's license, passport and / or an identification card of the user in order to enter the event, scanning the document and determining if an access right is associated with the document), a ticket sent by email or a printable ticket ^ tesüafgabíe, or it can be in the form of a physical ticket more easily transferred, such as a plastic ticket or paper made specifically to allow access to the event;

Current ticket sales information for the event and / or similar events; I

Historical ticket sales information for past events that have ended.

In state 160, the initial price levels and / or the sales sequence (s) are assigned to the price discounts, and the assignments are stored in memory. The sell order can be used to define the order in which seats / discounts are to be put up for sale, where discounts can be put up for sale at the same time, and certain discounts can be offered sequentially at a time. later.

In state 162, the event setup is optionally transmitted to one or more users for approval before offering the tickets for sale (for example, via an email containing a link that when activated, causes the recipient's browser or other viewer displays user interfaces showing the information to be approved). For example, authorization may be requested from the artist / performer and / or venue operator for review (for example, so they can review price levels, discounts, prices and specific capacities and seating availability, etc. .) In state 164, a determination is made as to whether the requested authorization has been received. If not, optionally, a follow-up communication requesting approval is transmitted to the user (s).

If the reviewer user has responded but has requested modifications to one or more elements (for example, the price levels, to the price discounts, to the assignment of the price levels for the discounts, to the sale sequence, etc. .), then in state 166 the various items can be set by the system, and the settings stored in memory.

IMPI

Optionally, requests for approval of settings can be made by one or more selected users.

Optionally, some seats or discounts may be designated as subject to price changes in the future, even after ticket sales for the event begin, and certain seats or discounts may be designated as fixed (not subject to change once ticket sales have started).

In state 168, tickets to the event are for sale (for example, through online websites, through mobile apps, through physical outlets, by phone, or otherwise) in accordance with the price set as mentioned above.

Sample interfaces for pricing tiers and event creation are described in more detail in this document.

Event setup user interfaces can be used during negotiations between stakeholders (e.g. artist / team, promoter, box office, ticket sellers, etc.) to configure the different possible models of the event, which can be used to estimate potential revenue and / or ticket sales given different configuration parameters (e.g. different number of price tiers, different ticket prices, different number of seats occupied, different number of seats removed, etc.). Once the ticket setup has been agreed upon, the setup user interfaces can then be used to provide basic instructions to the venue's and / or other entities' ticket offices on what is the setup of the initial event, and the tickets. They can be sold according to the configuration. The event setup user interfaces can also be used after tickets go on sale to dynamically change the event setup (for example, to change which seats are assigned to which price levels, the price value of unsold tickets, number of seats occupied, etc.). Certain modalities may include a data interface configured to receive dynamic pricing from a pricing engine.

<img file="MX350182B_D0011.tif" />

INSTITUTO MEXICANA Dt LA ^ R ΉΙΕΓ'ΑΓ)

<img file="MX350182B_D0012.tif" />

prices and are configured to change the price of tickets where changes can be reflected automatically ^Qn the licfa Hp ramhins___

An example of an event creation process will now be described in more detail. Price discounts are established for a specific event (s) and / or venue (s). As similarly described above, price discounts refer to pricing for respective sets of seats, such that prior to the start of the sale of those seat tickets, the open seats within a discount of given price will have an identical or substantially identical price. Optionally, one or more seats can be put on hold at a certain price discount.

Over time, or as the result of initial modeling, the price level associated with a price discount can be dynamically changed (for example, by a user or system authorized to change prices). For example, price levels can optionally be increased or decreased based in whole or in part, on ticket sales. For example, price levels can optionally be increased or decreased based on one or more of the following factors:

The number of tickets sold for the event and / or specific seating areas for the event,

The rate of sale of tickets for the event and / or specific seating areas for the event,

The number of tickets sold for other events with the same artist or for one or more similar artists,

The rate of ticket sales for other events with the same artist or for one or more similar artists,

Selling a specific seat or group of seats in inventory

The expiration of a timer or date / time alarm, and / or other parameters.

At the time of such pricing changes, the inventory of unsold tickets associated with a certain price discount may

<img file="MX350182B_D0013.tif" />

IMPJ eg be moved to a new price level and its price agtí £ SB ^^ &amp; aSwB ^ sold before those changes, and optionally available seats in the same row, in the same seating section (or other designated items in a data warehouse with an indication that the price level is not going to be changed for the event and / or as determined by a rule), when this inventory has been sold, they can be left at the price level at which they were initially sold (for example, to facilitate appropriate reimbursement and / or for customer relations).

An exemplary graphical tool, illustrated in Figure 2, is optionally provided throughout the system for display on a user terminal to allow a user (e.g., an authorized user who has appropriate permissions) to view and set discounts on items. prices. The tool can be offered by system 102. The graphical tool provides an interface that makes it easy to define and display areas of equal quality at the site, using, for example, color coding. Different colors can be used to reflect different price discount areas and / or different price levels applied to those discount areas. A price can be assigned to seats (for example, through a field that associates a color, individual seats, specified rows, and / or specified sections / areas) through one or more fields.

For example, red, olive green, green, blue, teal, orange, etc. can be used to indicate different price discounts. Optionally, more muted or pastel colors can be used to indicate relatively lower / lower grade seats, and brighter or primary colors can be used to indicate relatively higher / higher grade seats. Other visual cues can be used as well (eg flashing seat icons can be used to indicate much higher / higher grade seats).

For many paid events, certain tickets are held by the artist, promoter, and / or venue, so they are not generally available to the public (at least in relation to the initial ticket sale to the public). These tickets are

IΛ4 PJ sometimes referred to here as on hold or reserve i ^ w ^^ p ^ “on hold” seats are among the most expensive and coveted seats. - *

The handling of reserved tickets can impact sigrffiraW3Trrente ~ los - .. ticket sales income. This is because the initial hold setup is often not closely tied to event capacity and pricing decisions. In addition, the practice of reserved tickets often eliminates or reduces public access to the highest priced seats, where price adjustments for sale tend to be more relevant to meeting demand. Furthermore, although many reserved seats are eventually made available to the public (for example, because the reserved seat holder will not be using them), traditionally unused reserved tickets are often released for sale to the general public. too late in the event to be effectively acquired. Therefore, many of the valuable reserved tickets that are released go unsold, or have to be sold at a discount from face value or relative to the price at which they could have been sold at an earlier time. Also, due to lack of proper tools and inefficient late communication often reserved tickets are placed after capacity and p ricing decisions are made, leading to poor ticket sales.

In order to overcome some or all of the above challenges, certain embodiments provide modeling tools that allow price and capacity decisions to be made with concessions for the number of tickets reserved at a certain price level so that capacities can be appropriately expanded. (for example, additional seats may be added and / or certain reserved seats may be reassigned for sale to the general public) so that the public can access and purchase seats at more expensive price levels.

Figure 3 illustrates the graphical tool of Figure 2, with waiting or reserved tickets indicated visually (eg, in black). Thus, a user who is responsible for the allocation of reserved seats and the allocation of price discounts and price levels can i> ve ^ 'T & uiriaÍ € to concentration of reserved seats, as well as the price levels of adjacent non-reserved seats. This allows the user to quickly assess which seats should be designated as reserved seating, and to change such designations in order to increase revenue and / or access for the general public.

Figure 4 illustrates a user interface showing a high-level view of a seat map of the venue, color-coded to indicate price discounts and an editable performance calculation tool panel that lists price discounts. and several example parameters, which are discussed in more detail later. In this example, there are 28 discounts / price strata (although there may be a greater or lesser number of price variations), in contrast to the more than four typical price reductions.

The performance calculation tool panel in the example allows a user to specify a number of seats for a price reduction, the face value / price level of a ticket for a certain price reduction, the total cost of a ticket in a determined price reduction, and an estimated percentage of tickets to be sold for a given price reduction at a given face value / price level. Some or all of the above values ​​can also be read from a database (for example, by activating an import control to import a file, such as a CSV (comma separated values) format file, or they can be calculated (for example, through a prediction tool).

The performance calculation tool then calculates (for example, in response to a user activating a calculate control or automatically in response to a user using a parameter change) the total dollar value of the tickets that are predicted to sold for a given price reduction, the total gross potential based on the face value of the tickets, and a total gross potential based on the total ticket values ​​(although the tool may provide more or less information). The value or total price of the tickets is related to the price that would be paid by the buyer

IMPI INSTITUTO MEXICANO OE LA PROPERTY INDUSTRIAL of the ticket (for example, the face value of the ticket, service charge, shipping costs, etc.), or a subset of them. Generally, although not Thirteen times, the total price will be greater than the face value of a given ticket. The calculated values ​​can be exported to a file (for example, a CSV file) after activation of an export control by a user. Optionally, the reported percentage of tickets sold can be adjusted to take into account reserved tickets (for example, when reserved tickets are not included when determining the denomination of the following: (tickets sold for a certain price discount) / (total of tickets available for a certain price discount).

Certain modalities provide tools that bridge the time gap between reserved seat handling and capacity decisions by allowing reserved seats to be placed manually (for example, when a user can click on a group to indicate whether it is a reserved seat). Furthermore, such tools allow transferring bookings by their owners and selling them to the general public through the ticketing system to increase revenue, optionally, without the use of ticket brokers or resellers, who often buy and resell tickets. For example, certain embodiments provide a user interface through which an authorized user can select reserved seats through the interactive user interface and change the designation to a listing designation.

Figure 5 illustrates an example of a user interface that makes managing reserved tickets even easier. Optionally, in response to a user action (for example, clicking on or hovering over a specific seat icon, entering a seat identifier in a corresponding field, etc.), the user interface displays the information of the seat. Accessed from a system database. For example, the user interface can display the section, row, seat number, price level, price reductions and / or reserved statuses for the corresponding seat or group of seats. In addition, a real-time report is optionally generated, reporting, for a specific event or set of events, the total number of seats, the number

<img file="MX350182B_D0014.tif" />

total number of seats available, the total number of tickets sold, the number of seats reserved, the total number of inquiries (for example, tickets whose purchasing process has started but has not yet been completed, such as tickets for seats placed in a user's online shopping cart), the total actual gross, and the total potential goal (assuming all seats are sold).

Figure 6 shows another example of the user interface of a reporting tool that allows the decision maker to efficiently manage multiple events, providing the decision maker with direct access to the condition of a location entry (for example , the price assigned to a ticket for the seat, an indication of whether the seat is reserved by the venue or promoter, etc.) and to directly execute changes in the condition of the seat, through a seat map. Thus, in certain modalities, the decision maker can execute price changes directly, without having to issue requests for the status of others involved in the ticket sales process, such as those in charge of the box office.

Certain modalities facilitate the processing and visualization of data for multiple events, as well as the management of ticket purchase prices, price reductions, and reserved seats for multiple events. As illustrated in Figure 6, an example an online information distiller tool filters and / or aggregates ticket sales information and pricing information for multiple events. For example, the distiller can generate reports for multiple events including, on an event-by-event basis, and collectively across multiple events, some or all of the following information:

PL (price level) / PB (price markdowns) index;

The number of seats for which tickets have been sold;

The number of seats available (seats available for sale to the general public);

The number of QOpen (qualified open seats are seats available for purchase by public buyers who have an access code

IΜ ρ I specified or are using a credit card brand d ^ emwhadaK er number of reserved seats and ticket sales rate; _______________

An indication of the acceleration / deceleration of sales (eg increase, decrease, stabilization of the sale rate);

The date and time of the last ticket sale;

Tickets sold out PB / PL projected;

The release rate / percentage of the event (in which certain seats can be shown as reserved seats or seats sold until the sales index reaches a certain or specified threshold, at which point all or some of these seats have their change of condition or status to open or open qualified (for example, tickets are released for sale to the public). This technique allows an event whose sale is slow to appear more popular, showing not as many seats available at any given time); I

The event rate (as described similarly with respect to Figures 21P and 21Q, the event rate can be used to determine what type of user interface to display and / or the mechanism to allow users to specify tickets want to buy).

Additionally, a user can specify a watch list, which is then stored in memory. The system accesses the user's watch list, and then adds and reports the status of ticket sales for an event added to the watch list by the user. For example, the watch list report may indicate some or all of the following and / or other information:

If the event is sold out (for example, based on the number of seats available and the number of tickets sold);

If the event will sell out soon, such as within a specified period of time, such as within 12 hours, 1 day, 1 week, or another specified period of time (for example, based on the number of seats available, the number of tickets sold, and the rate of ticket sales);

If ticket sales for the event are moderate (for example, based on the number of seats available, the number of tickets sold, and / or the rate of ticket sales);

IMPI ^

MEXICAN INSTITUTE

OF THE «REMAIN

If ticket sales for the event are slow (eg, WTOfciorFiElenumber of seats available, the number of tickets sold ^ íZaJaUtasa-da. Ticket sales);

The PL price level for the event;

The PB price reductions for the event;

Openings;

The sales rate for the event;

The number of tickets sold for the event.

Similarly, the watch list report can generate and present the information for all ongoing events that are monitored, or a subset thereof, including some or all of the following information: the status of ticket sales (for example, sold out, almost sold out, moderate, slow, etc.), the PL, the PB, the number of openings, the percentage of available tickets sold (including or excluding reserved tickets), the actual and / or predicted date / time of a total sale of an event, an event release rate.

Optionally, based on the status of ticket sales and / or other information described in this document, one or more of the following actions can be taken (automatically and / or manually):

Reduce the number of ticket reservations (including determining which reserved seats can be offered to the general public);

Raise ticket prices for certain or all seats / price discounts;

Lower ticket prices for certain or all seats / price discounts;

Offering free or cost ticket upgrades, giving buyers relatively higher quality seat tickets than they would have selected to purchase,

Increase in advertising / marketing expenses related to the event;

ΙΜΡΙζ

INSTITUTE ,

Reduce advertising / marketing expenses related ^ c &amp; eoTFel e, and / or -

Select media / channels / targets / demographic segments for advertising / marketing for the event.

For example, if one or more reported information / data items meets a specified threshold, one or more of the above actions can be implemented.

Additionally, historical ticket sales information from past events and / or current ticket sales information for ongoing events can be used by a prediction tool to determine the effect (for example, what would happen in scenarios) to raise or lower ticket prices on the overall potential gross sales and / or to determine the risk that the amount of gross sales or other sales will fall below a guarantee made by the ticket seller to the place, the interpreter, the promoter and / or another entity.

Figure 7 illustrates an example prediction tool user interface. A user can select predefined report formats that specify what data is to be reported and the presentation format. For example, a report can specify the total number of seats, the total number of available seats, the total number of tickets sold, the total number of reserved seats, the total number of inquiries, the actual total gross, the potential total gross, and a what would happen if the total gross ”. The "what if total gross" can be calculated based on a user specified what if the nominal value (in which the what if the nominal value can be specified to be higher or lower than a current nominal value), in the than the what if the value can be specified over the network. The network can also be used to specify and / or display a price level, the category of the seat, the type of seat (for example, adults, children, open, etc.), a face value, a number of seats, a earning potential and real income. A navigation control allows a user to specify whether to view all or an enlarged part of the seat map.

<img file="MX350182B_D0015.tif" />

<img file="MX350182B_D0016.tif" />

When an event has been completed (for example, after holding a concert that is part of a tour de-eeftdertos ^ fénjñ artist or after a sporting event), the data prior to the event and during the event can be saved in a centralized data medium and optionally used to make decisions on the remaining dates of the concert tour or sports season, and / or the data can be extrapolated for use with a similar tour. For example, as described elsewhere herein, the data can be used to tag prices for one or more price reductions, to determine venue seating configurations, to determine how many shows to schedule in a given venue for a performer. to determine which acts should be scheduled together for a given event (for example, to choose an opening act for a main act), and so on.

An example flex execution tool will now be described, with reference to FIG. 8, which illustrates an example flex execution tool user interface. Controls are provided through which a user (for example, a promoter, artist or licensed entity) can change the price of a specific seat or set of seats (for example, for a price reduction). For example, the user can specify that the price level for a particular price markdown is to be changed to another predefined price level. As an example, there may be 32 different predefined price levels, and the user can change the price level for a given price cut from price level 15 (for example, $ 28 per ticket) to price level 16 (for example, $ 32 per ticket). The tool calculates and displays the impact that the price change will have on revenue (for example, the net impact on gross potential), optionally in near real time. In relation to the revenue impact report, the tool can report how many seats were affected by the instruction to change the price level, the previous price level, and the proposed price level. In this way, the flex execution tool can be used by a user, such as a developer, to modify the levels of

T NA PI i prices based at least in part on the information received-eFmohitdteí INSTITUTO MEXICANO tools described in this report, and immediately notify the user of the effect of said modification.

<img file="MX350182B_D0017.tif" />

Figure 9 illustrates an example of a user interface with the distiller for sale tool, similar to that illustrated in figure 6. The user interface with the distillation tool for sale is configured to report, optionally substantially in real time, information regarding current ticket sales, as well as historical ticket sales information. The user interface includes a notification area that alerts the user to actionable pricing recommendations (provided by another user and / or automatically by the system). For example, the recommendations may be based on the sales rate and / or total information for an event and / or one or more selected seating sections of a venue from one or more current and / or past events.

The example user interface with the distiller for sale tool optionally includes a user interface for a watch list. A user can add one or more areas of interest for one or more events. For example, the user can specify what information (for example, the sales rate, the number of available seats, the number of tickets sold, a report on whether the price reductions / price level are out of stock, if the sales are moderate , if sales are slow) relative to price level 1 / price reductions 3, price level 2 / price reductions 5 and price level 2 / price reductions 7 will be continuously updated in the list area of vigilance.

Certain pieces of information, such as alerts, can be visually highlighted (for example, a bright color, a highlighted graphic, a flashing symbol or text, etc.) to better capture the user's attention. For example, certain data can be color-coded so that the information or modification thereof will be emphasized to capture the user's attention. For example, a sold or out of stock alert can be color coded blue, a sold or out of stock alert can be color coded.

IMPI ¿3 ^

MEXICAN INSTMITO • S LA UtOHEOAD orange, a moderate alert may be a yellow color code.³^^ slow sales alert can be a red color code and πτΓ'ΐΐΕΐ ^ ίϊαπΊΐ *⁰

An area called all items reports information on additional events, price levels / price reductions, etc. For example, the all items area may report some or all types of information provided through the watch list report and / or additional information, such as percentage of tickets sold, projected date / time for total sale (if any) of all applicable tickets, event ticket release rate, etc. The user can specify to the system that the report should be ordered based on one of the types of information.

As mentioned above, the user interface with the distiller for sale tool optionally also plays back historical ticket sales information, allowing the user to view sales patterns and trends. At the distiller, this sales information can be displayed and viewed with numbers and projections that are indicated independently, allowing a user to view seats by changing their status on the map.

A pause control is provided, which allows the user to pause the updating of the reported information, allowing the user to analyze the information at a given time. The user can then resume the update to allow the update to complete.

Figure 10 shows an example of a price markdown or discount report. The report indicates, for a given price cut, the price level (s), the face value at a given price level, and the entire face value (for example, the ticket value plus taxes and service charges) in a certain price level. An audit data stream on the system includes information on the number of tickets sold at each price cut and at what price levels. This provides the user with a historical record regarding the effectiveness of the price easing.

Information can also be provided in real time (for example, accurate to less than 2 minutes or another period of time, such as less than 1

<img file="MX350182B_D0018.tif" />

IMPI g minute or less than minutes). The real-time information will show where tickets are selling quickly and / or slowly so that prices can be adjusted appropriately. For example, if certain areas have ticket sales less than a desired amount and / or at a lower speed than desired, the user doing the pricing can adjust ticket prices down in specific areas to stimulate and increase ticket sales. By way of example, certain modalities include a substantially real-time graphical sales report that shows some or all sales on a graphical seat map.

Figure 11 illustrates an example of a real-time sales map. The illustrated real-time sales map shows substantially current sales information on a location map with a legend showing sales, openings and / or reserved numbers. Information may be provided on a rebate basis by price reduction, and / or section by section of seats and / or for the entire event on the percentage of tickets sold, openings and / or reserved, the pace of ticket sales, the acceleration or deceleration of ticket sales, a projected amount of time for available tickets to sell out, the rate of sales of a price or section cut relative to the entire event, etc. Individual seats can be color-coded to show the status of sales (although text, graphical, and / or other indicators can be used to show the status of sales, price adjustment, etc., other alternative or additional indicators can be used ).

Figure 12 illustrates another example of a user interface that provides, through a graph, information of the sales rate substantially in real time. In the example illustration, a ticket sales rate for a first price cut (PB2) and a ticket sales rate for a second price cut (PB3) are represented by the system. Ticket sales rates for fewer or more price reductions, price levels and / or events can be selected by the user and then graphically represented by the system. In addition, the example user interface verbatim provides additional information for one or more price reductions, price levels and / or

<img file="MX350182B_D0019.tif" />

INLUSTRIAL events. For example, some or all of the following information may be displayed:

Quantity of tickets sold, open and Qopen (qualified open, which can be an attribute that is applied based on the status of the seats, in order to sub-assign inventory to the public, in which a user has to enter a promotional code or password, or use a certain brand of credit card to qualify for a qualifying open seat;

Number of reserved tickets, the percentage of tickets sold, the time / date of the last ticket sold;

The sales rate (for example, tickets per minute), and a report on whether the sale is accelerating, slowing down, holding steady, etc;

Date / time projected sold out or sold out;

Projected date / time of sales stagnation (in which the system can extrapolate from a current sales rate and template curve to an expected sales curve (for example, a decomposition curve, which can be selected on the base of historical sales profiles of a similar event), fit the curve through the data points of the event's ticket sales, and if sales fall below a certain threshold, project when the pace of sales will fall below a certain level, such as event ticket sales close to zero per day or another relatively low rate that indicates ticket sales are stagnating);

Event release rate.

In addition, the user interface illustrated in Figure 12 provides a user-defined watch list and an information display of all items, similarly as described above.

A detailed report on sales / price ranges, such as the one illustrated in figure 13, can be generated, providing, for a given price reduction, price level and / or section, percentage of tickets sold, open, and / or reserved, the pace of ticket sales, acceleration or deceleration of ticket sales, a projected period of time when available tickets are going to sell out, the sales rate of a rebate or price section relative to the entire event, etc. In addition, it is ρΓοροΓοίοηβ ^ οόηνοίθδ ^^^ through which a user can instruct the system to add a graphic to the_______ user interface illustrated in figure 12 in the watch list or in a particular strip (for example, where a user can select a price level for which sales activity will be displayed essentially in real time).

Figure 14 shows a user interface through which a user can specify a period of time during which the sales rate and / or other information should be graphically represented or reported. In addition, an interface is provided through which the user can specify that price reductions with a higher than specified percentage of sales (for example, the percentage of seats sold at a selected price level that are to be ignored / not report (for example, if there are almost no or no seat tickets available at the selected price level).

Other reports (provided substantially in real time and / or with a delay, not in real time), may include charts of, for one or more venues and / or one or more shows at a particular location;

Visits to the website on a day-to-day basis (or other period of time), an example of which is illustrated in Figure 15;

Web page conversions (where a visit to the web page resulted in a ticket sale), an example of which is illustrated in Figure 16;

Accumulated sales per day as a percentage of original net capacity, an example of which is illustrated in Figure 17;

Gross cumulative audit per day, an example of which is illustrated in Figure 18;

Average daily ticket sold price, an example of which is illustrated in Figure 19;

As similarly described above, the charts can optionally include charts for multiple venues for events associated with a given performer and / or for multiple events / shows at a given venue, allowing a user to visually compare ticket sales for various venues and adjust ticket prices conveniently. For example, graphs provide metrics to stakeholders ^ J ^ íft ^ p;

in setting the price of tickets (for example, artists, promoters, venues) to allow an understanding of the development of events and OoFHo price changes and inventory management affect sales. Thus, in certain modalities, a user can simultaneously view sales and / or other event data for several events.

Additionally, reports can be generated that indicate the number of tickets sold, the gross total, and the average price per ticket sold, and the number and / or percentage of tickets resold for a certain section of the venue (for example, floor, lower 1, lower 2, upper 1, upper 2, etc.).

In this way, costs and seat price reductions can be dynamically configured using the interfaces mentioned above. Optionally, in addition to or instead of, the following techniques can be used to set price reductions. In the exemplary embodiment, where there are multiple price reductions or discounts, an event is created from the discounts or price reductions within a certain physical section and combinations of discounts that are assigned to a block of individual seats. A block of seats is a group of seats with certain identical attributes (for example, the same price level, near the same exit door, that has the name of the same section, in the same area of ​​the venue, in the same row, etc.). Therefore, a seating block may be smaller than a physical section of the venue (for example, it may be smaller than the venue's orchestra, hall, or balcony sections). Different price levels can be assigned to different blocks of seats. Having more blocks of seats than physical sections of the venue allows for a higher degree of granularity in the prices of the sections, and thus allows multiple blocks of seats to be more appropriately priced. Optionally, the seat blocks can be large enough to handle all the seats that could potentially be added to the manifest with those seats being in an open state. So, for example, if a venue event has around 280 degrees of visibility above the stage, with around 80 degrees behind the stage

IΜ Ρ1

INSTITUTO MEXICANO zí

FROM THE ΡΚΟΡΙΜΟαΓ. · Completely locked, the backstage seats βϊίέδϊέη marked as unavailable, the front-stage seats may be ______ marked as available, and the seats at the boundaries between the available and unavailable areas may be marked as provisionally available or provisionally unavailable, subject to review by an appropriate authorized person (who can verify whether or not the scene is visible from the aforementioned boundary areas). Therefore, there may be enough defined seating blocks to maintain seating in the aforementioned boundary zones.

In addition to the process of defining seat attributes (for example, common attributes, such as price level, venue area, etc.) for a given block of seats, the price reduction identifier can be placed in a field of sub-price levels (also referred to as a field of markdowns or price discounts). The Price Reduction Levels field can be used to indicate which sections or specific seating areas at the same price level are to be reported separately with respect to ticket sales and / or ticket availability. For example, if the seating in a balcony area and the floor-level seating are the same price, a sales report that asks for information on the sales of $ 100 seats can skyrocket sales in the balcony areas and at floor level. floor. The number of seat blocks generated is recorded and this information can be used in estimating the event capacity available from the venue / event data structure. After an initial price has been established, the sell order of the seating blocks can be determined.

Optionally, the seating blocks are defined or moved so that the seating blocks in sequence follow the venue's specified or natural selling sequence. For example, entry blocks can be assigned numbers in sequence if the corresponding entry blocks are to be put up for sale sequentially. Optionally, the process is automated using a pre-existing chart with a given physical section assigned to a unique seating block identifier. Furthermore, the seating blocks can be defined in order to allow greater control of the sales order.

WICKED

Optionally, a unique identifier can be assigned to _ INDUSTRIAL specific seat including any associated discounts, thereby allowing a user to request a report on the Unique identifier of the defined; ---- where a report is generated for the actual net price . In an example embodiment, once the initial setup of the event is done, a pricing matrix can be defined.

A set of price levels is optionally set using event modeling statistics, artist / promoter representative experience, and / or any other information, in combination with the price markdown or discount setting tool. Optionally, a range of price reductions can be established based at least in part on artist preferences or specifications. Optionally, some or all of the seats and / or price reductions can be designated for paperless ticketing (for example, where a paperless ticket is associated, through a database entry, with an identification element of the user, such as a credit card or driver's license, which can be used to enter the venue). For example, certain seats may have a relatively low ticket price set, but may be designated as paperless ticketed only to ensure that tickets remain in the hands of the true fans who will actually be attending the ticketed event, rather than fall for ticket sellers or other people who buy tickets with the intention of reselling them. By way of further example, other more expensive tickets may be designated as paper or paperless tickets, in which the ticket purchaser can select their format.

For example, as also described above, the illustrated user interface tool can display, using color coding and / or other notation to designate price reductions, reserved seats (for example, seats reserved for the artist). , for the promoter, the venue and that are not available for sale to the general public), the seats related to the sale of paperless tickets, etc. The user interface helps the person (s) entering the pricing information to view groups of ^ 4jiftdw »icyN &lt;

potential gross and / or net income, as calculated by the system * ™ *¹

By way of illustration, the user can order by system ^ through the user interface iwcontrol, color the seats according to the price and / or by the price reductions or discounts. The user can order the system, through a user interface control, to calculate the nominal value / average price, the average total value / price and the expected number of available seats and / or the expected number of seat tickets to be will sell. The user can instruct the system, through a user interface control, to calculate the total gross potential value of ticket sales for the event based on the face value of the tickets and / or the total value of the tickets (the face value of the ticket plus expenses and service charges).

Optionally, a user-editable table is provided to define a price matrix. The table includes rows for a given price cut, and columns that include values ​​for the number of tickets in the price cuts, the face value of the discounted tickets, the total value of the discounted tickets, the percentage of tickets that expected to be sold, and the number of tickets expected to be sold, and the total value of tickets expected to be sold (for example, full face value and / or full or all-inclusive value). The user can modify one or more tickets (for example, the face value and / or the percentage of tickets that are expected to be sold), and the system will calculate the resulting values ​​(for example, the new total sales for a certain price reduction, new potential total gross sales of nominal price and / or total price), etc. Optionally, controls are provided through which the user can enlarge or reduce a given seating section on the seating diagram.

Optionally, the system stores rules and permissions that are used to determine who can change ticket prices for a given event, venue, performer or team, and / or promoter, as similarly described above. For example, in certain cases, an applicant's price changes may be required to be approved by the ticket office of the

<img file="MX350182B_D0020.tif" />

place (or other entity). Optionally, the user, such as

M LA FROWEDAO artist or promoter, can introduce price changes, such as p8F^r^ fémpl &amp; ', through the visual map. Price changes are automatically converted to.

an electronic message (optionally after receiving a corresponding instruction from the user). The electronic message is transmitted over a network to the box office system. The message can be stored in memory in the locker system for later retrieval and / or the message can be viewed through the locker system when received. An authorized user at the box office can retrieve and view the message, and can then approve or deny the requested price change. Optionally, a message regarding approval or denial is automatically transmitted to the requester.

If the price change is approved, the approval is communicated to the ticketing system and the price change is reflected, optionally, essentially immediately (for example, in less than 15 minutes, in less than 10 minutes, in less than 5 minutes, in less than 15 seconds, in less than 5 seconds) online through web pages presented to potential ticket buyers. Therefore, certain modalities allow the rapid approval of ticket price changes and the publication of the same to the online ticketing site.

In certain embodiments, prior to the final event creation, a matrix can be created, such as the example matrix illustrated in Figure 22. The example matrix is ​​configured to indicate the price level that can be initially assigned for sales or price discounts. In addition, a list of potential price levels to which a price reduction or discount could be applied may be indicated.

The number of possible price markdown / price level combinations may optionally be limited by the number of sections at the site and the average number of price markdowns per section. The limitation of a particular event can, in certain circumstances, be difficult to predict before actually setting the event, so optionally the process is performed in

IMPI iterative way. An estimate can be given based on the free seats. Price levels can be assigned to some or all of the seating blocks.

Optionally, the initial event setup for a venue may require it to be reviewed and approved, by the performer, the event box office, or another entity. The authorization can be viewed through a terminal of the person issuing the approval, and the approval or disapproval of the event configuration can be received through a network from the approver's terminal stored in memory in relation to the initial configuration of the event.

Figures 29A-H illustrate additional examples of user interfaces for creating a ticketed event. Figure 29A illustrates an example opening user interface that can be populated using data accessed from a ticket system database, and in which the values ​​can be calculated (for example, via the ticket system and / or the user's client computer). The user interface in the illustrated example includes the following functional areas (although other modes may have fewer or more functional areas): a reporting area or reports, an event data area, and a seating map area, and a reporting area. change list.

The reporting area (on the left side of the example user interface), displays the following information in summary of the event levels and / or other information:

a name of the event;

a system that saves the event model;

a date and time of the event;

an event location;

performance data, including:

the total number of seats available (for example, if ticket sales have started, the total number of seats available to the general public, and if ticket sales have not yet started, the total number of seats that will be made available available to the general public, optionally including seats that are almost open in the sense that an offer code may be required · νγτγππ · ομ £ * χ> νο

OI LA «OFUDALl INDGfT» lAL special or a credit card associated with a certain brand / issuer panria purchase of tickets of respective seats); ---—------—_______ the total number of sold (the number of seats whose tickets have been sold, and are no longer available for the initial sale);

the total number of reserved (seats whose tickets are not available to the general public, even when ticket sales begin, but which could later be put up for sale to the general public (for example, tickets reserved for families of band members or for other private distribution));

the total number of deaths (seats whose tickets are not going to be sold due to a physical impairment, such as the seats that are backstage and whose visibility of the artists is completely blocked);

the total number of inquiries (seats whose tickets are in the purchase process, such as those that a person charges their shopping cart online, but for which the purchase has not been completed (for example, in which if the purchase is not completed within a certain period of time, the status of the seats will be changed to available so that others can buy the tickets)).

Total gross, including:

Actual gross ticket sales to date (the sum of the number of tickets sold times the actual sale price of the corresponding tickets);

Potential gross sales (for example, the sum of, for each price level, the price of a standard adult ticket at a price level to which the seat is assigned, multiplied by the number of seats at that price (where the actual gross may be different than potential gross where certain seat tickets are sold at a discount, such as at a lower rate), optionally assuming no dead seats, not including advance ticket sales of dead seats).

The event data area, in the lower left part of the user interface, provides a grid that presents, and allows the user to view, detailed statistics and allows the user to decide which data and statistics will go to the Mexican institute Oí LA PROPIEDAD INDUSTRIAL a to show. For example, a user can use column headings to organize and classify data. By way of illustration, the first Column can be used to define the classification base. As an example, in the user interface illustrated in Figure 29A, the first column lists the price levels (PL) by number (1,2, 3, etc.), and therefore the data is arranged in order price level. In certain modes, a user can click on a column heading so that the data in that column is used to determine the sort order.

A user can drag and drop columns to organize how the data is represented and, optionally, the classification basis. As illustrated in Figure 29B, the first column has been changed to seat status, and the data is sorted alphabetically according to the spelling of the seat status. In addition, the column headings include controls (check boxes) through which the user can specify what data is to be summarized. In the example illustrated in Figure 29B, seat status is selected.

Returning to Figure 29A, the event data shows a list of the price levels and the respective price levels, the following information is provided in the respective columns: Seat status (for example, available, reserved, dead, sold, in process of purchase, etc.) for seats at the corresponding price level, ticket values ​​(for example, non-discounted ticket prices) for the seats at the corresponding price level, the number of seats at the corresponding price level, the earning potential at the respective price level, and the actual income (actual sales) at the corresponding price level. Other example columns might include seat type, price discounts or rebates, description, qualified open seats, etc. The example user interface illustrated in Figure 29C includes a check box through which columns can be added or removed from the event data grid.

In certain modalities, a user can manually enter the data in a given field, and the system will calculate the effect on the data in other fields,

IMPiíj »

MEXICAN INSTITUTE

OF THE PROPERTY to allow a user to perform a hypothesis analysis. Pt ^^ Jémpl ^^ T user can change the face value of the ticket, number of seats, v / or the number of seats that have a specified status (for example, open, sold, reserved, dead), and the user interface it will be updated to reflect the effect of the change to other types of data, such as income potential. Thus, the user can see the effect of certain changes (for example, in revenue, profitability, the number of tickets that can be sold, etc.) and decide whether or not to apply the changes in practice.

Figures 29D, 29E, and 29F illustrate example filtering operations. Referring to Figure 29D, a user interface is provided through which the user can specify filter criteria, such as some or all of the following and / or other filter criteria:

From the price level (the current schema price associated with the corresponding entries);

Price reduction (set of logically grouped seats, such as seats in a certain common area, which can be moved as a set from one price level to another);

Price, a location group, section group, additional group (which can be used to specify other groupings of seats, when a given seat can belong to several groups, such as a lower level, a tier group, first side of the group base 3 group side of base, etc., where a buyer can specify a desired seat ticket by naming the groups without reference to a visual map (e.g. during a phone call with a ticketing agent or interactive voice response system boletoing), and where different seats within the same price level can be assigned to different groups for information purposes;

Sections (in which a certain section can be specifically named (eg section 101)).

The seating map and event data can then display / emphasize seating and related data that satisfy the filter specified by the

IMPI iN.srrnn »mj.xiCano user. Additionally, selected ^ '^ A ^ subtotales can be calculated in the event data area.

Figure 29E illustrates another example of a user interface, in which the user can specify one or more price levels of the filter operation. In the example illustrated, 3 price a level is selected. Figure 29F illustrates the results of the price level 3 filter operation. The seat map highlights, through colors, graphics, and / or icons, the seats that correspond to price level 3, and the event data only shows the data corresponding to price level 3, and does not show the data of the price levels of others.

Optionally, the filter criteria can be combined using Boolean functions (for example, AND, OR, exclusive-OR, no, and / or other Boolean functions).

Figure 29G illustrates an example user interface through which the user can select specific seats through a seat map and edit attributes associated with the selected seats on the fly. For example, a user can click or otherwise select one or more individual seats or a group of seats. The number of seats selected is displayed through the number of seats field in the dialog box. The user can change the price level associated with the selected seats (for example, through the action menu) and / or change the face value associated with the tickets for the selected seats. As a further example, the user can change the status of the selected seats (for example, between open, keep, kill, sold, etc.). Changes can be reflected in the change list area (for example, as a result of calculations based at least in part on changes). For example, the change list area can show the action (for example, price level changes, change seat status), destination (for example, seat identifier, price level, status), number positions, impact, change status, delete, etc. Changes can be stored in memory. Thus, the user can specify certain changes, see the effect on the event data, and then decide

IMPI ^ accept / implement the change, or reject / remove the rejection of changes can be stored in memory in association with the specified changes. Changes may be re-arranged and applied prior to placing event ticket sales and / or after ticket sales have begun. Therefore, the user interface can be used to dynamically change prices, seat availability, etc., for an event for sale.

In certain embodiments, the user interface allows the user to select one or more seats and assign the selected seats to a specific user account before or after other tickets are put on sale to the public. For example, in certain cases, an interpreter may indicate that tickets for certain seats will be assigned to the user's mother or father, without the specified seat tickets never being put on sale.

The administration of seat tickets for a given event can be divided among different entities, in which different entities manage different subsets of seat tickets for an event. For example, in certain modalities, the user interface allows the user to select one or more seats (for example, a subset, but not all of the seats place) and assign control / management of the selected seats (which can be initially assigned seat retention status) to a specified authorized entity, in which the specified authorized entity does not control or manage tickets for event entries. For example, in some cases a government city entity / may own a venue, but may hand over to an operator, who still maintains control over a relatively small subset of the seats (eg 200 out of 18,000 seats) in order to decide how to allocate seats (for example, visiting dignitaries, honorees, etc.) The government entity (or a third party) and the local operator can negotiate which subset of the seats are to be controlled by the government entity, and the agreement can be applied by a seat selection and allocation operator seat management selected to the government entity (or other party is specified). By way of another example, in some jurisdictions, while service providers

IMPI

MFAICAN INSTITUTE

OF LA ΡΚ'ΉΗΜί »industrial 7” gx multi-ticket sales may have the right to sell tickets for events in a certain location, multiple ticket-selling service providers can divide the seats of the venue, in which A certain ticketing service provider is assigned a certain subset of the seat tickets to sell. The seat map can be used to assign the management of / authority to sell tickets for subsets of respective venue seats of different ticketing service providers.

The seat map can be used to assign event alerts and / or weather alarms to individual seats and / or groups of seats. The event alerts can be related to a change in the status of the seat (for example, from open to sell, from several seconds to open, from killed to open, from open to dead, etc.). The event alert can be tied to a time criterion, in which an alert is provided only if an event occurs (or does not occur) within a specified time / hour.

For example, certain embodiments allow a user to assign an alert to one or more selected seats, wherein if a ticket for a seat associated with an alert is sold, an alert is broadcast to one or more specified recipients. By way of another example, certain embodiments allow a user to assign an alert to one or more selected seats, wherein if a ticket for a seat associated with an alert is not sold by a user-specified date (which may be a specified month / day / year, or in which the date will be specified with respect to the date of the event or the initial sale offer, such as 15 days before the event or 30 days after the seat ticket is on sale) and / or the weather, an alert (for example, in the form of an email, SMS messages, MMS messages, voice call automated, request notification, or otherwise) is transmitted to one or more specified recipients. The seats can be selected alerts such as the ticket sales seats for those seats indicate the overall performance of the ticket sales for the event. For example, the sale of tickets for certain seats may indicate that the sales are going well events /

LMPI

INSTITUTO MIXICAN '--- Say THE INDUSTRIAL PROPERTY satisfactorily, while the failure of those seats to sell on a certain date / time may indicate that sales are only slower-than-desired. Seat alerts can indicate to recipients which ticket prices should be raised or lowered in order to increase revenue.

More calendar tickets, warning alarms / timers (for example, with associated expiration times or calendared dates / hours) can be assigned to one or more seats (for example, a notice that certain seats initially assigned to the governmental entity will be reassigned back to the box office you will have to sell). A text message can be displayed by the system in association with the alert, the text message optionally identifying one or more entries associated with the alert and / or a message previously specified by a user (for example, a text message and / or graphics, including a reminder regarding seats, such as AC seats will be reassigned to today's box office). The user can specify one or more recipients and / or device / email addresses that are to receive the alert and associated message.

Figure 29H illustrates an example providing user interface of another mechanism through which the user can edit / change the seat attributes (eg to enable dynamic seat ticket prices). In this example, a menu is provided through which the user can edit / change the previously set face value of seats at a selected price level (for example, without moving by changing the price level to which the seats are assigned) . In addition, fields are provided through which the user can edit / modify tickets related to rates (for example, the cost of the service, the charges of the center, etc); impact per seat (in which the user can enter a delta change in the price of the bill, or in which the change is price / impact is calculated and displayed based on the change specified by the user in the face value field ), the impact on gross event (the delta / change in the gross expected event), etc. Changes can be reflected in the change area of ​​the list, which shows the action (for example, changes in price level, change status of the seat), destination (for example, seat identifier, price level, Asfatng) to | number of posts, impact, change status, eliminate. Changes can be stored in memory.

Therefore, the user can specify certain event changes, see the effect on the event data and reports, and then decide to accept / implement the change, or reject / delete the change. The acceptance or rejection of changes can be stored in memory. Changes can be made prior to placing event ticket sales and / or after ticket sales have begun.

While the user interface illustrated in Figure 29G allows the user to specify changes for specific entries selected by the user, the user interface in Figure 29H allows the user to specify changes more ambiguously (for example, via the box pop-up dialog or data grid event). For example, the user can specify that the 25 seats should be moved from one price level to another, without specifying specific seats that are to be moved to a different price level. The system can then calculate the effect on the event data. As another example, the user can specify a desired goal (for example, a $ 10,000 increase in gross revenue), and the system will calculate how many seats will need to be moved from a price level first to a price level second ( higher than the price level first) in order to reach the target. The user can specify any of the event tickets, as a goal, and the system can calculate one or more ways to reach the goal by varying one or more parameters, which can be displayed to the user.

An example configuration workflow event will now be described. Many entities and individuals who have different roles (e.g. advisor, decision maker, executor, etc.) and responsibilities may be involved in an installation event (e.g. in defining the physical layout of the event, the price structure of the event, in determining the number of positions filled or dead, etc.) For example, there may be one or more actors (for example,

IMPI

ΙΝΚΤΤΠΠΌ MEXICANO 'ru ta ptOFiEÍ-'AD musical performer (s), team (s), agent (s), etc), promoters, operators, box office venue managers, consultants, price dynamics generators, assistant managers, etc, involved in creating a ticketed event. Certain modalities described in this document allow various entities to carry out their functions with the corresponding rights and capacities to carry out the configurations, modifications, view data, etc.

As mentioned above, different users can have different roles. For example, some users may act as advisors regarding an event setup. Such advisors may have access to view event data, such as the one described in this document, specify interim changes (for example, in ticket prices, number of price levels, seating status, etc., to via a change list or otherwise), view the calculated results of such changes before the changes are actually implemented, save the changes in one or more log change proposed event files, and / or designate a change file as a recommended change file. The advisor can also recommend what type of tickets will be issued for which seats (for example, a physical ticket, an electronic ticket, and / or a virtual ticket). Therefore, the advisor may make proposals regarding changes to an event setup, but does not have the authority to actually instruct that the changes are implemented as an event for sale. Therefore, an advisor may have the ability to perform What-if analysis on several different event setups and offer recommendations on how the event should be setup for a decision maker (for example, an event promoter) who has the authority to approve such changes, but without that authorization, the event is not set based on the advisor's recommendations or saved change files.

The decision maker can view the file of the proposal (s) and then approve reject those changes and / or can make further changes, in which said approval, disapproval, and / or other changes are saved in memory. The decision maker can automatically be informed of a proposal

IMPI INSTITUTO MIXICANU DI LA PROPIEDAD INDUSTRIAL new or revised from an advisor through an email, an electronic notation file, an alert is displayed through one or more of the user interfaces described in this document, or otherwise. For example, an advisor can activate a control instructing the system to transmit a proposal to a decision maker, and the system can enable the decision maker with the proposal, which can include one or more of the user interfaces described in this document. .

After viewing a proposal, the decision maker can then instruct an executor (for example, a cash office) to apply the changes (for example, the list of changes defined by the counselor, approved and / or modified by the policy maker decision making). For example, instructions may be allowed through an email, an electronic notation file, an alert displayed through one or more of the user interfaces described in this document, or otherwise. The executor can then apply the specified changes (for example, using one or more of the user interfaces described in this document), and the event will be configured accordingly (for example, with the specified price levels, entry level prices, the values ​​of face ticket assignments, discounts, and / or user status, etc.) The executor may be endowed with a certain degree of discretion in application changes. For example, the decision maker can instruct the executor to move 25 seats from level 1 to price level 2, without specifying which of the seats in a price level are to be moved. The executor can choose 25 seats to be moved, and then move the executor-selected seats from level 1 to price level 2 accordingly. The decision maker can be automatically informed by the system when the implementer has implemented a change (for example, when the system detects that the user has instructed the system to implement the change, and transmits an electronic notification to the appropriate recipients). Tickets can then be put on sale to buyers according to the applied case configuration.

IMPI ^^

MEXICAN INSTITUTE λ _____. . . ... ..... MUFOM

As an additional example, as described antenormeiM ^ Tte ^ maTTtera— similar, some users / entities may be provided with the authorization for _______ ticket control and other configuration properties for a subset of event seats, but not for all event seating.

The assignment of authority to carry out and execute various tasks can be performed by a user who has the authority to assign functions and provides the corresponding authority to users to execute those functions, optionally on a case-by-case basis. The above tasks can be accomplished using one or more user interfaces provided through the ticket system or otherwise. The specified assignment of authority can be stored in memory in the respective user and / or event logs or otherwise.

For example, a given user may be provided with a userID and / or password to access the system, and the system may use the userID and / or password that identifies the user accessing the system, accessing a user and / or registration of event to determine the user's rights to access certain event data, to create event models, and implement event changes, and allow the user with the corresponding authorization functionality. Of course, other techniques can be used to validate a user and allow the user to log in, such as biometrics (e.g. fingerprints), smart ID cards, backpacks, etc.

Optionally, a given user assigned a corresponding role may be provided with the authority to designate another user or users who have a sub-authority to carry out all or some of the tasks that the user has the delegation of authority to carry out. . For example, a cash office manager can create an authority tree, where the cash office manager can authorize an assistant box office manager to make and / or implement certain types of changes (for example, change the status of a seat place to open), but others do not (for example, the ability to change face ticket values). As an additional example, a decision maker, such as

IMPI ^

INSTITUTO MEXICAN &lt;i

I heard THE PROPERTY promoter, you can delegate decision-making authority patcP'W others^- designated users. __________

Optionally, a particular user can instruct the ticket system for someone to whom the user has provided that sub-authority to grant new sub-authority with another user. Optionally, a given user can instruct the ticketing system not to allow someone to whom the user has provided that sub-authority to grant further sub-authority to another user. The system can then allow the user granted sub-authority with the specific degree of rights to view the data, experiment with the changes and / or implement the changes.

In certain modalities, the system can keep a record of each proposal and / or lists of changes implemented and can generate a report of the same with an associated timeline. In the report it can be seen that he proposed a certain change (for example, changes in the price level, price change, face price, place status,), that he approved the given change, that he has implemented the given change, when the tasks previous were carried out, and what the changes were n. Changes can be displayed graphically and / or text (eg, starting with a base event, and subsequent changes). Additionally, the history of sales activity can allow seat showing when tickets were sold, changes in ticket sales rates, changes in the absolute number and / or percentage of seats sold, etc.

The story can be presented statically, such as using multiple screen shots of text, tables, graphs, or otherwise in a physical or electronic report. As an additional example, the story can be allowed in a dynamic format. By way of illustration, the story can be played back like a movie (for example, an elapsed time movie where the user can control the speed of the story playing), with the seat map being sequentially re-colored to reflect changes in the order made, and the text likewise is continually updated to reflect the changes. The user can specify starting points and for the

IMPI

ΙΝΓΠΤΙΓΤΟ MEXICAN · DF. THE INDUSTRIAL PWOMerAD replay by specifying start and stop dates / times or events (for example, beginning when a first ticket price change occurred and ending just before a second ticket price change is produced, or beginning when a first certain percentage or number of seats were sold tickets, and ends when a second specified percentage or the number of tickets for the seats were sold) to focus all the more quickly on areas of interest.

Figure 30 illustrates an example of an event setup process that can be executed by the ticket system and / or another system. In the 3002 status, the entities involved in setting up an event (eg, an artist manager, promoter, hall operator, etc.) negotiate on the characteristics of a new event setup. In status 3004, an agreement on the physical stage / configuration event is specified (eg final stage, 360 degree stage), and the configuration can be stored in a record associated with the event. In the 3006 status, a high-level authorized user (for example, the highest-level executor, such as the locker manager) selects a layout / place template from a menu of corresponding memory stored templates of the specified physical configuration and creates a base event. The base event can be stored in the event log. At status 3008, the high-level authorized user / enforcer designates other users (e.g., ticket office staff) as enforcers, and designates another user, such as the developer, as the highest decision maker for the event and optionally for other events. The designations can be stored in the event log. The decision maker is provided with the authority to appoint other decision makers and advisers. In status 3010, one or more of the revenue event users model using the interfaces discussed herein (for example, by experimenting with different numbers of seats at each price level and different base prices at each price level ). In status 3012, the appropriate user selects seats via a seat map or otherwise, and assigns them the appropriate price levels and set the prices.

IMPI base prices. In status 3014, the above changes' &amp; ISbi ^ fl ^^

INtHNTR_1ALchange lists in the event log, which can be displayed to a user.

In the 3016 status, once the decision maker approves— the modifications (in which the approval can be stored in the event log), the decision maker instructs the implementers to make the actual changes in the event (for example, via electronic communication transmitted by the system). On status 3018, the event was put up for sale according to the event setup (for example, with tickets offered at the designated prices according to the specific event format, with full and undead seats being offered for the event). sale), and the system can process ticket sales orders and deliver tickets (for example, electronic, physical, and / or virtual tickets). In status 3020, the system displays sales activity graphically (for example, through seating maps, charts, etc.) and textual (for example, through the report and / or event data areas described above) , optionally in substantially real time. Users can configure filter or more to select what is displayed and reported. In status 3022, based on active event sales activity and / or other factors, users can generate additional changes reflected in the corresponding change lists that performers can upload to the ticket system during live sales.

Interactive seating maps will now be discussed in relation to illustrative modalities illustrated in the figures. As illustrated in Figures 20 and 21A-21Z, interactive seating maps of a venue and / or event can allow for display on network user terminals (e.g., telephones, personal computers, interactive televisions, or connected devices in network, etc) of potential ticket buyers.

A system, such as the ticket system described above, can access data from a database (such as one or more databases that store hall maps, seating and data maps, pricing data, event data, user account and preference information, social network information, photo tagging information, event invitation and

IΜ ΡI responses, other data displayed through the interfaces iflS ^ &amp; tíar industry described in this document, and / or other data) and use that data to populate the user interfaces, including interactive seating maps. Loé datar

<img file="MX350182B_D0021.tif" />

Populated can be dynamically changed in response to user actions (for example, in response to some or all of the following: user searches, specified preferences, navigation instructions, user selections, section selections, via purchase instructions, labeling instructions, control activations, etc.) User interfaces, including interactive seating maps, can be updated in real time substantially in response to user actions and / or in response to updated data, such as updating ticket prices, seat availability, seat status, etc., which was made or detected by the system.

In addition, in certain modalities, the system will allow information on the screen such as the distance from the seat to the seats of the user's friends who have tickets at the event (for example, expressed as a number of seats, rows, sections, and / or in a unit of length, such as feet, meters, or yards).

A given seat may have different types of tickets available (eg, adults, children, etc.). In certain cases, the different types of tickets for a given seat may be associated with different prices. Optionally, if there is only one type of seat available (for example, adult only or child only), and the user clicks on the seat to add the user's shopping cart seat or a list of the selected seats, the seat will be will add immediately. However, if there are several types of seat available, a user interface can be presented (for example, through a pop-up dialog), asking the user to choose the type of seat the user wants to buy before the seat. seats are added to the user's selected. A link may be provided in association with the additional information through which further additional information may be provided.

IMPI ^

Interactive seating maps can be trusted ^ user understanding regarding a case of available seats, prices, available discounts, seating packages, other seating features, which of their friends are present and where they are sitting, etc. ,, by, in certain embodiments, providing a coherent and / or unified view (including a graphical representation) of what can be a complex set of prices and promotions, and other seat and related event information. Furthermore, certain modalities may allow a user to select a seat or section, and have a photograph, video, or other representation (in two and / or three dimensions) of the view from the seat or section displayed to the user.

As illustrated in Figure 20, the user interface may include a navigation map, and in another area, it may include an enlarged view of a section of the venue indicating user-selected seats, user-purchased seats, seats that match the user's search criteria (for example, price range, seat section (s), seat type, special offer (s) specified by the user, etc.), the seats that are available, the seats that are not available.

Controls are provided through which the user can navigate the map and / or zoom in on a certain section of the map. For example, the map is configured to allow a user to click an area on a map and drag the map to change the map of the displayed area. In certain modes, even when a user clicks or selects another seating area mode or particular section, to thereby expand the view of the selected area, the entire place is still displayed in one area of ​​the map, with the seat indicated statuss (for example, via color and / or text). For example, if a user enters search criteria (for example, seats have a ticket price between $ 50 - $ 100), the user interface will highlight (for example, through color codes or other type) of the seats and / or sections that match the search criteria. If the user selects a certain highlighted section, the UI zooms the section

IΜ ΡI ¡^ nvro m_OR«.A * selected, while still showing an overview of the place (que'bYfédeSi ^^ reduced in size) in a corner or another place, i luí idu ~ Ia víjLq gonoml still highlights the seats / sections that match the criteria User search (for example, entries between $ 50 - $ 100).

Optionally, if the user moves the pointer (for example, a cursor) over a certain seat or seating area, or otherwise indicates a section of seat or seats (for example, by clicking on a specific seat or seating area). be), additional information is provided (for example, via a pop-up window or overlay) regarding the corresponding seat section or seats. For example, the additional information may include an indication of whether an offer code is needed, and if so, from what source, specific seating information (e.g., section, row number, seat number, price of the ticket, the type of ticket (for example, adult full price, discount for adults, children, etc.), an indication of whether the seating area only has individual seats available (and not two or more adjacent seats available). Other information, such as whether the seat is in a covered area or an exposed area, in the shade or in direct sunlight, the distance of the seat to a different exit, bathroom, concessions, parking and / or destination, how far the seat is from an aisle (for example, expressed as a number of seats and / or in a unit of length, such as feet, meters or yards), expected seat temperature during the event, if there is waiter service for the seat, and / or other information can be displayed as well.

As illustrated in Figure 21A, the user interface can include a map that graphically (for example, via a drawing or photograph a) represents a seating chart of the entire venue (optionally with different sections graphically indicated, through color-coded, and / or alphanumeric text), and a broader view of the venue showing individual seats, in which the user can move a navigation box over the table of locations of the entire property to select the area to be displayed in the expanded view. Optionally, the corresponding colors are

IMPI

INSTITUTO MEXICANO OE LA PHOMOAO used to indicate the status of the seat with respect to availability (for example, available, sold, waiting, etc.), but not to indicate price? which can be displayed verbatim. Optionally place, corresponding colors are used to indicate seat ticket price.

As illustrated in Figure 21B, the user interface can include a map in an area that graphically represents a seating chart of the entire room for navigation purposes (optionally with different sections outlined graphically, via color codes, and / or via alphanumeric text), and in another area, it shows an enlarged view of some of the seat sections that shows the determined sections in greater detail, but without optionally showing individual seats. As also described above, the user can move a navigation box over the table of locations of the entire property to select the area to be displayed in the expanded view.

In an example embodiment, such as the one illustrated in Figure 21B, when the map is zoomed out, showing the location map in a main area of ​​the user interface, the sections of the location may be color-coded (eg, light gray, blue, medium blue, and / or dark blue). For example, gray (or another color) can be used to indicate that a section is totally sold out or does not contain any seats that match the user's selected price range and / or ticket options. Blue (or another color) can be used to indicate that there are at least some seats within the section that match the selected user price range and / or ticket options. Variations of a color (for example, darkness or intensity) can be used to allow additional information. For example, the darker the blue, the more seats within the section that match the user's search criteria.

Depending on the size of the venue, the number of room seats, and / or the size and / or resolution of the user's screen, the interactive map can optionally show all the seats in one location at the same time, as shown below. Shine in Figure 21C.

<img file="MX350182B_D0022.tif" />

Other information can be stored in the system database and included in the interactive map. By way of example and not limitation, IcTftnina—- - of the seat, type of seat (eg, padded, no padding, backrest, no backrest, etc.), and / or angle of rotation of the seat can be included and shown . Information can be transmitted through a seat icon (or other indicator) using a corresponding interior color, outline color, interior symbol / text / character, color of said symbol, one or more orbit symbols that are optionally a color code, etc

In certain embodiments, the software application used to configure the interactive seat map intended for presentation to consumers for the purchase of tickets for the event is optionally the same or substantially the same software application used for the creation of events. In certain embodiments, the shadowing, encoding, and behavior of the user interface is controlled by a scripting language that is passed to the map allowing the behavior to be dynamically changed. For example, the scripting language can be used to control polygon representation for the map (for example, it can be used to indicate seating areas), seat representation, hover over message handling, and interface control. user.

The highly configurable example map can be configured as desired. For example, the map can be configured to display a scheduled ticket in a similar way to that of a calendar ticket (for example, a Microsoft Outlook calendar or Google Calendar ticket).

The map can be configured to allow viewing from the seat (for example, images, movies, photographs, graphical representations, etc.) For example, a user can select / click-on a seat / section and / or an associated icon (for example, a camera symbol), and the view from the seat or section are displayed. The image (s) may include one or more still images, a view from the seat, a view of the performance area venue, and / or a 360 degree immersive virtual reality or full sphere view.

INSTITUTE

Certain modes of the map are configured to show ^ ¡TTEMIC * sut> ^ content. For example, the image of the place can be modified to mn ^ trar, - selected advertisements based on the characteristics of the user (for example, the user's location, the object the user is viewing, etc) on the map itself (for example , on a playing field, stage, scoreboard, billboard, etc.) By way of illustration, the content may be a static advertisement that includes a static image and / or text, or a movie. Ads can be selected and / or served through an ad server operated by the ticket system operator, an ad dealer, or otherwise.

Optionally, the map can be hierarchical and you can insert hyperlinks. For example, the map can show a campus view, illustrating multiple buildings at the same time from a bird's eye or oblique view. If it is detected that the user is selecting (for example, via hovering or click-running) a building, including a venue used for paid events (for example, an auditorium or sports stadium), the interface Map user can respond by accessing and viewing a seat map corresponding to the ticket location within the selected building.

As an additional example and as illustrated in Figures 21 A and 21C, with respect to the seat colors, dark blue (or another color) can be used to indicate that the seat is available for purchase and matches the range of the seat. user selected prices and ticket options. Blue (or other colored) light can be used to indicate that the seat is available for purchase, but is outside the selected user's price range and / or ticket options. Gray (or another color) can be used to indicate that the seat is not available for purchase. Orange (or another color) can be used to indicate that the cursor is over the seat or the user has already added the seat for user-selected seats.

Optionally, in addition to or instead of coding colorants, if the map is being viewed through a 3D terminal (for example, a terminal that needs glasses to view the 3D image (sometimes referred to as active 3D), or a terminal

ΙΜΡΙ «^ ¡NiTITU '! O MEXICAN

OF THE INDUSTRIAL MOHEDAL that do not require glasses to view the 3D image), the amount of the 3D effect can be used to allow information. For example, the more that 'it matches' with the user's search criteria, the greater the 3D effect can be emphasized. By way of illustration, a matching section or seat may appear to project of the image by an amount corresponding to the degree of matching.

As illustrated in Figure 21D, changes to the interactive seat map can optionally be substantially updated in real time (eg, in 2 minutes or less). For example, changes in seat availability, user prices, user ticket sources, seat status, and / or other seat and related event information discussed herein, and so on, may be updated. in substantially real time.

Figure 21E shows an example user interface that includes an interactive seating map for an event. As also described above, if the user points to / hovers a cursor over a seat, additional information about the seat is displayed (e.g., seat location information, an indication of whether the seat is in shadow, price of the ticket, service charges, taxes, total cost, etc.) In addition, controls are provided through which a user can recommend the event to other people. If the user activates the recommendation control, the recommendation can appear on the page that the user of the social network, the social network page of the user's friends and / or notifications regarding the recommendation can be transmitted to friends of the user (for example, by email, SMS, MMS, or otherwise). Figure 21F illustrates an example user interface similar to that of Figure 21E. In this example, if the user points to / hovers a cursor over a seat, additional information about the seat is presented (e.g. seat location information, an indication as to whether alcohol is allowed in that seat, an indication of whether the view is a full view, partially locked through one, a full command view, etc.)

IMPIí ^

MEXICAN INSTITUTE

OF INDUSTRIAL UGLY

Figure 21G illustrates an example user interface that includes an interactive seat map and offer menu doñüü “CI UbUdiiu can select one or more offers related to seat tickets (and which can be restricted to specific seats or specific groups of seats) and / or seat classifications (for example, full price, children under 12) and the Interactive Map that highlights the seats and / or rest areas corresponding to the offers. If the user points to or flies over a corresponding rest area or through the offer, additional details regarding the offer can be presented. As an example, the offers may be sponsored by one or more companies / advertisers and may offer discounts on tickets, allow access to buy seats not available to the general public, or allow an auxiliary item (for example, food, clothing , parking, travel) at a discount or free with the purchase of a seat ticket.

In addition, certain modalities will show warnings or other information in certain situations that the user has to acknowledge viewing before being able to buy a ticket through the map. For example, as illustrated in Figure 21H, if a user hovers the cursor over or clicks on a seat that has an obstructed view, a warning regarding obstructed view may be provided for viewing through a window. pop-up or otherwise, and the warning may have an associated control (for example, a continue or agree control) that the user needs to activate before the system or user interface will allow the user to add the seat to the user's ticket seat list and / or before the user is enabled to buy a ticket for the seat.

Optionally, as illustrated in Figure 211, the user or system interface detects whether the seat user's selection of one or more seats would leave a seat chain in the row (one seat available alone, instead of two or more seats free adjacent seats), in which if the user selected a different set, but the same number, of adjacent seats in the row, there would be no braided seat, or there would be fewer sunken seats (for example, a

IMPI iNiinino Mexicana de LA f'KOPILDAD INDUSTRIAL chain instead of two sunken seats). If this situation occurs, a notification about the above can be provided to the user and the notification can inform the user that the user is obliged to or is asked to select a different set of seats in order to avoid or mitigate the occurrence. of the strand seats, as illustrated in Figure 21 J. The notification may specify or suggest one or more comparable sets of seats that eliminate or mitigate the number of sunken seats. The user can request that or required to activate a notification recognition control. Optionally, if the user does not select a different series of seats and / or does not confirm the notification, the user may be prevented from participating in the addition of tickets for the user's selected tickets and / or prevented from purchasing the tickets . Optionally, instead, the user may be enabled to continue with the seat selection or purchase, even if a braided seat occurs.

As a further example, as illustrated in Figure 2 IK, the system or user interface can detect whether the user has selected a set of seats (for example, two or more seats), where two seats are separated by a hallway or barrier (for example, a pole). The user interface may allow a warning regarding seat clearance. The warning may have an associated control (for example, a continue or agree control) that the user must activate before the system or user interface will allow the user to add the seat to the user's ticket seat list and / or before the user is enabled to buy a ticket for the seat.

Optionally, as illustrated in Figure 2 IK, a seat user's selection is displayed on the user interface than the map (eg, directly below the map). Optionally, a control is provided (for example, Show details control) to view additional details regarding the selected seats (for example, price, seat section, row, number, ticket type, total cost) , in which the user can modify the ticket list. The user can continue browsing the map or click on a check box to complete the purchase. Optionally, the seats

<img file="MX350182B_D0023.tif" />

IMPI

ΙΝ'ΤΤΠΠν MEXICAN

DE LA FROHEt'AD selected are not reserved until the ChSeRSW · control becomes active (at which point tickets can be reserved for a period of time). Optionally, if the user has not completed the payment process within a certain period of time, the payment process is terminated, and the tickets are no longer designated as reserved (although optionally they may still be listed in the list of seats of selected users), allowing other users to purchase the tickets.

So, for example, the user interface can report on the number of seats selected by the user and the subtotal cost (for example, the total of the face value of the selected tickets, optionally with any discount applied, optionally without any discount applied) . Optionally, the total cost, including any discounts, handling fees, center fees, taxes, and / or shipping costs displayed.

As discussed elsewhere herein in a similar manner, in the illustrated example, a field is provided through which the user can enter an offer code or password. Fields and / or a scroll bar are provided through which the user can set lower and / or upper limits for the ticket prices that the user is interested in. Optionally, if the system determines that an event has only one price of the ticket. standard ticket, the system will not offer a slider or other user interface to specify the price as search criteria. A field is provided through which the user can tell the system to highlight and / or only show the seats that are part of a special offer (for example, a pre-sale for a credit card holder of a certain company , or a fan club pre-sale).

In certain embodiments, as illustrated in Figure 21L, a user interface may be provided that allows a user to purchase or reserve a right (which may be represented by a physical or electronic ticket) to enter a location (such as a museum or amusement park ride) at a certain time or to use a facility at a certain time (for example, a golf tee time). The user interface can display a

<img file="MX350182B_D0024.tif" />

plurality of timeslots, with an associated add contr¿TfS »^ | $ ^ a plugin control, the associated timeslot is added to the user's list of selected timeslots or, in certain embodiments, directly to the user's purchase card. If the user points to a hovering or a cursor over a particular time list, the information relating to it can be displayed (for example, via a pop-up or otherwise). For example, the additional information can be a ticket time, price or a price range, number of tickets remaining for the corresponding time interval.

As illustrated in Figure 21M, after detection that a user hovers a cursor over or has selected a seat requiring a special offer code (for example, from a specific credit card company, from a club of fans, etc.), a notification can be presented through the user interface, the inclusion of an offer code source, a reference seat / identifier, a ticket price and associated fees, As illustrated in FIG. 21N, the user interface may indicate, through icons or otherwise, which seats are handicap accessible.

As a further example, if there are no tickets available on a given sales channel (an initial or primary sales channel) in a pointed section or the user is clicked, a notification can be provided as to the availability of tickets in the section through one or more alternative channels (for example, a second hand / secondary market channel, an auction channel, etc.) as illustrated in Figure 210. The notification may include a link to a purchase page or other user interface of the alternate channel (s).

Figures 21R-21U illustrate interactive seating maps allowing users to purchase tickets through an auction format and / or through which a user makes an offer at a user-specified price, which may or may not be accepted. by ticket sellers (eg, a major ticket seller market conducting initial ticket sales). Through the illustrated interactive seating maps, users have the flexibility to bid on different seating areas, between different prices for different seating areas, tie a -bfena * n &amp; fa ^ i7 &amp; »yffi tickets together with your friends 'bids, and set the' relative priority rank of the user's preference. By way of illustrationcOnjac ^ cionalr-w - ^^ makes an offer, the offer can be automatically evaluated by the ticket system, which can compare the user's offer with a certain minimum acceptable offer from the ticket sellers. If the offer meets or exceeds the minimum acceptable offer, the offer can be automatically accepted, the user can be informed of the acceptance, the user must pay for the ticket at the offer price (and all related service charges), The user payment (or a portion thereof agreed) can be transferred to the ticket sellers, and the ticket can be delivered to the user. If the offer does not meet the specified minimum acceptable offer, the offer can be automatically denied, and the user can be informed of the denial and, optionally, the minimum acceptable offer price, and the user can have the option to allow another offer. . Optionally, instead of having an offer automatically accepted or rejected, the offer may not be communicated to a human authorized operator who can manually inform the system if the offer is accepted or denied, and the system can process the acceptance or rejection of the same way as described above. The minimum acceptable offer may be a fixed amount or it may be varied according to a formula that takes into account the number of unsold tickets seats in a given seating area, the number of unsold seats for the overall event, and / or the number of days until the event is to take place.

If an auction format is used, the system can specify a minimum price and / or a minimum bid increment. Later, users can submit their bids and they are received by the system. The system can determine the highest bidder for a given flight, and the highest ticket can then be awarded and delivered to the highest bidder. The winning user can charge for the ticket in the amount of the winning bid and the user payment (or a portion thereof agreed) can be transferred to the ticket sellers.

IMPI

If the user submitted multiple relative priority order, und^ANDVU &amp; ^ fc_L'^^ receives tickets through one of the relative priority user offers, then the rest of the priority being offered / seating areas of the user bid on can be ignored and / or withdrawn from a voucher request data store so that the user has only suffered one set of tickets. When determining which user who wins ticket, the relative priority rank for the user indicating the associated seating area will also be taken into consideration.

In certain modalities, the auction can be a ranking seat auction, where there can be multiple winners in the same auction. As an example, in some auctions, a user does not bid on tickets for a particular seat. Instead, the user can simply bid for the tickets to view the event on a seat that was subsequently determined by comparing the user's offer with the other offers that are submitted before the auction ends. Seat tickets in an auction may have been ranked according to what event providers or ticket sellers have decided to be from highest to lowest convenience and comparing it against bids submitted by users, optionally, taking into account The relative priority users rank associate with the different seating areas. At the end of the auction, tickets can be assigned to the winning bidders based on the rankings so that those winners who bid higher than the user are assigned higher ranked seats and those winners who bid lower than the user will be assigned. Lower-ranking positions, optionally broken links in favor of people who submit their final offer before other offers.

Optionally, different seat tickets may be available for purchase using different techniques. For example, some seat tickets may be available at a preset price (for example, where the user only agrees to purchase the ticket at the preset price and the purchase is automatically processed by the system), some seat tickets may be available through an auction, some tickets may be available when a user makes a purchase offer to

IMPI ^

INSTITUTO MEXiCAN- DE LA PROPERTY C ^ jCy a specified price that the holder of the current ticket can ^ ecept-ff-reject or respond to a free sale offer. Some seats may be available using two or techniques. For example, tickets for a seat may be available at a fixed price, in which if a user pays the set price, the purchase is complete, or the user can bid on the set unless the system price , where the ticket owner can accept or reject the user's offer, and the purchase will not be made unless the owner accepts the user's ticket offer. The interactive seat map can include coding (for example, color, icon and / or text coding), which indicates the purchasing technique of a given seat, so that a user can decide not only which seats they want purchase tickets for, but can also decide which purchasing technique is acceptable to the user and make ticket purchasing decisions accordingly.

Figure 21R illustrates an example seat interactive map with indication of the number of event tickets available, a specified minimum offer price, an average amount of offers corresponding to the offers can be, per event tickets, and the number of event ticket offers received. The user can also activate a control for the seat map to indicate that a user's friends have made offers. Through the interactive seat map, the user can choose a section, level, row and / or seat, enter an offer price, and present activate a control. The offer can then be processed in a similar manner as described above.

Figure 21S illustrates an example interactive seat map, similar to that of Figure 21R, in which a level (level 100) has been selected by the user. A pop-up window appears providing additional information regarding the selected level (for example, the distance from the floor, the number of tickets available for the selected level, the number of offers presented for the selected level).

As illustrated in Figure 2, a chat user interface can be enabled by allowing the user textual and / or via voice chat in substantially real time with other users / friends regarding which seats to

IMPI tNxTm> T <.M .-: x: CAHo f '' 1

Df la '' Ki'n, i ·,> 1 - .. ,,, make an offer for, how much to offer for the seats, seated ^ ü'ñtüis, ete-tas³'' selections can then appear in the dpjigiiarin interface as illustrated in Figure 21U. A priority field can be granted, after the auction or bid period is over, the first highest priority bid is first examined by the system before the second highest priority bid is considered by the system, and so on. , until one of the offers is accepted or until there are no more user selections. Optionally, users can link their ticket offer to that of their friends. As illustrated in Figure 21U, for each sale line items, the user interface me seat allows the user to select from a list of social friends of the network user's site (for example, with the friends of the logged in user). as equally described herein), which friend (s) the user wants the specific line offer item to be tied together with. The system determines whether both offer to the user and the user's selected friends' are accepted. In those cases, the system will not grant the user to purchase tickets (the user's offer will not be accepted) unless the selected friend (s) offer (s) are also accepted for that same seating location.

An exemplary embodiment provides user interfaces, illustrated in Figures 21V-21W, that allow a user to make an offer to buy a ticket from another user who had previously purchased the ticket. For example, the user interface may include a local map, such as the map illustrated in Figure 21V. The user can select a specific section or seats for which the user wants to buy the tickets that can be held or owned by other users. If a determination is made that a ticket holder is willing to accept or entertain purchase ticket offers from other users (for example, based on an indication provided by the ticket holder to the system through a user interface , in which the indication is associated with the corresponding seat, where the ticket holder can also specify a minimum price that can also be stored), The system may cause the icon of a seat ticket holder to include a corresponding indication (eg, a corresponding icon, ¡tfORterayiootor. INDUSTKlAl --system can transmit the offer in an offer notification (for example, by email, SMS message, MMS, voice messages, inupa du JUiCTlO ?; website, phone application, or otherwise), including the price, presented by the user to the ticket holder through a purchase offer interface, which may include a field for you to receive a user-specified offer price. The system can receive the acceptance or rejection of the offer from the ticket holder (for example, where the ticket holder activates an access control or control of the refusal to include in the notification or through an access page by clicking on a link or other control included in the notification offer), and will transmit an indication of acceptance or rejection to the user (for example, by email, SMS message, MMS, voice messages, seat map, website, phone app, or otherwise). If the holder of a ticket accepts the offer, the system can store an indication corresponding to acceptance, process the purchase (for example, charge the user's credit card or other financial instrument, and charge the user and / or holder of a ticket for a service charge), and transfer the ticket (which can be a physical or electronic ticket) to the user. The system may store an indication in a ticket database that the ticket has been transferred to the user in association with a record for the corresponding seat. The system may cancel or will not invalidate the original ticket holder's ticket to prevent the use of the same (for example, by recording in memory an indication that the original ticket holder is invalid, so if it is used and scanned at the event venue, the admission system will access the ticket database and determine that the original ticket is invalid). Optionally, if the ticket holder rejects an offer, the ticket holder can present a counter offer, which the system can communicate with the user, who in turn can accept or reject the counter offer, and can couple a negative with a counter- free sale offer.

Figure 21V illustrates an example of a user interface including the controls through which a user can make an offer to buy the

IMPI tickets of other users of one or more seats. In addition, there are '^ ¡bfoYciona ^ os controls that allow the user to select an item ^ and have a fntnyafe »- video, or other representation of the view of that seat or section being displayed. Additionally, the user interface identifies the current ticket holder (for example, through their name, nickname, photograph, or otherwise), of a user's selected seat, and offers indications (in the form of text, color, charts, etc.) that indicate whether the current ticket holder is open to receiving offers to purchase tickets, and offers the minimum price the current holder expects or requires if the ticket holder is to sell the ticket. In addition, the different search and filtering controls and fields (offer / password ticket field, price range control, option ticket menu, who is sitting in the menu, etc.), and event and venue information (eg, artist name, venue name, address, event date / time, user ratings and / or recommendations, number of user communications about the event, who attends, sale dates / times for tickets, etc) are provided as discussed above with respect to other example user interfaces.

In addition, the sample user interface shows average ticket prices (or other statistical calculation) for tickets sold for events, calculated by the ticket system or other system. For example, the user interface can display the average price and / or price range for tickets in a specific time period, such as the current day. Optionally, the sale of tickets price information that prescribes a section or seating area specified by the user. A control is provided through which the user can instruct the system to allow historical event ticket sales prices for other time periods (eg past days or weeks).

Figure 21W shows the user interface of 21V figure with a pricing interface for user submission. The user can enter an offer price per ticket and expires one day and one hour until the offer. Optionally, the user is instructed that there is a minimum price required and if the user enters a

IMPIAS price below the minimum, the system detects it, and informs q &amp; EH

INDUSTRY! ^ * 33 offer is not accepted because the offer is less than the specified minimum quantity. ~~

Figures illustrate 21Z-21X user interfaces, including interactive seating maps, that provide a unified presentation of event seating tickets, both in the primary market (initial sale of an event ticket) and the secondary market (resale of tickets from previous buyers. The information that is used to populate the user interface can be obtained from a plurality of systems associated with the respective primary and secondary ticket sellers. Some ticket sellers may be contracted in both the primary and secondary market, while other ticket sellers may be sold in the primary single ticket market or only secondary ticket market sellers.

As illustrated in Figure 21X, a user interface is provided through which the user can select one or more ticket sources, which can include primary and secondary market vendors. The seat map is updated to highlight the seats whose tickets are available from the selected sources. The seat icons can be coded differently (e.g. different internal graphics, different colors, different borders, etc.) to indicate the font of the ticket for a given seat and / or an indication of whether the font is a font. primary market or a secondary market source. The user interface includes various other fields, controls, and information, in a similar manner as described above with respect to certain other user interfaces.

FIG. 21 illustrates Y an example user interface (eg, the user interface illustrated in FIG. 21X) that includes user-selected seats. When the user hovers over or points in the selected seats, additional information regarding the seats is presented, including the source of the seat ticket and / or an indication of whether the source is a primary market or secondary market source.

π · »· i» *

WICKED

In certain modalities, the ticket holder revendwwwnv ^ l ^

INDUSTRIAL F * '' specify to which other users or categories of users the ticket holder is willing to resell a ticket to. For example, in some-cases; ~ el-tTtCTlar cte · ticket cannot sell a ticket to a ticket broker, but is only willing to sell the ticket to someone who has a designated friend or who may be a ticket holder. friend of a friend (or who may be a member of a specified group, such as a fan group of the performer performing at the event). The carrier can also enter, via an electronic form or otherwise, a requested price per ticket and a reason why the ticket holder is not using the ticket. The ticket system can then determine whether a user looking to purchase tickets fits the specified ticket holder designation, and if not, prevent or inhibit the user from purchasing the ticket. For example, the system may indicate that the seat ticket is not available for purchase to users who do not conform to the specified designation ticket holder.

On the buyer side, a seat map may indicate that the seat tickets being offered for sale are being offered by a friend of the buyer (which can be determined from information obtained from a social network database) . In addition, a purchasing user can specify that the user wants to filter the seat map to indicate which seat tickets that are offered for sale are being offered by a friend (or otherwise specified by the seller). Figure 21Z illustrates this type of example user interface. In this example, the user has selected Friends exclusive under Ticket Options. The seat map has been updated to indicate through a star that the seats are associated with the tickets that are offered for sale by a friend. If the user hovers the cursor over a seat, additional information is presented, such as the location of the seat, the reason provided by the user for the ticket sale, the requested price, and an indication that the ticket holder is only selling. the ticket to friends. Controls are provided through which the user can send the ticket holder a message.

In certain modalities, a ticket can be resold), a ticket seller without having to manually send a ticket, ____ physical to a ticket buyer, for example, subscribers can electronically transfer a ticket to the recipient through the ticket system . The bearer can identify the ticket being sold by selecting their ticket from a menu provided by the ticket system tickets held by the ticket holder (for example, based on the ticket holder's account information) or by delivering to the ticket holder's identification system of the relative information for the purchase of tickets (for example, a unique code printed on the ticket if the ticket is a physical ticket). When the purchase is complete or when instructed to do so by the ticket holder, the system can cancel the ticket held by the ticket holder The ticket system can keep a record of each transaction so that the system can track who it is the current ticket holder is, as well as who has declared the ticket.

In certain modalities, the interactive map may turn off if the ticket system is so loaded that it cannot adequately support one or more instances of the interactive map (for example, when the system cannot allow up-to-date information about which seats are available with the sufficiently quickly (eg, substantially in real time), resulting in seats that have become available still shown as available) as illustrated in Figure 21P. For example, if consumption activity in a certain event peaks (for example, during the first hour or other time period Tickets of events are put on sale), the system can automatically disable the interactive seat map and users in Instead, they may be presented with or directed to a user interface ticket purchase alternative, such as the one illustrated in Figure 21q. For example, the alternate user interface cannot allow a user to select specific seats. As an example, the alternative user interface may instead allow a user to specify a price level or best available seats, where the system, instead of the user, then selects the specific open seats that match the criteria user and quality ratings or assignments with respect to losatafe ^^ SISbi ^ SSs ^ -Λ (for example, the system can locate the highest rated seats or quality assignments that are open and that meet Tprécío ~ 3eT^m'· ¹user and / or criteria of the selection section). The system then allows the user to purchase the selected seating system through the alternative purchase ticket user interface. The notification may be made with a charge to the user's screen regarding the disabling of the interactive map. Optionally, a first notification can be provided indicating that, due to the detected system load, the performance of the interactive map may be significantly degraded (for example, very slow), and the user may offer the option to continue using the interactive map or use the alternate user interface. Then the selected user interface is presented to the user.

As an example, consumer activity can be measured by one or more of the following factors:

to. the amount of web traffic that is arriving on the purchase page of an event;

b. the number of seats that are simultaneously reserved in the ticketing system.

Additionally, the thresholds for these factors may vary based on the life cycle of the event (for example, if an on-sale is approaching, the thresholds may be relatively lower to be more sensitive to traffic and buying activity.

Examples of processes for obtaining and using data from social networks and web sites will now be explained in more detail.

As described above, in certain embodiments, the system (eg, the ticket system) determines (eg, from information accessible from a social network database and / or a ticket system database) and provides to display an indication that seats are assigned to the user's friends via the interactive map. A friend can be another that the user has identified as a friend to the system or to a source that provides information to the system or that the system is inferred from the data (for example, the contact database of the XsíViIo JesLrf INSTITUTO MEXICANO del user. A friend can be a personal friend, a Se ^ negS &amp; fes partner,

<img file="MX350182B_D0025.tif" />

person that the user wants (or, in certain ways, that is inferred from the system that he wants) share the ticket / seat of the information related to.

This allows the user to determine which friends have purchased tickets for the event, and further allows the user to purchase (or attempt to purchase) tickets for the seats next to or near one or more of the user's friends' seats. For example, event seats for which the user's friends have purchased tickets, or tickets for which they have been purchased, can be colored green (or another color), designated with a special icon, or otherwise underlined.

The system can obtain information regarding which user's friends are using one or more processes. For example, the user may agree (for example, through an opt-in control) or instruct a social networking site to share information with the ticketing system regarding the user's information. The information that relates can identify that the user has indicated are the user's friends and / or that others have indicated that they are the user's friends. The system can access such relationship information through an application programming interface (API) associated with the social networking site or it can access information from other sources.

In addition to determining who the users' friends are, the system can determine if the friends have purchased tickets for the event, have received tickets for the event, and / or have been tagged in a seat for the event. For example, the system may have ticket records that indicate the identity of buyers, ticket holders, and seat labeling information, and may assign the names or other identifiers associated with the user's friends (for example, obtained from the relationship information) to the EVENT PLACE seats using the ticket records that identify the current ticket holder. In cases where the current ticket holder is not the original ticket purchaser, the system may use contact information such as names / addresses (for example,

.... _ ...... 11Υ1Ρ J email, SMS, MMS, or any other addressN (efi) ^ dj * ^ that have tickets electronically or physically been sent to protect idehiiíit ^ who is the holder of the current ticket , although the current-ticket-owner is not the purchaser of the original ticket. The relationship information and the support ticket information can then be used to generate a seat map for the user, indicating that the user's friends are sitting or may be seated. The seat map can be dynamically updated to include and display to the user my friends' comments, photos and / or videos submitted via a website ticketing system, social networking site, computer / phone application, service short messages, or otherwise.

Optionally, the ticket system may receive such relationship information directly from the user, instead of or in addition to receiving the relationship from a social networking site. For example, a form can be presented to the user that prompts the user to identify other users that the user considers friends. For example, the user may request to identify his friends by allowing the friends' names, email addresses, physical addresses, telephone addresses and / or unique identifiers assigned by the system or selected by the friend, or to identify the friends. As an additional example, the user can ask to provide the system with access to the user's contact database, which can be used to determine who the user's friends are or could be.

In an example embodiment, if a user connects to a social network site, the ticket system receives from the social network system, a user identifier (user ID) from the social network system. The ticket system can then use the user ID to request and retrieve information from the social system network related to the user, such as the user's profile and an identification of those who are designated as the user's friends. Some or all of the retrieved information may then be displayed to other users as discussed elsewhere herein.

If a user indicates that the user is going to attend an event (for example, by responding, through an RSVP or not, to an invitation to attend the event of

ΙΜΡΙ @

MEXICAN INSTOUTE. ·. . ,. . ...^OF THE PROPERTY 1 * 1 other user, or by purchasing a ticket) for the tickets whichfYesFvendbO through the ticket system, the system stores the indication ticket can transmit the indication (for example, the RSVP) to the network system social, which can send the indication. An event for the ticketed event can then be set up on the social networking site, where selected users or all users can have access to event information through the social networking site, as described below.

For example, the event may include a description of the ticketed event, and the date, time, location, and address of the event. Privacy settings can be set for the event, which specifies who can see the event information, and a guest list can be defined as well. Invitations to attend the event can be transmitted by the social network system and / or ticket system to the members of the guest list. A ticket regarding the event (including some or all of the information from the previous event) can be displayed on one or more user pages (for example, in the form of a wall post), on a page associated with the operator of the ticket system and / or something else is available for viewing.

In a similar way mentioned above, the ticket system can also store user-to-seat information. For example, if a user has chosen to tag the user's seats to an event (indicating that they will be seated in the seats purchased by the user), user-to-user data can be stored. The stored data may include a user's account identifier / userID for an account stored by the ticketing system and / or an account identifier / userID associated with the site user's social network account, stored in association with the seat identifiers for user seats. Optionally, such a data tag user-to-seat is not transmitted to the social network system, although in certain embodiments, it may be transmitted to the social network system.

When a user accepts an invitation seats or tags and friends to an event, the ticket system can build a back wall and transmit the wall message to the social network system. In turn, the social network system

IMPI can return a wall message identifier , which »* · ®® ^ euaifia <. > I INDUSTRIAL ticketing system and that can be used to track the matching message ^ and call or erase the message from the wall if necessary or if desired .------—- As an example, a post of built wall may include some or all of the following information

1. Event details: name (for example, artist's name), date, place, time, address, web page / URL of the event page and / or artist / Artist page.

2. The names of the friends who were tagged for the event (optionally excluding or including the social media friends, site user IDs)

In an example embodiment, if a user tags his / her friends to an event, or invites the user's friends to an event, the ticket system builds a user-to-user social networking site for the application (app) request. from a social network application of the ticketing system site for the corresponding domain or, in addition or instead, The ticket system may build a user-to-user email message social networking site or other mechanism to deliver a message to the recipient user. In turn, the social media system returns an application request ID that is received by the ticket system. The ticket system can use the application request ID and / or email message ID to track the request to thereby track individual application request and message ticket tray statuss and act on consequence, or remember the application request invitation or email message when needed or desired. The ticketing system can store individual user-to-user requests app or ticket tray messages in a database.

A sample application request or email message may include some or all of the following:

1. Event details: name (for example, the name ^ ift ^ téri

INtXSTIUAL date, place, time, address, web page / URL of the event page and / or performer / artist page. —- -

2. An identifier (for example, a userID) of the user of the social network site initiating or transmitting the request.

An indication that the user has purchased the seats for the event and / or a seat location identifier (e.g. section, row, seat number) can be published by the ticketing system and / or the system social network for display on the user of the social network page or other page / document associated with the user (for example, the user's own blog or web page). This allows other users who have permission to view the user's page and / or activity updates to view or be notified (by email, SMS message, MMS, postal mail, automated voice messages or not) of the ticket purchase. of the user and / or the seat assigned to the user.

Optionally, a link may be provided on the site user's social network page, which, if activated, will cause a user interface ticket purchase, which allows the viewer to purchase tickets to the event, optionally for seats near user seats. Optionally, the system tracks when purchases have been made by users who navigated to the event ticket page through a link associated with another user's page, and made ticket purchases, and provides a benefit (for For example, a discount, a credit, a payment, a free musical element (for example, a CD, MP3 song, etc.), an article of clothing, etc.) to said user whose page includes the link.

Figure 23 illustrates an example user interface that allows a user to indicate to others that the user is attending an event. In this example, an action control (Attendance) is presented to a user substantially immediately after the user has purchased a ticket for an event, during the same session and at the same site where the user purchased the ticket. Optionally, in addition or instead, the control

IMPI ^. ..,.,. . . ·. > Ν. ™ τυτοΜ «κ> Ν <'' UT of action (which could be a link) can be sent by mail ^ g & ^ ic ^ transmitted to the user via SMS, MMS, an application of the device of _____________________„ __ telecommunications, a web page, an interactive seat map, or otherwise, sometime after the completion of ticket sales. In this example, the user interface instructs the user to activate share control (Assist) if the user wants to inform others (for example, that the user has designated as friends, other groups of people, or everyone), to Through a social, networking website or otherwise, that the user will be present at the event. If the user activates the shared control (Attendance), which indicates that the user will be present at the event, it is published on the website of the social network user and / or the indication that the opposite is provided to other users by mail electronic, SMS, MMS, a telecommunications device application, a web page, an interactive seat map, or otherwise. The indication can optionally include the name of the event, the date of the event, the time of the event, the location of the event, and / or the local location.

Figure 24 illustrates another example user interface that allows a user to indicate to others that the user is attending an event, as described above similarly with respect to Figure 23. In this example, an action control (Attendance) is presented to a user substantially immediately after the user has purchased a ticket for an event, during the same session and at the same site where the user purchased the ticket. Optionally, in addition or instead, the action control (which could be a link) can be sent by email or transmitted to the user via SMS, MMS, a telecommunications device application, a web page, a seat map interactive, or otherwise sometime after the completion of the ticket sales. In this example, the user interface includes a field through which the user can enter the content (for example, text, images, graphics, and / or videos) to be published in association with an indication that the user is attending. to the event. The indication can optionally include the name of the event, the date of the event, the time of the event, the place of the event, and / or the location.

IMPIfO 'local. If the user activates a publish control, the indication 'EO ^ qpg ^ l üS ^ rrgs *' will be present at the event and the user has entered content published on the user's website of the social network and / or the indication otherwise made available to other users by email, SMS, MMS, a telecommunications device application, a web page, an interactive seat map, or otherwise.

Figure 25A illustrates another example of an interface that allows the user to indicate to others that the user is attending an event and that allows the user to indicate which of the user's friends is going to attend and / or the user would like to invite them to attend. . In this example, the images of the user's friends (who may have been visited from a social networking site) are presented in association with the names of the friends / identifiers. Optionally, the user can limit the friends presented through the user interface by searching for one or more particular users. For example, the user can search by name, geographic location, group membership, interests, musical preferences, etc. The user can select (for example, by clicking on the names / photos of friends) which of the friends are attending the event and / or the user would like to invite to attend. A field is provided through which the user can designate who is allowed to view, via a seat map, which seats the user to buy tickets for. For example, the user may be able to designate that the seat information is to be viewable by everyone, friends, pre-specified groups of people, specific individuals, etc. As described above similarly, in this example, the interface of user is presented to a user substantially immediately after the user has purchased a ticket for an event, during the same session and on the same site that the user purchased the ticket. Optionally, in addition to or in place of, the user interface may then be provided to the user through one or more of the techniques described above or otherwise.

Once the user tags other users through the user interface illustrated in Figure 25A, the user activates a next control, and the

<img file="MX350182B_D0026.tif" />

The example user interface shown in Figure 25B is prd ^ Q'oha for the screen. The example user interface presents a pHgiaqfn Ha in g ^ coran -— published on the page that the user of the social network / document (which can be presented via a browser, the application of the telecommunications device or other ). The user can activate a control in Publish to publish the attendance information, or activate a control to prevent cancellation of said publication.

Figure 25C illustrates an example of the social media page with the notification illustrated in Figure 25B presents the same. A notification can be provided via the social or other networking site to tagged / select users through the user interface of Figure 25A, inviting them to attend the event. The notification may include a link, which if activated, will cause a user interface ticket purchase for the event being presented to the invited user. The user interface ticket purchase can be offered by the ticket system described above.

Figure 26A illustrates an example user interface purchase ticket through which a user can select specific seats for an event and can see which of their friends have bought tickets or do not have tickets for the event, and where it will be seated. In this example user interface, the user can activate a link, which will initiate a connection to a social networking site and / or database that stores information on who the user has designated as friends. To encourage the user to activate the link, the user interface presents a seat identifier (e.g. section, row, seat designations) and indicates whether the user wants to know that they are seated in the seat corresponding to the seat identifier. seat, the user must activate the link.

Figure 26B illustrates an example user interface provided for presentation to the user if the user activates the link described above with respect to Figure 26A. As illustrated, icons (f in this example) are displayed on the interactive seating map, indicating in which section of user-friendly seating will be seated. The icon may indicate the origin of

IMPI ÍNsrrnrro mejucan &lt;

identification of friends (for example, f can indicate f^?ctoeKθ ¢ ^ ® ^ different icons can be used to represent different social networks. If the user is hovering or pointing a cursor over a section where a friend is sitting (for example, which includes one of the above icons), the names and / or images and / or of the friends and / or count of a number as to that of friends sitting in the section will be displayed. This information allows the user to quickly find which friends are attending the event (or the intention to attend) and where they are seated (or the intention to sit), which can affect the user's decision of whether or not to buy a seat ticket. for the event, and which seat to buy a ticket for. The user can purchase tickets through ticket purchase controls that are displayed in conjunction with the interactive seat map.

<img file="MX350182B_D0027.tif" />

Figure 26C illustrates an enlarged view of the interactive map of Figure 26B, in which individual seats can be viewed. If the user points to a hovering or a cursor over a chair where a friend is seated (for example, including one of the above icons), the name (which can be the friends' legal name or a nickname / alias) and / or photograph the friend will be displayed. A control is provided through which a user can tag himself / her car on the seat map (for example, indicating that the user intends to or is considering buying a ticket for the seat), so that when the user friends through the seat map for the event, the seat map will display the user's name and / or image. The user can purchase tickets through ticket purchase controls that are displayed in conjunction with the interactive seat map.

Figure 26D1 illustrates a social network user, apps page (through which third-party content can be displayed) indicating that a ticketing application has received an invitation to attend an event, including an accept control Through which the user can accept the invitation. If the user accepts the invitation, a user interface purchase ticket for the event will be presented pay by the user's browser or in another application and the user can purchase a ticket for the event.

INSTITUTO MEXICANO DL LA FROPIEiXAD INLíUSTRUi,

Figure 26D2 illustrates an interactive seat map that includes a user interface that provides tagging control through oua4-the user can tag himself / herself on the seat map so that when the user's friends see the seat map for the event, the seat map will display the user's name and / or image (or other identifier). Figure 26E illustrates an interactive seat map that includes a user interface that indicates that more than one user has been tagged for a particular seat. The user interface presents photographs and / or user names that have been bookmarked by the given seat, and allows the user to tag himself or herself in that seat (for example, indicating that the user intends or is considering buy a ticket for the seat) so that when the user's friends through the seat map to the event, the seat map will display the user's name and / or image (or other identifier).

Figure 26F shows an interactive seat map presented to a user after purchasing a ticket to an event. The user may have brought a ticket for himself / herself or for someone else. A user interface is provided to the screen that displays a seat identifier (eg seat section, row, number) corresponding to the purchased ticket and prompts the user who is seated on the seat. The user interface provides a control through which the user can indicate that they are sitting on the seat (eg by entering / selecting the name and / or photograph of the person sitting on the seat). If the user purchases multiple seat tickets for the event, a user interface can display each of the corresponding seat identifiers and can optionally present the names / photos of the user's friends (for example, access to a social network). The user can select the friends from the list and indicate which friends will sit in which seat. Furthermore, a user interface is provided through which the user can specify who or what groups of people can see the markup made by the user.

Figure 27 illustrates an example augmented reality user interface that provides a computer-augmented view of a physical location

MEXICAN INSTITUTE

M LA PROPERTY industrial - * --.--- generated visual and / or audio information. In the example, an application is downloaded and hosted on the un-UGuario telecommunications device (for example, ΙΠΤ2Γ camera equipped phone). As the user points the device's camera in a room view, the application and / or a remote server in communication with the application uses the device information to determine (e.g. estimate) what is in the room view. the camera. The determination may be based, in whole or in part, on:

GPS location information, tower cell location information, WiFi location information, an internal compass for the device that provides bearing information (for example, relative to magnetic north), an internal accelerometer in the device (which also can be used to allow orientation information), gyroscopic orientation information from a gyroscope (for example, a 2 or 3 axis gyroscope that can allow two or three dimensional information attitude (e.g. pitch, roll and yaw) and, in combination with accelerometer output, rotational speed) located inside the device, object recognition performed using image analysis to identify landmarks (which can be structural landmarks, such as walls, columns, doors, seats, and / or can be active or passive beacons, such as coded signs (for example, where each sign has a unique visual code and the signs are strategically placed are columns, walls, etc), etc), faces, etc, and / or other information.

In order to make the determination, some or all of the above information may be used in conjunction with a 3D map of the site (which may include location information beacon placement, if such and / or other sign identifications and locations exist ) and / or photographs and / or what is actually physically present at the location as reflected through a rear-facing camera lens on the user's smart phone, PDA device or

100

PREVENT tablet. In particular, some or all of the waiver informaeto ^ i # ^^^ to determine the attitude of the device (position and orientation). For example, GPS information can be used to determine the latitude and longitude location of the user device, and gyroscopic orientation information can be used to determine the angle of the lens with reference to ground or other reference point or plane. Upon receipt of an Indication (for example, through the application) that the device's camera is active (capturing images), and knowing the device's user pose, and the system can determine what is displayed on the screen Of the device.

The application and / or the server may also obtain seat information (for example, the inclusion of identifiers / names associated with ticket holders) and personal user information (for example, identifiers / names associated with the user's friends obtained from the ticket system and / or a social networking system data stores) that can be compared to determine where and in which seats the user's friends sit. The server can transmit to the application information as to where on the seat of the display device such and friend information are to be displayed. The application can be superimposed on the captured image by camera names, photographs, and / or seat identifiers of the user's friends so that the user can visually see where the user's friends are. Optionally, the system can receive comments, photos and / or videos sent by event attendees during the event.

For a given user, the system can determine who the user's friends are, and then transmit the user's friends' comments, photos and / or videos sent through the application, a short messaging service interface, an interface social network, or otherwise, (and received by the system) substantially in real time to the user's device for display through the augmented reality user interface. Additionally, other types of information may be overlaid on the camera view, such as other highlights or emphasis around restroom tickets,

101 . IMPI concessions, other services, outputs, the user of the autonomy ^ Btí ^ j ^ be visually encoded (for example, a color code, coded cone, etc.), where different codes can be used to identify the different characteristics or types of information (for example, the type of service provided by the equipment (for example, food, a bathroom, a water fountain, an ATM).

In addition, the system can determine which of the user's friends have arrived at the place based on an indication that their ticket (which can be a physical ticket, an electronic ticket on their phone, the credit card used for the purchase the right of assistance, etc.) has been analyzed on the spot, through a device presence signal received from mobile communication friends, while on the spot (for example, GPS information provided through a phone application hosted on mobile communication devices friends) through affirmative action by staff (for example, by activating a control I have reached through an application hosted on the friend's mobile communications device), or otherwise (the system may also determine if the user is there). When the user's device is pointing at a friend's seat, the system can code (for example, color code, icon code, text code, etc.) the seat to indicate the friend has arrived (or that a friend has not arrived if its presence has not been detected). In addition to or instead of, a list can be presented to the user through an application or web page indicating which of the user's friends have arrived and which have not yet arrived.

In certain modalities, the ticketing system can determine whether the user's view includes an interpreter, can access information about the performer, and cause the accessible information to be displayed through the user's device in association with the interpreter's image. .

In certain modalities, the ticket system will be able to determine if the user's view includes ticket seats for the event that have not yet been purchased. The system can optionally identify the seats as

102

IMPT ^ »available to the user through an increased validity indication # superimposed on the view (eg, verbatim, graphically or otherwise). A control can be provided through which the user can purchase at a specified price, through their device, a ticket / upgrade for the seat, which can then be electronically delivered to their device for display or communicated to others. (for example, to an Usher) to indicate that the user has a right to use the seat. Optionally, before indicating to the user that a seat is available, the first system can determine if the seat is a better current seat seat of the user (for example, have a better view, is closer to the stage or playing field) , based on classification or other information stored in a database. If the seat is not better (for example, it has a similar rating, the same, or less than the user's current seat), optionally the system does not detect the seat as available to the user.

Figure 28 illustrates an example ticket selection and purchase process that can be executed by a computer system, such as system 102 described above. In status 2802, the process receives a user selection of an event (for example, through a menu selection, a user-initiated search, the activation of an event link, or otherwise), and the process causes a map of the event location that will be displayed on the user's terminal (for example, a laptop, desktop, tablet PC, mobile phone, television, etc.) As an example, the map may be provided for viewing on a ticketing web page through a ticketing application or hosted on a computing device. The map can take place demarcated sections of seats (for example, using polygons). Sections and / or seats can be color-coded and / or otherwise encoded (for example, by icons, text, animations, 3D effects, etc.) by allowing information on sections and / or seats (for example, location information, location information status, pricing, offer code requirements, view information, etc.), as described above.

103

The process can cause a field to be presented to the user can enter an offer code. For example, offer code ......._ may give the user the right to buy seats that are not available to the general public or to certain people in the absence of the offer code. In addition, or instead, the offer code may entitle the user to reduced prices / discounts on tickets for some or all seats and / or it may entitle the user to a package (for example, a musical food recording, and / or an article of clothing, in addition to the ticket to the event).

If the user has been identified by the system (for example, through a login process on a ticket sales website, a social network website, through a signal, a unique user terminal identifier , or otherwise identified), the map can be personalized for the user. For example, in status 2803, automatically or in response to a user instruction to show where the user's friends are sitting, the process may identify certain other people who have a social relationship with the user (which, for convenience, is called friends) of information obtained from an account of the user's social network. The database can be part of a social network organized by the ticket system or separately, hosted and managed. In addition, information regarding such friends (eg names, email addresses, wall posts, activities, etc.) can be accessed from the social network account of those people. The process may use identifying information about friends (for example, their names, addresses, emails, etc.) to locate, in a ticket sales database, user records that include some or all of such information. , identify a data record of ticket users will be able to indicate which seat tickets for the events that are held by the respective user. Then the process can determine which friends are the ticket holders for the event and establish which seats the friends hold tickets to. The map can then be generated or modified to include indicators as to where the user's friends are sitting (eg, at a section level and / or at a seat level). Indicators can

104 be in the form of color coding flags, icon, n^lSfñS '£ it was ai

INÍXJSTWAL photograph friend, or otherwise. Different can be used depending on what level of map detail is presented to the user.

In status 2804, the process receives from the user a selection of a location section (for example, the user clicks or hovers a cursor over the section on the map) or a modification of the user's search criteria (for For example, by the user to specify or modify a desired price range, ticket type, container type, seating area, Shaded seats, Sun seats, Covered seats, Aisle seats, Adjacent bathroom seats, Adjacent concession seats, exit adjacent seat, Friendly seats, etc).

On status 2806, the map provided for user display is updated, optionally in substantially real time, to reflect section selection, modified search criteria, and / or system initiated modifications (for example, to reflect change in seat status). For example, if the user has selected a section, the process may allow, through the user terminal, an enlarged view of the section so that the entries can be viewed and selected individually. If the user modifies the search criteria, the colorful map (or other indicator) may indicate that the sections and / or seats match the user's search criteria and / or the degree to which the sections and / or seats match the user search criteria. In status 2808, a user seat selection is received (for example, by a user clicking a seat icon on the map or by entering a seat identifier in a field), and the selected seat (s) they are added to the user's selected seat list and have a reserved status assigned. In this embodiment, when the seats are in a reserved status, other users cannot buy the tickets, although optionally they can be on the waiting list for tickets, in which the user on the waiting list can be notified when the seats reserved are available for purchase (and are no longer reserved by another user). In certain modalities, reserved seats can be released

105

IMPI,. ,, INSTITüTp MEXICANO so that others can buy (in which the status canroi ^^^ disposition), if the user does not complete the purchase of tickets and / or certain stages of the purchase of the ticket, within a specified period of time .

In status 2810, the user activates an exit check, and the process processes the order (e.g., obtains or retrieves payment information, shipping information, etc.), and causes the ticket (s) to be delivered to the user (eg electronically or as a physical ticket) and / or allows an existing user physical or electronic document (eg a credit card, license, membership card, etc.) to be used as a ticket. The user can automatically be tagged in a seat selected by the user and / or purchased by the user, or the user can instruct the process to tag the user in the seat. Optionally, a user interface is provided through which the user can tag others in one or more seats.

In status 2812, the process may receive an instruction from the user to transmit invitations to attend the event to one or more people and / or a group of people designated by the user. The process may then transmit such invitations to those so designated directly through system 102 or through another system (eg, through the social network system 122 illustrated in Figure 1). The invitation can indicate by username and / or photographs that the user is attending the event (for example, the invitation includes the name of the event, date, time, place and / or location of the user's seat), and can allow a control, which when activated will cause a ticket interface to be presented to the invitation recipient through which the user can purchase a ticket to the event (for example, using the process illustrated in Figure 28).

In status 2814, the process can send to one or more pages (for example, to some wall pages of the user's social network, to a specific event for the event, to friends the user's pages and / or other pages ), a ticket that indicates that the user is attending the event, in which publication optionally includes some or all of the following data:

106

ΙΝύΤΤΠ ΙΤΟ -

FROM THE >> «OPIHi_{TO THE)} event name, date, time, place, location of user ^ n ^ 'a'sienTOrW number of people attending, number of seats ^ i-gnibloE,

Optionally, once in place to attend the ticketed event, the system can allow for viewing on a user's mobile communications device (or other terminal), a mapping that shows where the user's friends have seats, and can in addition to the color code (or otherwise indicate) the seats to indicate which friends have already arrived at the place. For example, seats can be colored green to indicate seats that are assigned to the user's friends, and seats can be colored gold to indicate that seats are assigned to the user's friends who have arrived at the event. The system can determine that the user's friends who have arrived through the scanned information of physical or electronic tickets of the user's friends when entering the place and / or through the location information provided through a mobile terminal of the user (for example, a mobile phone). For example, a scanner will be able to scan:

a barcode ticket or other code on a physical ticket;

a barcode ticket or other sample code via a user's phone screen or messages from another terminal;

a field device near communication built into the user's phone or another device;

the RFID (radio frequency identification) tag, and / or a user identification document (for example, a driver's license, credit card, fan card, membership card, etc.) related to the right of admission (for example , where the user can use a credit card used to buy a ticket as the boleto, or when the user has a driver's license on file in the system that is associated with an admission right when the user purchases a ticket).

In addition, or instead, a gatekeeper, attendants, or another person may manually enter, through a terminal, an indication that they have arrived at the event venue.

107

MEXICAN INSTITUTE

PE LA PROrlír'AD C '«ae« -J »^ otoÍF

The system can store an indication that it has arrived in^TOthe event based at least in part on the scanned information. So if -im-user -— views a map through a terminal, the system identifies the user (for example, through registration information, a unique identifier associated with the user's terminal, a unique identifier associated with the application display of the user, or otherwise), identifies friends of the user who have tickets for the event, identifies which of those friends have arrived, and displays the corresponding information on the map. The map can be updated, optionally substantially in real time, to indicate changes in the statuses of your friends. For example, if a friend comes to the place or buys a ticket, the map can be updated accordingly. The map can indicate (via text or otherwise) what time a friend arrived, the friend's current location, and / or other information.

In certain embodiments, the system can track the location of a user at an event location and / or outside an event location to thereby enable location-based services. For example, the user's location can be tracked on the spot (for example, via GPS, cell tower, and / or WiFi information received by the user's mobile device, and transmitted through an app. related tickets hosted on the mobile device to the system; or through a transceiver that receives information from a near-field communication device carried by the user). Said information can be used to determine the location of a user s at the event site, and to allow information for display to the user (through a map, text information, and / or otherwise) that may be of interest. for the user in relation to the user's current location and / or direction of movement. For example, the system may use information about the user's location, along with design site information stored in a database, to determine the closest restrooms, concessions, and / or exits in relation to the user, and to allow directions to such destinations and / or display a map of those destinations, while showing the user's current location on the map.

108

<img file="MX350182B_D0028.tif" />

As a further example, a map mode can be changed based on the user's location. By way of illustration, UTTTTiapa ...... of a place can be displayed in a ticket purchase mode or in an in-place mode, where information can be displayed differently depending on the mode. For example, when in a ticketing mode, a local event map can display information about ticket sales prices and seat availability, and can allow purchase ticket controls, as mentioned above. Optionally, information regarding the location of the concessions, bathrooms, etc., is not shown or hidden (although it may eventually continue to be accessible if the user activates a corresponding control). When in an in-place mode, the ticket price information and seat availability and / or ticket controls provide purchase may be withdrawn or not displayed (although optionally they may still be accessible if the user activates a corresponding control). However, in the in-the-venue mode, information about who has arrived can be displayed and other information of interest to an attendee can be displayed (e.g. location of exits, concessions, restrooms, etc.). Optionally , the mode is automatically switched from ticket-buying mode to in-place mode when the user enters the venue on the day of the event (as detected when the user's physical or electronic ticket is scanned or via information transmitted from the terminal such as GPS or WiFi location information).

Optionally, when the user is at the location for an event (as can be determined using one or more of the location determination techniques described in this document), an application installed on the user's terminal will automatically display the location map for the event. , without requiring the user to manually select the specific map for the place (although the user may have to launch the application and / or it may be necessary to indicate that the user wants to view a place map without having to name the place or select the specific one place from a place list - such as by activating a current place control program). The map can be transmitted to the user terminal through a ticket system.

109

INSTITUTE ΜΙΑΛΑΐ ”'

In addition, that information the user's location can be determined by line length / waiting times at concessions, bathrooms, departures, or at other seats / destinations selected by the user and / or the system. For example, if the system determines, from user location information and a site layout, that a user is standing within a certain distance of a facility (for example, a bathroom, concession stand , or exit) and appears to be moving in the direction of the facility within a certain speed range (for example, less than 0.2 feet / second), the system can infer that the user is waiting in line for the installation. The system can use the previous location and movement information to estimate the length of the line, as expressed in time (for example, a 4 to 5 minute wait) and / or distance (for example, a line of foot 20). Such information The length of the line can be transmitted for display on the user's terminal (for example, through a map, verbatim, and / or by means of an email, SMS, MMS message (s)) and / or in the terminals of other users. A map and / or text list that can be provided for display through a user terminal, providing waiting line information for a plurality of destinations of a certain type (for example, bathrooms), so The user can select a destination with an acceptable shorter line or length. Optionally, the system determines from line lengths, a user's current location and / or movement information, and the locations of destinations of a given type, which destinations of the given type the user will likely reach / be able to use the fastest, and thus can identify the corresponding destination to the user as being the fastest available.

For example, if a bathroom within 100 feet of a user has a 5 minute line, and a bathroom within 200 feet of the user has a 1 minute line, the system can determine that the bathroom located 200 meters from the user be used by the user faster than the nearest bathroom. The system can transmit on the screen to the information of the

110

IMPI user maybe (via a map and / or text list) for ^ j ^ í ^ OSBid INDUSTRIAL destinations of the given type and can sort and / or list the destinations in the order of the estimated speed in relation to the destinations can üéi¹ reached or

<img file="MX350182B_D0029.tif" />

usable.

In addition, communications can be transmitted to an attendee if given before, during and / or after an event, his interest in the information goods and / or the offer and services. For example, the communication can be transmitted to a terminal (e.g. computer, telephone, television) of an attendee on the same day or the day after the event, while the case is still fresh in the mind of the attendees, asking attendees to submit a review of the case, which can be posted online in association with an offer to sell tickets to another event by the artist himself. In addition, or instead, the communication may offer musical recordings (for example, in the form of a CD, DVD, Blu-ray disc, or digital download) of the performer (for example, a live recording of the concert the attendees attended the recording or another of the interpreter) for sale or free of charge for the user.

Although certain embodiments can be illustrated or discussed as having certain additional components, eg, fewer, or different components can be used. Process that is described as being performed by a ticket system can be performed by a user terminal or other system or systems. Processes described as being performed by a user terminal can be performed by a ticketing system or other system or systems. Data described as being accessed from a given source, such as a ticket system database, can be stored by and accessed from other sources, such as a user terminal or social network database. Furthermore, with respect to the processes described in this document, the various statuses can be performed in a different order, not all statuses are required to be achieved, and fewer, additional or different statuses can be used. Although certain modalities may refer to the encoding of certain information (for example, seating information on a floor plan) using a particular technique, other techniques, including color, text,

111 RUTITUTO MEXICXN.H graphical, animations, video, audio, and / or other indicators can f ^ íiiKí ^ c ^ place or in addition. The user interfaces described in this document are optionally presented (and user instructions may be received) through a user's computing device via a browser, other network resource viewer, or otherwise. For example, user interfaces can be presented (and user instructions received) through an application (sometimes referred to as an APP), such as an application specifically configured for purchasing tickets related to activities, installed on the The user's mobile phone, laptop, pad, desk, television, television box, or other terminal. Various features described or illustrated as being present in the different modalities or user interfaces can be combined in the same embodiment or user interface.

Although the disclosure may refer to a user hovering over or pointing to a particular item, such as a section or seat, other techniques can be used to detect an item of interest to the user. For example, the user can click on that item to show interest, touch the item via a touch screen, or otherwise indicate an interest.

The various aspects and advantages of the modalities have been described where appropriate. It is to be understood that not necessarily all of these aspects or advantages can be achieved in accordance with any particular embodiment. Thus, for example, it should be recognized that the various embodiments can be carried out in a way that achieves or optimizes an advantage or group of advantages as taught herein without necessarily reaching other aspects or advantages as may be taught or suggested. In the present memory. In addition, the embodiments can include several novel features, not a single one of which is solely responsible for the desirable attributes of the embodiment or which is essential to the practice of the systems, devices, methods, and techniques described herein. . Furthermore, various features of different modalities can be combined to form other modalities. For example,

112

IMPI

INSTITUTO MEXICANO aspects found in the different user interfaces ^^^ u combine to form even more user interface.

113