WO2019213631A1 - Systems, devices, and methods for secure, flexible, and scalable ticketing and guest experience platform - Google Patents

Abstract

Systems and methods for providing a secure, real-time, cloud based, enterprise grade flexible, and scalable ticketing and guest experience platform. The platform provides dynamic pricing and flexible buying and selling options.

Description

SYSTEMS, DEVICES, AND METHODS FOR SECURE, FLEXIBLE, AND SCALABLE TICKETING AND GUEST EXPERIENCE PLATFORM

FIELD

[0001] The subject matter described herein relates generally to systems, devices, and methods for a ticketing platform. In particular, the platform provides a secure, real-time, cloud based, enterprise grade ticketing platform.

BACKGROUND

[0002] Event ticketing, for example for concerts and sports, is a $100 billion and growing global market. However, purchasing tickets is a frustrating experience for consumers. Pricing is convoluted and confusing. Inventory is fragmented. Tickets are generally non-refundable, yet their authenticity is often a real concern. For the artists and sports teams, the secondary market for ticketing is a huge concern. It has been estimated that leakage to the secondary market is a high as $10 billion. The current closed distribution of inventory often leads to large unsold tickets. This may be as high as forty percent. Many of these problems can be distilled down to the current separation of identity from the access credential. Tickets are still pieces of paper or barcodes on phones, divorced from identity, payment, and geolocation. The result is that teams, artists and venues often know less than 10% of the people walking into their physical space. This is a major customer relationship management problem, and it inhibits event owners both from providing a high-quality fan experience, and also from effectively monetizing fans before, during and after events. The anonymity of tickets also hinders efficient pricing. Unlike most goods, event owners don’t have visibility into the real time value of their product (it being a perishable physical good), and they lose out on significant revenue by over or under pricing tickets.

[0003] Security at events has also been an increasingly urgent problem. The anonymity of event attendees contributes to high security risks. We know a host of information about every individual getting on an airplane. We know nothing about upwards of 1,000 times as many people walking into a stadium.

[0004] Thus, needs exist for systems, devices and methods for a secure, real-time flexible, and scalable ticketing and guest experience platform without the above mentioned and other disadvantages. SUMMARY

[0005] Provided herein are example embodiments of systems, devices and methods for providing a secure, real-time, cloud based, enterprise grade flexible, and scalable ticketing and guest experience platform.

[0006] In some embodiments, the platform is a native, cloud based, enterprise grade ticketing platform. The platform may include support for real-time, variable and dynamic pricing. For example, ticketing operations can trigger price increases based on real-time demand, repricing for seats may be displayed in real-time, and so on.

[0007] In some embodiments, the platform may include a computer-implemented method for providing real-time, flexible, and scalable ticketing and guest experience by one or more processors. In some embodiments, the method may comprise obtaining data of a venue of an event, wherein the data comprises one or more 180-degree views; providing one or more graphical user interfaces to a user for selecting one or more seats at the venue; receiving one or more seat selections; calculating a price for the one or more seat selections; providing the price for the one or more seat selections; receiving purchase order for the one or more seat selections; requesting one or more biometric data of the user; creating a digital ticket for the one or more seat selections; storing the purchased one or more seat selections and the biometric data in a fan profile; and verifying the user for access to the venue for the event.

[0008] In some embodiments, the platform may be a secure multi-tenant, (Software as a Service) SAAS based, ticketing platform. Each tenant in the platform may have the ability to customize the metadata, for example adding, renaming, re-ordering and controlling visibility of the fields and objects in their instance in a way that is isolated from other tenants. The platform may also enable the customization of tenant’s workflows and support the customization of these workflows including when and how different parts of a workflow may be performed through an integration into other systems.

[0009] In some embodiments, pricing may be provided for packages, not just seats. Packages can include unlimited flexible entitlement types. These can include, for example, seating, suites, clubs, parking, physical goods (e.g., t-shirts) and digital access (e.g., digital content streaming). Entitlements may be combined in any way as needed and pricing can be modified accordingly. [0010] In some embodiments, the platform may target packages to fans based on their profile and purchase history. For example, a VIP package including seat, valet parking, t-shirt and club access for premium price can be targeted at fans that have been to over X number of games, spent at least Y dollars and are tagged as high-income based on 3rd party data.

[0011] In some embodiments, the platform may provide unlimited flexible ticketing plans, flexible invoicing and billing, support for complex payment situations like payment plans, deposits, personal seat licenses (PSLs), customizable ticket release rules, and fraud detection and alerts, and so on. Other flexible ticketing plans are also contemplated.

[0012] In some embodiments, the platform may include open distribution and transfer features. For example, the platform may allow the users to decide on where to distribute inventory, provide fine grained inventory controls for when tickets are released, and with price and transfer rules, allow the users to know who a ticket is held by at every step of the way. The transfer platform may enable tracking resale on 3rd party platforms and decide on a ticket by ticket what the resale and transfer rules are, e.g., charity, fan, club, open. Other open distribution and transfer features are also contemplated.

[0013] In some embodiments, the platform may provide for significant control of the consumers. The platform can provide flexible role-based access control to determine what things people can see and what actions they can take. The platform can also provide secure authentication, including, for example, single sign-on (SSO).

[0014] In some embodiments, the platform may include flexible access control. For example, the platform can provide total control of how people access all parts of the events, including from paper seat locators to pure biometrics (including facial recognition) and other methods.

[0015] In some embodiments, the platform may further include a scan feature that may identify a person, the platform then may control what that person can access. In one aspect, this can enable the user to ensure that the person entering the event is the person who owns the account that has the tickets. The platform can be integrated into Point of Sale systems, suite scanners, parking, etc.

[0016] In some embodiments, the platform may provide event-day experience, for example, directions, upgrades, and engagement. The platform may also provide various event operations, for example, allowing users to see where the fans are and take real time action, e.g., move staff to different gates, message fans, while having accurate real-time, easy-to-understand scan counts.

[0017] In some embodiments, the platform may further include sophisticated dashboards and user interfaces.

[0018] Additionally, the present disclosure also includes systems and methods for validating the data acquired by the platform. For example, consumers and events data can be validated before use.

[0019] The embodiments of the present disclosure provide for practical applications to the field of ticketing and event management, and for improvements over prior modes in these fields. These improvements can include, for example, optimization of computer resources, improved data accuracy and improved data integrity, to name only a few. In a number of embodiments, instructions stored in the memory of computing devices (e.g., software) can cause one or more processors of the platform to perform the steps of the embodiments described herein.

[0020] The improvements of the present disclosure are necessarily rooted in computer-based systems for the acquisition, validation, analysis, and processing of events and ticketing data. Additionally, many of the embodiments disclosed herein reflect an inventive concept in the particular arrangement and combination of the devices, components and method steps utilized for acquiring, validating, analyzing and processing events and ticketing data.

[0021] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Moreover, it is noted that the invention is not limited to the specific embodiments described in the Detailed Description and/or other sections of this document. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.

BRIEF DESCRIPTION OF THE DRAWINGS [0022] The accompanying drawings, which are incorporated in and constitute a part of the specification, are for illustrative purposes only of selected embodiments, serve to explain the principles of the invention. These drawings do not describe all possible implementations and are not intended to limit the scope of the present disclosure.

[0023] FIG. 1 shows a high-level network view of a ticketing and guest experience platform, according to various embodiments of the present disclosure.

[0024] FIGS. 2 and 3 show a high-level overview of a server of the ticketing and guest experience platform, according to various embodiments of the present disclosure.

[0025] FIG. 4 shows an overview of the Event Operating System (EOS), according to various embodiments of the present disclosure.

[0026] FIG. 4.1 shows a high-level overview of an AI-driven NLP architecture of the platform of the ticketing and guest experience platform, according to various embodiments of the present disclosure.

[0027] FIGS. 5A and 5B show examples of graphical user interface (GET) for a fan or customer ticket, according to various embodiments of the present disclosure.

[0028] FIGS. 5C.1 to 5C.27 show example GUIs and process of purchasing a seat for an event at a stadium, according to various embodiments of the present disclosure.

[0029] FIGS. 5D.1 and 5D.2 show example GUIs for a fan to sell tickets to other fans, according to various embodiments of the present disclosure.

[0030] FIGS. 5E.1 to 5E.9 show example GUIs and process for a fan to bid for a seat, according to various embodiments of the present disclosure.

[0031] FIG. 5F.1 shows an example GUI for successful bid notification, according to various embodiments of the present disclosure.

[0032] FIGS. 5F.2 to 5F.4 show example GUIs and process for accepting a bid, according to various embodiments of the present disclosure.

[0033] FIGS. 6A and 6B show an example Inventory engine, according to various embodiments of the present disclosure.

[0034] FIG. 7 shows an example diagram of a Dynamic Pricing engine, according to various embodiments of the present disclosure. [0035] FIG. 8 A shows an example access control management overview, according to various embodiments of the present disclosure.

[0036] FIGS. 8B to 8E show example GUIs of access control dashboard, according to various embodiments of the present disclosure.

[0037] FIGS. 9A and 9B show an example facial recognition access control device, according to various embodiments of the present disclosure.

[0038] FIGS. 10A and 10B show example GUIs informing a fan being admitted into an event, according to various embodiments of the present disclosure.

[0039] FIG. 11 shows an example flow of fan location and targeting, according to various embodiments of the present disclosure.

[0040] FIGS. 12A to 12C show example GUIs of an offer, according to various embodiments of the present disclosure.

[0041] FIGS. 13A to 13F show example GUIs of the Fan Location and Targeting system, according to various embodiments of the present disclosure.

DETAILED DESCRIPTION

[0042] The present disclosure relates to systems and methods for providing a secure, real- time, cloud based, enterprise grade flexible, and scalable ticketing and guest experience platform.

[0043] It will be appreciated that for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements or steps. In addition, numerous specific details are set forth in order to provide a thorough understanding of the embodiments described herein. However, it will be understood by those of ordinary skill in the art that the embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the embodiments described herein. Furthermore, this description is not to be considered as limiting the scope of the embodiments described herein in any way, but rather as merely describing the implementation of the various embodiments described herein.

[0044] Generally, the platform may provide ticketing as a digital access credential. In some embodiments, the credential may include at least customer identity, payment and real-time geolocation metadata. In some embodiments, the platform may provide unlimited flexible pricing for seats, other entitlement types, packages of entitlements, ticketing plans. The platform may also provide flexible access control to events, fan marketing and engagement, sophisticated reporting and dashboards. The platform may further include an app (fan app) to provide customers flexible buying options and status reports.

[0045] As used herein, the term customer and fan may be used interchangeably. Other terms used herein include:

[0046] Fan - An attendee of an Event or Experience.

[0047] Enterprise User - A user who performs administrative and operational actions in the platform on behalf of an organization. In some applications, this may include organization administrators, TTO (Team Ticketing Operations) users, etc.

[0048] Organization - An organization defines a segmented set of data that may only be visible to Enterprise Users that belong to that organization (there maybe cases where subsets of data maybe shared across organizations). It may not map directly to a corporate entity, but it often does. In some applications, groups of users within the organization may be limited to only view/manage specific venues within the organization.

[0049] System - Global to the entire platform, Platform Administrators may be considered System Users.

[0050] Venue - A venue is a main facility where Events are held.

[0051] Event - Grants a Venue's inventory to fans for a limited duration. Events may be "Template Events" in which case they may not specify a specific day or time but may be used to facilitate copying a setup (such as a seating manifest and price allocations) from the template to multiple concrete events.

[0052] Event Group - A collection of related events. Event groups may be used to represent a Team's Season or the Summer Concert Series, for example.

[0053] Event Manifest - The layout of a Venue for an Event including inventory available, price allocations, VIP club access areas, etc.

[0054] Inventory - Inventory is used herein as a broad term which encompasses everything that may be sold or assigned to a Fan. Inventory maybe Seats at the Stadium, Parking, Merchandise, Concessions, etc. Inventory may be tracked at the Organization, Venue, or Event level.

[0055] Entitlement - A specific inventory instance that has been assigned to a fan, that fan is "entitled" to that inventory.

[0056] Allocation - An Enterprise user may allocate (or earmark or tag) inventory for a specific purpose. For example, Seats may be Allocated to a specific Price Tier, or for Employees only, or for Distribution to 3rd Party Partners, etc.

[0057] Assignment - When Inventory is assigned to a fan, that specific inventory item becomes that fan's entitlement. For example, Joe is Entitled to a T-Shirt, 2 Hot Dogs, 2 Sodas, and 2 Seats in Section 1L, Row 5, Seats 3-4.

[0058] Package - A grouping of inventory that is sold together and has a price for the overall package.

[0059] Order - Entity that anchors all workflows around commerce (selling inventory to fans), for example: when a new season is created, season ticket holders will have orders created for them to allow TTO users to reach out, find out if a fan wants to renew or relocate seats, and collect payment (or down payment if on a payment plan) to finalize the transaction. An order has a state associated with it to manage these state transitions through the system.

[0060] Access Controlled Area - Allows or blocks fans from entrance to a physical location based on an Access Credential that identifies that fan. Access may be granted based on whether the fan has been assigned the proper entitlement for that specific area.

[0061] Guess Access Record (GAR) - Contains information about, for example: the space and time range that the GAR admits a guest into (e.g., Pepsi Center Entry, Suite 45, etc.), the guest’s identity (e.g., fan profile image, name), metadata (e.g., seats, other entitlements). If the guest owns multiple tickets, then he has multiple GARs— 1 per ticket. GARs may be assigned to ticket using Packages Feature GUI or predetermined rules. In some embodiments, the platform may use event and ticket ownership information across all partner events to create guest access records. In some embodiments, a GAR may thus include a link to an event from which the GAR was created. User/Fan account may also include GAR. In some embodiment, an employee User account may include information from a GAR, e.g., for access to suites. [0062] Referring now to FIG. 1, a high-level overview of a secure, real-time, enterprise grade, flexible, and scalable ticketing and guest experience platform 100 (or platform 100 for brevity), according to some embodiments, is shown. The platform 100 may generally include a server system 130 (or server for brevity), at least one third party server system 150, all may be distributed on one or more logical and/or physical servers, each having one or more processors, memory, data storage, an operating systems, input/output interfaces, network interfaces, and other components and modules implemented in hardware, software or combinations thereof. In some embodiments, the platform 100 is could-based and server system 130 may be a cloud server. The platform 100 may further include an enterprise system 120 and a plurality of customer computing devices 110, 112 coupled to a public network 101, such as the Internet and/or a cellular-based wireless network. The servers, enterprise system and customer computing devices each may include one or more processors, memory, data storage, an operating system, input/output interfaces, network interfaces, engines and other components and modules implemented in hardware, software or combinations thereof. The servers, enterprise system and customer computing devices may each further include non-transitory computer readable memory storing instructions that, when executed by a processor may perform one or more embodiments of the platform 100 as described herein. The customer computing devices may include, for example, mobile devices, desktop or laptop devices. A mobile device may include smart phone, tablet, smart watch and other wearables.

[0063] Referring to FIGS. 2 and 3, a high-level overview 200 of the server 130, according to some embodiments, is shown. The server 130 may generally include three levels (or layers) of services. At the core is the cloud services 230 that may provide scalable, multi-geography, secure and resilient computing and storage services. The SAAS services 220 may include customizable and extensible multi -tenant cloud software providing common services. For example, user management, guest management, authentication, analytics, and so on. The platform may further advantageously include an events layer 210 that provide engines to manage venues, events, pricing, inventory, location, entitlement, access and so on. As used herein, the three layers 210, 220 and 230 may collectively be referred to as an Event Operating System (EOS). These services will be described in further detail below. In some embodiments, the tenants of the platform may include sports team users, or arena or stadium users. [0064] Referring to FIG. 4, in some embodiments, an overview 400 of the Event Operating System (EOS) is shown. The EOS may include the event services 470 as shown in 210 in FIGS. 2 and 3. The EOS may provide application program interfaces (API) and/or software development kits (SDKs) 450 to provide applications 430 accesses to the event services 470. In some embodiments, the EOS may include three types of applications: Enterprise, Distribution and Consumer. Logically above the applications 430 are access management engines 410. In some embodiments, the EOS may further include extensions 490 to support various special devices and configurations. For example, the EOS may include extensions 492 to support access management, such as rotating QR code, barcode, NFC, RFID, image recognition, door control, etc., extensions 494 to support location management, such as GPS, beacon, Bluetooth, image recognition, NFC, etc., and extensions 496 to support demand and pricing management, such as sports types (NFL, NBA, NHL, etc.), venue types (hotel, concert, etc.).

[0065] Organization Isolation

[0066] The platform may include many tenants, or organizations. In some embodiments, the platform ensures that records that are owned by a particular tenant cannot be seen or accessed by any other tenant. In some embodiments, access between tenants may be allowed, for example where a home team wants to allow access to tickets for a certain game to the away team, despite them being a different tenant in the system. Given the sensitivity of exposing tenant data to other tenants, the platform may by default restrict access.

[0067] In some embodiments, the platform may be configured for shared multi-tenancy. Several aspects of this approach include, for example, tenant isolation, performance monitoring and management, and development complexity. In some embodiments, with all tenants sharing a single database, the job of keeping tenant data isolated from other tenants (tenant isolation) may fall mostly, if not solely, to the application layer. Every query and save to the system database, may need to undergo some filtering layer that will be applied based on the current user context. For example, if the current user is an enterprise/organization user, then their organization id may be applied to all relevant top-level queries, joins, joined loads, and subqueries. If the current user is a system user, then their system id may be similarly applied, as organization id is for enterprise users. In some embodiments, different tenants may have different data sizes and potentially data shapes (depending on what they choose to store in flex columns). The platform may monitor performance metrics on an aggregate basis, across a single database, and may also monitor performance and metrics on a per-tenant basis. In some embodiments, the platform provide interfaces for code developers such that they need not know about how the platform or tenant-isolation is being implemented under the hood in order to develop a new feature which utilizes any kind of database query.

[0068] In some embodiments, the platform may support three types of users, Enterprise User, System User and Fan User. Each user may view the system from within a different context. As used herein, a "context" may be a lens or filter which is applied based on parameters on the user object itself. For example, when enterprise users log in, they can only view the system through the context of their own organization. They cannot see data outside of this, and that is the core principle of the multi-tenancy approach. When system users log in, from an API level they can view the system through the context of the system, meaning when they query for lower-level objects, they will see results across all organizations within their given system. In some embodiments, a system user may act as an enterprise user. That is, a system user can view the system through an enterprise user context, as if he were in an organization and assuming the role of a given organization user. This will be helpful, for example, for debugging and account management and such. When fan users log in, they also view the system from the context of the system. That is, for example, they can see tickets/events that they attended across all organizations.

[0069] Systems users may administer the system across enterprise boundaries. They are not scoped to a single Enterprise, although an access control system may limit the privileges of individual System User accounts. An example use case of system users may include create/onboard an Enterprise., including creating an Enterprise's first Enterprise User; perform customer support tasks for Enterprise Users, including Enterprise Admins (e.g., billing support, enabling/ disabling paid features); perform customer support tasks for Fan Users (e.g., account recovery, payments support), conduct analysis of platform data unified across all Enterprises; and enforce platform policies, licenses, and agreements (e.g., fraud mitigation).

[0070] The platform also serves two other classes of user: Fan Users, who attend events, and Organizations/Enterprises (Orgs), which create, manage, and run events. [0071] Enterprise Users (or Org Users) may operate on the system for the benefit of a particular Enterprise (e.g., team or venue). Each Enterprise User may have a single Home organization, which is the organization that owns that user record. In general, Enterprise Users may view the system exclusively in the context of their Home organization and can be considered scoped to that organization. An Enterprise Admin may be a user who has appropriate permissions to perform administrative functions in an organization. In some embodiments, for example, Enterprise Users may create and manage users, roles, and permissions within their Enterprise; create and manage venues, events, event series, and seasons within their Enterprise; analyze operating data of their Enterprise; manage access control at events within their Enterprise; view and manage data of Fan Users who have relationships with their Enterprise; and provide Enterprise-specific customer support to Fan Users (e.g., purchasing entitlements changing entitlements, billing/ payments support).

[0072] In some example use cases, Enterprise Users may operate across organization boundaries. To facilitate these use cases, Enterprise Users may be granted roles from organizations other than their Home organization. At any given time, an Enterprise User's view of the Enterprise Client may be in the context of a single organization, as such an Enterprise User with roles in multiple organizations may be able to switch context. As an example, there are two Orgs in the system, called Alpha and Beta. Alice is an Admin for Alpha and Bob is an Admin for Beta. Alice can create a new Enterprise User, Carol, in Alpha, which is then Carol's home Org. Alice can do any administrative tasks on Carol, including suspending and reinstating the account, as well as granting and rescinding roles within the Alpha Org. If Bob then grants Carol roles from the Beta Org, that allows Carol to do work in the context of the Beta Org (as per the permissions on those roles), but Bob can still only grant and rescind roles within Beta and cannot suspend, deactivate, or otherwise edit Carol. When Carol logs into the Enterprise Client, by default, she will be placed in the context of Alpha Org. By taking some action in the client, she can switch over to the Beta Org context, which causes the client to treat her as a user of Beta only.

[0073] Some examples of Enterprise Users (Orgs) may include US Major League preseason/ season/playoff game (e.g., NFL, MLB, NBA, NHL, MLS), where there is a home team owninf the venue or tenant venue, and an away team. There may be a neutral site game (e.g., NFL regular season London games) which may be different from managed or structured differently from "league" games (e.g., Super Bowl). Other Enterprise Users may be US Major League non team game, e.g., All Star Game, Pro Bowl, club soccer matches, tournaments, parent companies, touring sports events, touring music or art events, performing arts companies/venues, college sports, etc.

[0074] In some embodiments, Fan Users may be the ultimate consumers of the events held by the Enterprise users. Fan Users may not scope to any single Enterprise or System: they may hold entitlements from any Enterprise and attend any event in the system. In some embodiments, only Fan Users may hold entitlements. However, it's an important use case for individuals who interact with the system primarily as System Users or Enterprise Users to attend events. To support those use cases, Enterprise Users and System Users may link a Fan User account to those other account types. In some embodiments, for example, Fan Users may hold entitlements and attend events; make payments to Enterprises; and engage in money/entitlement transactions with other Fan Users. This may allow entitlements to be directed to an Enterprise or System User but have them transparently assigned to the linked Fan User, helping to maintain clean distinctions in the user model.

[0075] Data Models: In some embodiments, each table in the codebase may be associated with a system, indicating which system it belongs to. Most tables in the codebase may be associated with an organization, indicating which organization they belong to. This allows scoping everything within an organization for organization users. In some embodiments, some tables may hang off the system (e.g., artist, team, etc.) and may not need explicit organization ID fields on them, so these are exempt. Some tables may hang off either the system or the organization (e.g., role, permissions, metadata, etc.).

[0076] Query / Database Module: in some embodiments, to get access to a database session, all calls to save or query from the database go through a database module.

[0077] Query Wrapper Class: In some embodiments, queries are created (but not executed) at instantiations of this class and are created with a top-level entity to query against. Queries immediately get top-level filters applied for organization and system that are available in the current user context. Functions of this class may wrap all database module query appending functions (e.g., join, filter, etc.) and thus the platform provides custom wrappers for any such function that may affect multi-tenancy. Each function returns the executable query, so at any given moment the query returned by a wrapping function may be able to be executed in a safe, multi-tenancy compliant way.

[0078] In some embodiments, each tenant in the platform may customize the metadata in their instance. The tenant may add, rename and adjust the fields and objects in their instance in a way that is isolated from other tenants. In some embodiments, different tenants may have different workflows for the same types of activities in the system. The system may support the customization of these workflows including when and how different parts of a workflow may be performed through an integration into another system.

[0079] Referring now to FIGS. 5A and 5B, examples of graphical user interface (GUI) for a fan or customer ticket 504, according to some embodiments, is shown. A ticket may be a digital ticket that links a person's identity with a set of entitlements, or things that person should get or be able to do. Those entitlements, in turn, may be associated with physical spaces in a given venue. When a person's identity is confirmed at any of several access points, the associated entitlements are automatically evaluated, and access is granted to the union of those areas required by each of the entitlements. For example, if a user has entitlements to an autographing session (which happens to take place in the VIP club after a game is over) with the team's MVP along with a physical seat in the stadium, the user would have access to any general entry point, the specific gate leading to his or her seat, and, once the game ends, the VIP club. Because the system has detailed information of these physical spaces that house these events, and when these events occur, the system's access control can manage who can be where, and when.

[0080] In some embodiments, the platform may enable its event-owning customers to create arbitrary entitlements that semantically map to their internal CRM, POS, ERP, or CMS tools. Upon successful entry into an event+venue combination, the mapped, external tool is triggered via any of a variety of means, including webhook, direct RPC, or multicast radio connection. Such entitlement mapping may be performed manually by event staff or automatically through an integrated tool.

[0081] In the platform, a ticket may directly link a person's identity with a set of entitlements, or things that person should get or be able to do, e.g., physical spaces in a given venue. When a person's identity is confirmed at any of several access points, the associated entitlements are automatically evaluated, and access is granted to the union of those areas required by each of the entitlements. Access control will be described further below.

[0082] In some embodiments, a fan may use a Consumer App (e.g., App 111 and 113 shown in FIG. 1) to purchase tickets to an Event that he would like to attend. In some embodiments, once he has selected the Event already within the App, the App may present a highly-visual list of images taken from a fan's potential view in the available seats, along with basic price / location information. The fan can scroll fluidly through these available options and bringing an option "into focus" may activate additional visual elements that help communicate the potential energy / excitement available from that vantage point.

[0083] In some embodiments, the Consumer App may provide best option balancing price and experience, showing them potentially thousands of options on a map, in many cases with real differences in experience. The system may accommodate for high-supply / low demand, season ticket sales, fan wanting to sit next to friends in a known seat location etc.

[0084] In some embodiments, a fan process in viewing and purchasing may include a visualization of inventory. For example, a visual list may present seat view images in a smooth scrolling list alongside pricing and location details. When a fan lingers on or selects an image, additional visual content may be presented such as rolling a short video clip (still image may be the first keyframe) or dynamic animation content (e.g., camera flashes in the crowd, "intro lighting" shown on the court / stage) overlaid on still images. In another example, the App may show a preview image plus a control where the fan can manipulate the preview image, causing it to flip through the various options. This GUI may keep the relevant buy details visible on the screen below the preview image (buy now button).

[0085] In some embodiments, to create the fan GUIs, in venue, multiple cameras may be rigged to a fix height pole with gimbal stabilizer at "eye-level for a seated spectator capturing a mix of high-res still images, stereoscopic image pairs, stereoscopic video pairs, and at-least-l 80- degree video. In some embodiments, 360-degree view may be captured. This may further include an attached view finding to allow for reasonably precise "centering" on a focal point that may determine per event type (e.g., center ice vs center stage, etc.) to help control for a standard perspective. Multiple of these rigs may allow a crew of operators capture, record and tag the perspective from every seat and "area of interest" (club, concession stand, entrance, etc.) of the venue. The system may also include real time effects, define image regions such as "crowd" and "court / stage" and apply real-time lighting and animation, etc.

[0086] The fan GUIs may allow the fan to see the venue from the exact vantage point of the prospective seats, and to look around in a full spherical view to get a feel of the location. The platform may support multiple devices, for example, a fan may hold up a smart phone and move it around for a 2D view or use mobile VR devices.

[0087] In some embodiments, the platform may include an artificial intelligence (AI) natural language processing (NLP) interface, for example, in the ticket purchase process. An exemplary high-level overview of an AI-driven NLP architecture is shown in FIG. 4.1. An AI-driven NLP process may, for example, identify the user, including user data such as social profile, usage history of app / platform that the user’s request is made from. Based on this user identification and history, the platform may determine what the user is allowed to do, encouraged to do (e.g., a high-roller with verified payment info and a history of buying the best available entitlements regardless of price gets treated differently than a first time buyer with no stored payment info). In some embodiments, the process may mine and use user interaction for metadata (e.g., location, device details, identity, timing (e.g., 2 days before event), 1-1 communication, group chat, etc.).

[0088] In some example applications, a fan may receive a targeted ad on an event from the platform and may click on the ad to traverse to the platform to find details on event. The click action identifies user as being part of live event affinity group, and thus an input to future targeted groups and subsequent targeting. The fan may then decide to book tickets for the event that is in pre-sale window.

[0089] The fan may navigate a pre-sale GUI to indicate price preferences (range) and seat selection (e.g., sideline vs. endzone view, aisle, proximity to exit/restroom, shade/sun exposure) for event day. The platform may also suggest default seats and prices.

[0090] At any time, the platform may request the fan to create an account with a fan profile, including entering information to identify himself as a "real person" (i.e., not a bot or broker), including taking his photo (not a photo/ID scan) and, for example having entering a reCAPTCHA field. In some embodiments, the fan submits an ID "selfie" and performs a randomly selected gesture (e.g., a wink) to verify the selfie to prevent using pre-scanned video / images.

[0091] In some embodiments, the fan profile may also include other biometric data, for example finger prints.

[0092] In some embodiments, a fan profile may include a fan score which may be calculated based on factors such as social profiles, email and phone numbers, payment accounts, ID verification.

[0093] The above steps may be done on a website or from the Consumer App.

[0094] The fan may further add non-seat entitlements, for example promotional T-shirt, parking pass and VIP lounge access. In some embodiments, the entitlements may be offered based on membership in loyalty program.

[0095] The fan may then pay/check out and receive confirmation via push notification from the platform.

[0096] In some example applications, before the event, a fan may receive from the platform push notification indicating a person would like to purchase one of his seats, for example, at l.5x the face value of the seat. In some embodiments, the platform may include logic/rules indicating which tickets can and cannot be re-sold. In some embodiments, the platform may include logic/rules indicating proceeds on sale may be split in some fashion with the artist/team and the seller. The fan may decline the offer and indicate (to the system), for example, he will only entertain offers at least 2x over face value, and offer must include all seats in his entitlement collection.

[0097] In some embodiments, the system may allow a fan to change or gift a seat. For example, a fan may decide to bring a friend instead of child. He may navigate to game object GUI in the App and gift an independent, single-seat "ticket" to the friend for access purposes since they will be traveling independently. The system requires the fan to enter the friend's SMS number and sends the friend SMS with App install instructions and proceeds with install and account creation. The system may then allow the friend to navigate to seat map to see exactly where his gifted seat landed him. In an example, the friend notices a group of available seats directly in front of him, selects the seats and sends to others with recommendation to join him at the game. [0098] In some embodiments, before event day, the system may send push-notification to the fan notifying that the venue is, for example, 80% full, and offer the fan to upgrade, for example, to 3 rows closer for $5 each seat for a face value savings of $200. In some embodiments, the system may select a fan for offers. For example, the fan has large cart and revenue, is an influencer, etc. In some embodiments, the system may trigger offers based on needs and demands (e.g., for lower-priced seats, thus moving high value customers into better seats frees up more seats that are in higher demand at face value price).

[0099] In some embodiments, the system may further include a bidding feature. With this feature, an event is never“sold out”. Even when a fan does not see any seat he likes or can buy, he can still enable selecting sections or rows to bid on as an alternative to the "buy now" options. The App may then display a Bid GUI. In some embodiments, only sections and rows are displayed, but not individual seats. The fan may then select row(s) to bid on. A Pricing engine assists with prices. The fans who currently hold the entitlements (or tickets) for the seats in the bid row(s) are notified. When a fan accepts the bid, the ticket(s) is(are) transferred to the bidder.

[00100] In some embodiments, the system may include a Seat Control and Management engine (SCM). The SCM may include a Seat Manifest which is used in managing the seats. In some example applications, the system sets up venues with the available seats, and this is updated every season. This is known as the seat manifest. The seat manifest may be used to find available seats, and then the seat is placed as a 'hold' in a variety of ways. One of the primary reasons is to simply take it off availability while confirming the sale. Another reason may be to hold the seats for a fan (e.g., VIP fan). In some embodiments, the held seats are not visible to other users. Once sold, the seat is set as“assigned” or“sold” to a person. The exact seat manifest for an event is highly dynamic and can change many times between the time it is first created (pre-On Sale) up until fans are let into an event.

[00101] In some embodiments, the platform provides a Seat Map, especially for the Enterprise Users. A Seat Map may enable salespeople and Box Office employees to understand the location of the tickets they are selling, including the viewing experience or proximity to other key locations in a venue. The system may convey accurate information about ticket offerings overlaid onto an accurate seat map. The seat map may display fans at a venue based on various factors. For example, the system may display fans at the venue by section, fans segmented by fan profiles (including number of past events attended, geo data, social data, etc.), fans segmented by partner or third-party vendor, who are in event and who are arriving, etc.

[00102] In some embodiments, a seat map is a companion to the Inventory List. A seat map may also provide visualization of sales status and fan behavior during the event.

[00103] In some embodiments, the platform may further include an Inventory engine. The Inventory engine may be a software component of the platform that manages distribution of seat and non-seat inventory from (Org) issuers to fans, as well as the creation, management, and enforcement of rules and restrictions governing the transfer of inventory among fans after initial distribution.

[00104] FIGS. 5C.1 to 5C.27 show example GUIs and process of purchasing a seat for an event at a stadium. In all the figures of the present disclosure, the term“Rival” refers to the platform of the present disclosure. As shown, the platform may interactively communicate with the fan using the Consumer App. Upon receiving various inputs and requests from the fan, the platform may provide up-to-date, real-time data.

[00105] FIGS. 5D.1 and 5D.2 show example GUIs where the platform may provide to the fan who has purchased tickets to sell the tickets to other fans, using the Consumer App.

[00106] FIGS. 5E.1 to 5E.9 show example GUIs and process for a fan to bid for a seat for an event, using the Consumer App. In the figures,“Rival” refers to the platform of the present disclosure.

[00107] It should be noted that although the various examples and embodiments show the platform communication with the fans using the Consumer App, the platform may also communicate with the fans and other users using web interface, and other suitable forms.

[00108] After a fan has successfully made a bid for a seat, the platform may notify the current owner of the seat as shown in example GUI of FIG. 5F.1. FIGS. 5F.2 to 5F.4 show example GUIs and process for the selling fan to accept the bid. The platform may then notify the bidding fan that his bid has been accepted. When the bidding fan opens the Consumer App, the platform may display information indicating his ticket for the purchased seat. This fan may sell this ticket as shown above.

[00109] FIGS. 6A and 6B show an example Inventory engine 602, according to some embodiments. The Inventory Engine may manage distribution through a collection of Distribution Channel entities. Each Distribution Channel may be configured to offer one of more Products over a set of Inventory under a specific Pricing configuration. A Product is a complete specification of a commercial offering and terms and conditions for its sale, for example a single event admission, a series of admissions (as in season tickets), or a combination of items sold together as a unitary package. Inventory is specified as a selection of specific inventory items or an allocation of inventory from within a reserved pool. Both Product and Inventory have configured pricing, but the Distribution Channel itself allows those prices to be modified or overridden based on the needs of the issuer.

[00110] Each Distribution Channel is associated with an Outlet, which is the means used by a fan to transact on the Channel. Examples of Outlets include Box Office window, call center, mail-in, online, and so forth. This structure gives issuers fine-grained control over what fans have access to, how that inventory is packaged and sold, at what price, and through which means.

[00111] When Inventory is distributed to fans, issuers can place transfer rules on it that govern the conditions under which subsequent transfers are permitted to take place. These transfer rules may contain arbitrary business logic, according to the needs of the issuer. For example, an issuer may place rules on a seat that forbid its transfer under any circumstances (for example, in the case of seats donated or sold at a discount to charitable organizations). Alternatively, an issuer may allow inventory to be transferred back to the issuer only until some fixed date in the future. Or, an issuer may apply rules that allow the issuer to retain a portion of the transfer price paid by subsequent buyers.

[00112] These rules may be managed by issuers through the Inventory Engine. If a fan subsequently attempts to transfer inventory to another fan, the transfer request is submitted through the Inventory Engine. If the transfer meets the conditions specified in the transfer rules associated with that specific piece of inventory, the Inventory Engine approves the transaction and the ownership changes. If the transfer does not meet the conditions in the transfer rules, the Inventory Engine denies the transaction, and the original fan remains owner of the inventory [00113] Referring to FIG. 7, and as described, prices in the platform are dynamic. FIG. 7 shows an example diagram of a Dynamic Pricing engine, according to some embodiments. The system may set prices based on one or more of these factors: historical data 710; real time trend data 720, data from a third party, social data, etc.; demand data and projections 730, including seat location, typical desirability, desirability of the event, fan interests based on view/usage information; sales data, machine learning models, time until event day, etc. Pricing may also be personalized, e.g., per customer dynamic pricing based on lifetime value to an organization, propensity to spend during an event on additional food/drinks, merchandise upgrades, or future event tickets, membership in a group or demographic targeted for customer development, and so on. The system feeds these data into a Dynamic Pricing Engine (DPE) 702 which may continuously decide when and if pricing adjustments may be made. In some embodiments, to configure Dynamic pricing, an Enterprise ETser may set up configuration variables for seats or sets of seats such as: Minimum Price, Maximum Price, Incremental change amount maximum/minimum, Price Acceleration constraints (the rate at which the velocity changes).

[00114] In some embodiments, the system may also set pricing based on a "Heat Map" 750 of the venue for the event (or across events). The heat map may affect price properties on the seat such as "price velocity" which is a floating-point number between -1 and 1 and suggests how to affect the price of the seat (up or down) based on the incremental change amount. When a seat is sold, that will positively affect the velocity as well as have a ripple effect on the velocity of all the seats neighboring that seat based on a decay function. If no activity has happened related to a seat for a time, this indicates to the DPE that this seat is priced too high and will be set to a lower price in the next loop the DPE runs.

[00115] In some embodiments, the DPE may be trained using Neural Network approaches on all observable pieces of data about pre- and post-on-sale users, purchases, secondary market activity, event day data and additional transactions.

[00116] Although FIG.7 shows the DPE re-pricing seating inventory, it may also re-price other types of inventory, packages, parking, etc.

[00117] FIG. 8A shows an example access control management overview 800, according to some embodiments. At a venue, a fan first approaches a face recognition device 810 to gain access into the event. If the device 810 recognizes the fan, access is granted at Step 830, for example, by one or more of the access management engines 410 as shown in FIG. 4.

[00118] At Step 813, upon failure of the facial recognition access control device 810, in some embodiments, the system may first fall back to a human attendant equipped with a device 820 that has a full color screen. Immediately upon failure of the facial recognition access control device 810, information (including face photos) about a finite set of potential facial matches of known entitlement-holders is pushed to the device 820. At this point, Step 814, the human attendant may be able to visually inspect the person attempting to enter the venue and compare her to the images in the set of potential matches. If the attendant can affirmatively match the person to one of the photos, the attendant may simply touch the matching photo and allow the person into the venue.

[00119] At Step 815, if the attendant is unable to affirmatively match the user to a picture in the set of potential matches, the fall back chain continues, and the attendant asks to scan a QR code, which is made available through the Consumer mobile App, available to every account holder. Upon presentation of the QR code, an automated scan of the code is performed via a mobile or stationary device. In offline mode, the scanning device may be preloaded with the set of QR codes representing all potential attendees of that event. The code is then matched against that list, resulting in a pass/fail indication. Offline mode may be required, for example, in poor network conditions. In online mode, the scanning device transmits the target QR code to the platform, for example via the public internet, and receives a pass/fail response from the platform.

[00120] Note that the access control system at a given access point may be configured to always require a human attendant, never require a human attendant, or ask for a human attendant but continue the fallback after some period of inactivity on the part of the human attendant.

[00121] In some embodiments, with biometric access control, a ticket may not be needed. The fan is all the system may need to know. Everything else is contextual fan + context =“ticket”. The fan may take a selfie or upload an image of herself the first time she buys a ticket that requires that level of security, understanding that this is her access into the event. When the fan wants access, all she may need to do present herself to the system. She can do that with user ID via QR/RFID/BTLE, phone number - or anything that links to her account. In some embodiments, the fan may not need to bring a phone to the event. All the system may need is for users to have registered with a photo at some point, and have linked some information to their ID. Once the platform knows who the fan is, a scanner applies context - event and entitlement type - and checks/determines access. [00122] In some embodiments, the platform may support a mobile handheld scanner and a suite scanner. A deployed scanner may connect to the platform’s real-time API. The platform may also download all GARs for a space. As GAR generation and updates are dynamic, with real-time access, the scanner always has up-to-date guest access data. In some embodiments, the scanned data may be reported to the platform, for example, who is scanned, when, what event, and whether the guest uses all of his amenities, or entitlements. A scanner may be deployed in a space and covers multiple events in that space.

[00123] FIGS. 8B to 8E show example GUIs of an access control dashboard. In some embodiments, the dashboard may display real-time data for a space. The example shows access management for a large entertainment district where access control may be performed for specific venues or buildings within the district.

[00124] FIGS. 9A and 9B show an example facial recognition access control device 900, according to some embodiments. Once the device 900 recognizes a fan, the platform may send to the device 900 the fan’s profile for display as access is granted.

[00125] As shown in FIGS. 10A and 10B, at the same time that access is granted, the platform may send notification to the Consumer App which informs the fan (and event access control attendant) that all people in the digital ticket are now admitted into the event. For example, as shown in FIGS. 10A and 10B, four people (1010 and Seatsl0l2) are admitted into (entitled to) Parking lot Yellow Lot and Lexus Club (entitlements 1020).

[00126] In some embodiments, the platform may further include a Fan Location and Targeting system (FLT) to use fan location data as well as purchase preferences to present offers targeted to the fan, for example offer the fan a set of promotional up-sell opportunities or allow the fan to upgrade their seat or experience.

[00127] FIG. 11 shows an example flow 1100 of fan location and targeting, according to some embodiments. In the example, when a fan is located within a stadium or near an area of interest based on input data flowing into the Fan Location and Targeting system (e.g., Fan Location Data, Preferences and Purchase History, Demographic data), a Promotional Engine (PE) may decide what offers and/or up-sell / upgrade opportunities are available and based on the fan's preferences and purchase habits, may suggest one or more of the offers. The offer will be sent to the fan's mobile device which allows the fan user to accept the upgrade or offer. If the offer is a voucher, the fan may, for example, take his/her mobile device to the concessions or merchandise location which allows a beacon, NFC or QR code on the mobile device to integrate with the Point of Sale system at the vending station.

[00128] FIGS. 12A to 12C show example GUIs of an offer sent to a fan’s mobile device and the Consumer mobile App. The Consumer mobile App may allow the fan to view or dismiss the offer.

[00129] FIGS. 13A to 13F show examples GUIs of the Fan Location and Targeting system (FLT). For example, in FIGS. 13A and 13B GUIs, the platform may provide campaign creation based on fan segmentations using one or more criteria (e.g., attendance, demographic, income), and group targets. In FIGS. 13C to 13F GUIs, the platform may allow the user to locate and target at specific venue. FIG. 13F shows an example preview of a targeted offer message.

[00130] It should also be noted that all features, elements, components, functions, and steps described with respect to any embodiment provided herein are intended to be freely combinable and substitutable with those from any other embodiment. If a certain feature, element, component, function, or step is described with respect to only one embodiment, then it should be understood that that feature, element, component, function, or step can be used with every other embodiment described herein unless explicitly stated otherwise. This paragraph therefore serves as antecedent basis and written support for the introduction of claims, at any time, that combine features, elements, components, functions, and steps from different embodiments, or that substitute features, elements, components, functions, and steps from one embodiment with those of another, even if the following description does not explicitly state, in a particular instance, that such combinations or substitutions are possible. It is explicitly acknowledged that express recitation of every possible combination and substitution is overly burdensome, especially given that the permissibility of each and every such combination and substitution will be readily recognized by those of ordinary skill in the art.

[00131] To the extent the embodiments disclosed herein include or operate in association with memory, storage, and/or computer readable media, then that memory, storage, and/or computer readable media are non-transitory. Accordingly, to the extent that memory, storage, and/or computer readable media are covered by one or more claims, then that memory, storage, and/or computer readable media is only non-transitory. [00132] While the embodiments are susceptible to various modifications and alternative forms, specific examples thereof have been shown in the drawings and are herein described in detail. It should be understood, however, that these embodiments are not to be limited to the particular form disclosed, but to the contrary, these embodiments are to cover all modifications, equivalents, and alternatives falling within the spirit of the disclosure. Furthermore, any features, functions, steps, or elements of the embodiments may be recited in or added to the claims, as well as negative limitations that define the inventive scope of the claims by features, functions, steps, or elements that are not within that scope.

[00133] It is to be understood that this disclosure is not limited to the particular embodiments described herein, as such may, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting.

[00134] As used herein and in the appended claims, the singular forms“a,”“an,” and“the” include plural referents unless the context clearly dictates otherwise.

[00135] In general, terms such as“coupled to,” and“configured for coupling to,” and“secure to,” and“configured for securing to” and“in communication with” (for example, a first component is“coupled to” or“is configured for coupling to” or is“configured for securing to” or is“in communication with” a second component) are used herein to indicate a structural, functional, mechanical, electrical, signal, optical, magnetic, electromagnetic, ionic or fluidic relationship between two or more components or elements. As such, the fact that one component is said to be in communication with a second component is not intended to exclude the possibility that additional components may be present between, and/or operatively associated or engaged with, the first and second components.

[00136] As used herein, the term“and/or” placed between a first entity and a second entity means one of (1) the first entity, (2) the second entity, and (3) the first entity and the second entity. Multiple entities listed with“and/or” should be construed in the same manner, i.e.,“one or more” of the entities so conjoined. Other entities may optionally be present other than the entities specifically identified by the“and/or” clause, whether related or unrelated to those entities specifically identified. Thus, as a non-limiting example, a reference to“A and/or B”, when used in conjunction with open-ended language such as“comprising” can refer, in one embodiment, to A only (optionally including entities other than B); in another embodiment, to B only (optionally including entities other than A); in yet another embodiment, to both A and B (optionally including other entities). These entities may refer to elements, actions, structures, steps, operations, values, and the like.

[00137] Various aspects have been presented in terms of systems and engines that may include several components, modules, and the like. It is to be understood and appreciated that the various systems and engines may include additional components, modules, etc. and/or may not include all the components, modules, etc. discussed in connection with the figures. A combination of these approaches may also be used. The various aspects and embodiments disclosed herein can be performed on electrical devices including devices that utilize touch screen display technologies and/or mouse-and-keyboard type interfaces. Examples of such devices include computers (desktop and mobile), smart phones, personal digital assistants (PDAs), and other electronic devices both wired and wireless.

[00138] In addition, the various illustrative logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[00139] Operational aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.

[00140] Furthermore, the one or more versions may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed aspects. Non-transitory computer readable media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips...), optical disks (e.g., compact disk (CD), digital versatile disk (DVD), BluRay™...), smart cards, solid-state devices (SSDs), and flash memory devices (e.g., card, stick). Of course, those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope of the disclosed aspects.

Claims

CLAIMS What is claimed is:

1. A computer-implemented method for providing real-time, flexible, and scalable ticketing and guest experience by one or more processors, the method comprising:

obtaining data of a venue of an event, wherein the data comprises one or more 180- degree views;

providing one or more graphical user interfaces to a user for selecting one or more seats at the venue;

receiving one or more seat selections;

calculating a price for the one or more seat selections;

providing the price for the one or more seat selections;

receiving purchase order for the one or more seat selections;

requesting one or more biometric data of the user; and

creating a digital ticket for the one or more seat selections.

2. The method of claim 1, wherein the one or more 180-degree views comprise perspective view from every seat and area of interest of the venue.

3. The method of claim 2, wherein the one or more 180-degree views are videos.

4. The method of claim 1, wherein the one or more graphical user interfaces comprise one or more 180-degree perspective views from the one or more selected seats.

5. The method of claim 1, wherein calculating the price is based on at least one of historical data, real time trend data, data from a third-party, social data, demand data and projections, the user’s interests, and time until day of the event.

6. The method of claim 5, wherein the demand data and projections comprise at least seat location, typical desirability and desirability of the event.

7. The method of claim 5, wherein the user’s interests comprise at least view and usage information, and sales data.

8. The method of claim 1, wherein calculating the price is based on one or more machine learning models.

9. The method of claim 1, wherein calculating the price is based on one or more heat maps of the venue.

10. The method of claim 1 further comprises providing one or more graphical user interfaces to the user for selecting one or more non-seat entitlements.

11. The method of claim 10, wherein the one or more non-seat entitlements comprises at least one of parking and physical goods.

12. The method of claim 1, wherein the one or more biometric data is a facial picture of the user.

13. The method of claim 12, wherein the facial picture is verified with a randomly selected gesture.

14. The method of claim 1, wherein the purchased one or more seat selections and the biometric data are further stored in a fan profile.

15. The method of claim 1 further comprises providing one or more graphical user interfaces to the user for offering the one or more purchased seat selections for sale.

16. The method of claim 1 further comprises providing one or more graphical user interfaces to the user notifying the user a person is interested in purchasing the one or more purchased seat selections.

17. A computer-implemented method for providing real-time, flexible, and scalable ticketing and guest experience by one or more processors, the method comprising:

obtaining data of a venue of an event, wherein the data comprises one or more 180- degree views; providing one or more graphical user interfaces to a user for selecting one or more seats at the venue;

receiving one or more seat selections;

calculating a price for the one or more seat selections;

providing the price for the one or more seat selections;

receiving purchase order for the one or more seat selections;

requesting one or more biometric data of the user;

creating a digital ticket for the one or more seat selections;

storing the purchased one or more seat selections and the biometric data in a fan profile; and

verifying the user for access to the venue for the event.

18. The method of claim 17, wherein verifying the user comprises facial recognition.

19. The method of claim 18, wherein upon an unsuccessful verification of the user, further providing a set of potential images for matching with the user.

20. The method of claim 19, wherein upon an unsuccessful matching the user with the set of potential images, further scanning a QR code.