ACCESS THROUGH PAYMENT ACCOUNTS

CROSS-REFERENCE TO RELATED APPLICATIONS This application is a PCT International Application of, and claims priority to. United States Patent Application No, 15/334,665, filed October 26, 2016, and United States Patent Application No. 15/062,635, filed on March 7, 2016. In addition, United States Patent Application No. 15/334,665 is a contmuaiion-nv-part of United States Patent Application No. 15/062,635. The entire disclosures of the above applications are incorporated herein by reference.

FIELD

The present disclosure generally relates to systems and methods for facilitating access to events, via access credentials for one or more events based on payment accounts associated with such events, whereby payment devices associated with the payment accounts can then be used to provide access to the events,

BACKGROUND

This section provide background information related to the present disclosure which is not necessarily prior art.

Often, payment accounts are used by consumers to purchase tickets for events such as, for example, sporting events, concerts, transit/travel events, etc. Typically, once the tickets are purchased, they are delivered to the consumers, in person, by mail, or electronically. The tickets may be hard tickets (e.g., paper tickets, etc.) encoded with holograms and/or other security mechanisms, and which are physically delivered to the consumers from the event organizers. Other tickets ma be electronic tickets that are delivered to the consumers via e-mail or otherwise from the event organizers, in either ease, the tickets are then physical iy presented by the consumers, at the site of the events, in order for the consumers to gain access to the events,

DRAWINGS

The drawings described herein are for illustrative purposes only of selected embodiments and not all possible implementations, and are not intended to limit the scope of the present disclosure, FIG, I is a block diagram of an exemplary system of the present disclosure suitable for use in associating access to events, for consumers, with payment accounts of the consumers and for facilitating such access to the events, by the consumers, based on the association;

FIG. 2 is a block diagram of a computing device thai may be used in the exemplary system of FIG. I ;

FIG . 3 is an exemplary method, suitable for use with the system of FIG. I , for associating access to an event with a payment account of a consumer purchasing such access;

FIG, 4 is an exemplary method, suitable for use with the system of

FIG. .1 , for facilitating access to an event, for a consumer, through use of a payment account associated with the consumer; and

FIG. 5 is aa exemplary access interface that may be displayed in connection with the system of FIG. I and/or the method of FIG. 3 and/or the method of FIG . 4, for facil itating access to an event, tor a cons umer, through use of a payment account associated with the consumer.

Corresponding reference numerals indicate corresponding parts throughout the several views of the drawings.

DETAILED DESCRIPTION

Exemplary embodiments will now be described more full with reference to the accompanying drawings. The description and specific examples included herein are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure.

Tickets, whether in hard or electronic form, are often employed to control access to events, such as, for example, sporting events, movies, concerts, transit airline flights, etc. Typically, event merchants offer the tickets for sale and sell the tickets to consumers, who then present the tickets, in hard or electronic form, at the events in order to gain access to the events. Uniquely, the systems and methods herein permit linking between payment accounts and events based on purchased tickets, whereby the payment accounts (or payment devices representative thereof, etc.) may be used to gain access to the events, in particular, upon a payment account transaction by a consumer at an even t merchant to purchase ticket to an event, an authorization request is compiled by the event merchant for the transaction, which includes event, ticket, and a ment content. When the authorization request is received at a payment network and/or an access engine, a link between the payment account and the event is created (if the transaction is approved, and when the event, the consumer, and/or the event merchant are registered, for example). Subsequently, to gain access to the event, the consumer presents a payment device associated with the linked payment account at the site of the event (e.g., at a gate, etc.). In turn, the event merchant at the site submits an authorization request to the payment network, which is identified as an access request {e.g., by including a reserved merchant category code ( CC) in the authorization request, etc.). in response, the payment network and/or the access engine determines whether the payment account (associated with the presented payment device) is linked to one or more tickets for the event, if uch link exists, an authorization reply is returned to the event merchant, which indicates access for the consumer and potentially details of the access for the consumer (e.g., number of tickets, seat numbers, section numbers, etc).

FIG. t illustrates an exemplary system 100, in which the one or more aspects of the present disclosure may be implemented. Although the system ^' J 00 is presented in one arrangement, other embodiments .may include the parts of the system 1 0 (or other parts) arranged otherwise depending on, for example, processing of transactions in the system 100, arrangement and/or interoperability of acces engines and/or payment networks for facilitating access, etc.

The system 100 generally includes event merchants 102a-b, an acquirer 104, a payment network 106, and an issuer 1 8, each coupled to (and in communication with) network 1 10. The network 1 1 may include, without limitation, a local area network (LAN), a wide area network (WAN) (e.g., the Internet, etc.), a mobile network, a virtual network, and/or another suitable public and/or private network capable of supporting communication among two or more of the parts illustrated in FIG. I , or an combination thereof. For example, network 1 10 may include multiple different networks, such as a private payment transaction network made accessible by the payment network 106 to the acquirer 104 and the issuer .108 and, separately, the public Internet, which may provide interconnection between one or more of the event merchants 102a-b, the payment network 1 6, an access engine .1 .18, and consumers .1 .12a-b (or communication devices associated with the consumers 1 t2a-b), etc. The event merchants H)2a-b are generally associated with one or more events, such as for example, sporting events, movies, concerts, transit/travel events (e.g, airline flights, bus trips, etc.). etc, to which the event merchants K ⁾ 2a-b offer access (e.g., via tickets, passes, etc.) for sale to consumers in the system 100, including the consumers I ! 2a-b. In this exemplary embodiment, the merchant 102a is a merchant offering tickets tor at least one music event, such as, for example, a concert or a festival, while the merchant 102b is an airline merchant (e.g., an airline, etc.) offering tickets for airline flights, etc it should be appreciated that the events for which tickets are offered for sale by the event merchant 102a-b are often associated with event sites 1 14a-b. at which the events are located and/or at. which event access is needed. The event sites I I 4a~b may include, for example, concert venues, sports arenas/venues, buses, boats, airports, airplanes, theaters, or other locations, vehicles, or transports, often depending on the type of events, etc. Consistent with the above, in this example, the event site 1 14a is a conceit venue, at Madison Square Garden, in. New York, New York, while the event site 1 14 is an airplane, which is scheduled for flight # 12345 from St. Louis, Missouri, Lambert Airport, to New York, JFK Airport,

The event merchants 102a-b .may be located at or in proximity to, the sites of the events (i.e., at the event sites J 14a-b), as shown in FIG. 1 , or

geographically separate from the event sites .1 14a-b, or other event sites, in one or more other locations. For example, the airline merchant 102b may offer airline tickets for sale through one or more network-based applications (e.g., websites, etc), which are located apart from the airplane and/or airport (broadly, the event site .1 t4b), to which the consumer is purchasing access. Moreover, the event merchants 102a-b may include multiple parts entities located at different areas, for example, at the event sites .1 !4a«b and at other sites, etc Further, the event merchants 102a~b may foe associated with multiple event sites (including the event sites 1 14a~b) and access thereto, and/or may also be associated with one or more other products (e.g., goods and/or services, etc.) for sale (i.e., as a traditional merchant), it should be appreciated that, while only two event merchants 102a-b, two consumers I i.2a-b, and two event, sites I. I4a-b are illustrated in the sy tem 100 for ease of reference, a different number of event merchants and/or consumers and/or event sites may be included in the system 100 in other embodiments.

in addition, the event merchants 102a-b are also associated with terminals 1 16a-b, such as, for example, point-of-sale (POS) terminals, etc., suitable to interact with the acquirer 104 (which is associated with, both event merchants l.02a-b in the system 100) and/or the payment network 106, or other parts of system 100, in this exemplary embodiment the terminals ί 16a-b may include, or may be associated with, a network-based application, which is provided to cause the terminals I 16a ^« b to uniquely operate as described herein. In particular, th terminals 1 16a-b, for example, may be configured, by the application, to compile authorization messages (e.g., including event content, ticket content, payment content, etc), to transmit

authorization messages, to receive authorization replies, and to, when appropriate, present access outputs (and details) or denial outputs to (he event merchants 102a-b and/or the consumers 1 Ϊ 2a-b. This will be described in more detail hereinafter,

With continued reference to FIG. L each of the consumers ί i2a-b is associated with a payment account, which is associated with a payment device {not shown in FIG. I). The payment device may be a conventional card form, a fob form, or it may be in. a virtual wallet form in a communication device, such as, for example, a smariphone, tablet, etc. The consumers i. 12a-b may purchase access to one or more events from the event merchants 102a~b, in the font) of tickets (e.g., virtual tickets, etc.), through transactions funded by each consumers' payment accounts.

In one example, the consumer 1 1 2a may purchase tickets for at least one music event at the event merchant 102a (e.g., the concert at Madison Square Garden, etc.), b use of a payment account. As part of the purchase, the consumer 1 12a specifies and/or selects (at the terminal 1 16a. or via a sales assistant at the merchant 102a ) the number of tickets and may further select seats and/or sections within the event site .1 14a, Additional details related to the tickets and/or the consumer 1 12a (or the event) may further be selected, such as, for example, additional access {e.g., backstage access, etc.), ticket type (e.g., standard, VIP, etc.), parking options, etc. Similarly, additional information ma be available about the event, from the merchant 102a, including, for example, event ID, time/date, event site address, etc. The consumer 1 12a (hen presents his/her payment device to the event merchant 102a for purchase.

In another example, the consumer } 12b may purchase one or more tickets for {light events (e.g., the ticket for flight #12345 from St, Louis, Missouri, Lambert Airport to New York, JFK Airport; etc.) from the event merchant 102 b. in doing so, the consumer 1 12b may purchase one ticket or multiple tickets for himself/herself family, friends, business associates, etc. Further the consumer 1 12b may specify and/or select (at the terminal 1 16b or via a sales assistant at the merchant 102b) seat numbers for each of the tickets, or the airline merchant 102b may assign seat numbers without the consumer's input, or a combination thereof, etc. Additional details related to the tickets and/or the consumer 1 12b may further be selected, such as, for example, flight numbers, flight origin, and/or destination, time/date, additional access (e.g., sky club access, etc.), ticket type (e.g., standard, business class, first class, refundable, nonrefundable, automatic check-in, etc.), meal preferences, special instructions, disabilit accommodations, frequent flier or rewards content, etc.

Similarly, additional information may be available about the event, from the merchant 102b, including, for example, event ID (e.g., flight number, etc.), time/date, flight origin and/or destination, etc. The consumer 1 12b then presents his/her payment device to the event merchant 102b for purchase.

In the above transactions, either the event merchant 1 2a or the event merchant 102b, and specifically, the terminal I 16a or 1 16b associated therewith, reads the payment devices presented by the consumers 1 i 2a~b and compiles an

authorization request- The authorization request is submitted to th acquirer 104, to determine whether the respective payment account is in good standing and whether there is sufficient credit and or funds to cover the transaction. The authorization request is transmitted along path A in the system .100, as referenced in FIG. 1. In connection therewith, the acquirer 104 communicates the authorization request with the issuer 108 (associated with the consumer's payment account), through the payment network 106, such as, for example, the payment network operated by

Mastercard International Incorporated, the assignee of the present disclosure. In turn, if approved, an authorisation reply or response (indicating the approval) is transmitted back from the issuer 1 8 to the e vent merchant 1 2a or event merchant 102b, along path. A, thereby permitting the event merchant 102a to complete the transaction. The transaction is later cleared and or settled (via appropriate transaction messages such as clearing messages and/or settlement messages) by and between the event -merchant 102a, the acquirer 104, and the issuer 108 (by appropriate agreements). If declined, however, the authorization reply (indicating a decline) is provided back to the event merchant 102a or the event merchant 102b, along the path A, thereby permitting the event merchant 102a to halt or terminate the transaction.

In connection with the above transactions, both the authorization requests and the authorization: replies include ISO 8583 authorization messages (broadly, ISO 8583 transaction messages) (e.g. , a 0120 ISO-standard message, another ISC) message, etc.}. it should be appreciated that similar transactions, resulting in similar messages, may also (or alternatively} be performed between the consumer 112a and the event merchant i02a and/or between the consumer 1 12b and the event merchant 102b, which may avoid one or more parts of path A above.

Transaction data, is generated, collected, and stored as part of the above example interactions among the event merchant: 102a, the acquirer 104, the payment network 106, the issuer 108, and the consumer 1 12a (and among the event merchant 102b, the acquirer 104, the issuer 108, and the consumer ί 12b). The transaction data represents at least a plurality of transactions, for example, authorized transactions, cleared and/or settled transactions, attempted transactions, etc. The transaction data, io this exemplary embodiment, is stored at least by the payment network 106 (e.g., in a data structure associated with the payment network 106, etc.). Additionally, or alternatively, the event merchants i 02a-b, the acquirer 104 and/or the issuer 108 may store the transaction data, or part thereof, in a data structure, or transaction data may be transmitted between parts of system 100 as used or needed. The transaction data may Include, for example, primary account numbers (PA s) for consumers involved in the transactions, amounts of the transactions, merchant IDs for merchants involved in the transactions, merchant category code CMCCs), dates/times of the transactions, products purchased and related descriptions or identifiers, etc. It should be appreciated that more or less information rela ted to transactions, as part of ei ther authorization or clearing and/or settling, may be included in transaction records and stored within the system 100, at the event merchants i02a-b, the acquirer 104, the payment network 106 and/or the issuer 108.

in various exemplary embodiments, consumers (e.g., consumers Π.2&- b, etc) involved in the different transactions herein are prompted to agree to legal terms associated with their payment accounts, for example, during enrollment in their accounts, etc. In so doing, the consumers may voluntarily agree, for example, to allow merchants, issuers, payment networks, etc. to use data collected during enrollment and/or collected in connection with processing the transactions,

subsequently for one or more of the different, purposes described herein. Further, while one acquirer 104, one payment network 106, and one issuer 108 are illustrated in FIG. 1 , it should be appreciated that any number of these entities (and their associated components) may be included in the system 100, or raay be included as a part of systems in other embodiments, co.osiste.nt with the present disclosure.

FIG. 2 illustrates an exemplar computing device 200 that can be used in the system 100. The computing device 200 may include, for example, one or more servers, workstations, personal computers, POS terminals, laptops, tablets, s artphones, PDAs, etc. in addition, the computing device 200 may include a single computing device, or it may include multiple computing devices located in close proximity or distributed over a geographic region, so long as the computing devices are specifically configured to function as described herein.

in the exemplary embodiment of Flij. 1, each, of the acquirer 104, the payment network 106, and the issuer 108 are illustrated as including, or being implemented in, computing device 200, coupled to (and in communication with) the network 1 10. In addition, the terminals i !6a-h and the access engine 1 18 may each be considered a computing device consistent with computing device 200, for example, to accomplish one or more operations described herein. However, the system 100

(and the various parts thereof) should not be considered to be limited to the computing device 200, as described below, as different computing devices and/or arrangements of computing devices may be used. In addition, different components and/or arrangements of components ma be used in other computing devices.

Referring to FIG. 2. the exemplary computing device 200 includes a processor 202 and a memory 204 coupled to (and in communication with) the processor 202, The processor 202 may include one or more processing units (e.g., in a multi-core configuration, etc.). For example, the processor 202 may include, without limitation, a central processing unit (CPU), a microcontroller, a reduced instruction set computer (RISC) processor, an application specific integrated circuit (ASIC), a programmable logic device (PLD), a gate array, and/or any other circuit or processor capable of the functions described herein.

The memory 204, as described herein, is one or wore devices that permit data, instructions, etc., to be stored therein and retrieved therefrom. The memory 204 may include one or more computer-readable storage media, such as, without limitation, dynamic random access memory (DRAM), static random access memory (SRAM), read only memory (ROM), erasable programmable read only memory (EPROM), solid state devices, Hash drives, CD-ROMs, thumb drives, .floppy disks, tapes, hard disks, and/or any other type of volatile or nonvolatile physical or tangible computer-readable media. The memory 204 may be configured to store, without limitation, transaction data, links between payment accounts and events, ticket purchase history and/or details (e.g., number of tickets, seat/section numbers, event IDs, date/time, event site, destinations, origins, descriptions, etc.), and/or other types of data (and or data structures) suitable for use as described herein.

Furthermore, in various embodiments, computer-executable instructions may be stored in the memory 204 for execution by the processor 202 to cause the processor 202 to perform one or more of the functions described herein, such that the memory 204 is a physical, tangible, and non-transitory computer readable storage media. Such instructions often improve the efficiencies and/or performance of the processor 202 that is performing one or more of the various operations herein. It should be appreciated that the memory 204 may include a variety of different memories, each implemented in connection with one or more of the functions or processes described herein.

in the exemplary embodiment, the computing device 200 also includes a presentation unit 206 that is coupled to (and is In communication with) the processor 202 (however, it should be appreciated that the computing device 200 could include output devices other than the presentation unit 206, etc.). The presentation unit 206 outputs information (e.g., access outputs (and details), denial outputs, etc.), visually, for example, to a user of the computing device 200, such as the consumers 1 12a-b in the system 100 (e.g., via a communication device consistent with computing device 200, etc.); users associated with one or more of the event merchants i 2a-b and/or the terminals 1 16a-b; etc. It should be further appreciated that various interfaces (e.g., as defined by internet-based applications, websites, etc.) may be displayed at computing device 200, and in particular at presentation unit 206, to display certain information. The presentation unit 206 may include, without limitation, a liquid crystal display (LCD), a light-emitting diode (LED) display, an organic LED (OLED) display, an "electronic ink" display, speakers, etc. In some embodiments, presentation unit 206 includes multiple devices. Additionally or alternatively, the presentation unit 206 ma include printing capability, enabling the computing device 200 to print test, images, and the like on paper and/or other similar media. For instance, the terminals 1 16a-b may print out access and/or event information, onto paper, as described beiow.

in addition, the comparing device 200 includes an input device 20S that receives inputs from the user (i.e., user inputs) such as, for example, selections of events and/or details related thereto, selections to opt into linking payment accounts and event access, different inputs for the user to register to the access engine 1 18, etc. The input device 208 may include a single input device or multiple input devices. The input device 208 is coupled to (and is in. communication with) the processor 202 and may include, for example, one or more of a keyboard, a pointing device, a mouse, a stylus, a magnetic stripe reader, a touch sensitive pane! (e.g., a touch pad or a touch screen, etc.), another computing device, and/or an audio input device. Further, in various exemplary embodiments, a touch screen, such as that included in a tablet, a srnariphone, or similar device, behaves as both a presentation unit: and an input device.

f urther, the illustrated computing device 200 also includes a network interface 210 coupled to {and in communication with) the processor 202 and the memory 204. The network interface 210 may include, without limitation, a wired network adapter, a wireless network adapter, a mobile network adapter, or other device capable of communicating to one or more different networks, incl uding the network Ί 1 . Further, in some exemplary embodiments, the computing device 200 includes the processor 202 and one or more network interfaces incorporated, into or with the processor 202.

Referring again to FIG. 1 , the system 100 includes the access engine 1 1 8, wh ich: is specifically configured, by computer executable instructions, to perform one or more of the operations described herein. The access engine 1 18 is illustrated a being a standalone part of the system 100, but is described in the following example as associated with the payment network 106 (as indicated by the solid arrow line), such that it may be incorporated in whole or in part therein. As described above, the access engine 1.18 may be considered a computing de ice consistent, with computing device 200 (or may be considered implemented via the computing device 200 associated with the payment network 106), Moreover, as indicated by the additional solid arrow lines extending from the access engine 1 18 and the dashed circles at the event merchants 1 2a-b, the access engine 1 18 may additionally (or alternatively) be associated or incorporated (at least in part) with the event merchant 102a and/ or the event merchant 1 2a-b. Further, in various other embodiments,, it should be appreciated that the access engine 1 1 may be associated with, or incorporated with, still other parts of the system 100, for example, the acquirer 104, the issuer 108, etc, or may be a standalone part of the system .100. In this exemplary embodiment, the access engine 118 alone, or in combination with the payment network 106, is configured to provide a linked access service to merchants, including the merchants i f)2a-b, and to consumers, including the consumers 1 12a-b. In connection therewith, the access engine 1 18 is configured to register the merchants 102a-b (to the access engine 1 18), and the events for which tickets are offered for sale by the merchants I02a-b (prior to occurrences of the events). It should be appreciated that a variety of different registration techniques and/or interact ions are within the scope of the present disclosure. Regardless of the techniques and/or interactions, though, the access engine 118 is configured to then compile a iist. of regtstered merchants and/or events (which may be incorporated into an access data structure 120, described below) for use in. ultimately providing access to the consumer I i 2a-b for the events.

As an example, the access engine 1 i 8 may register merchants

(including the merchants I02a-b) via a merchant portal (e.g.* via a user interface associated therewith, a web service associated therewith, an appropriate network- based application, etc.) for the linked access services described herein, in connection therewith, the access engine 1 18 may include (or be associated with) a relational data structure (e.g., as part of the access data structure .120, etc.) that can be accessed by the merchants, via the merchant portal, to allow the merchants to tie/link their events to specific terminals (e.g., to terminals 1 16a-b. etc.), which will be used by the merchants to facilitate access to the events, in so doing, the terminals may be identified either via an Acquirer ICA ( nterbank Card Association) and or a Merchant ID or other data -fields configured on the terminals to show as "gateways" for the specified events to grant access, in addition:, the relational data structure may include information, as received from the merchants during registration via the merchant portal (or received otherwise), relating to the merchants (e.g., contact information, address, website information for customer servicing, notification preferences, etc) and relating to various events associated with the merchants and desired to be registered (e.g., information identifying the events as relating to air travel, rail travel, theatre events, musical concerts, etc.; geo-Iocational data about the events; latitude and longitude coordinates for the events; etc.). Then, once registered, the merchant, portal may instruct the merchants how to configure their new events and how to do configure their terminals for the specific events, and may generate/facilitate notifications (e.g., real-time notifications, etc.) for the merchants regarding their registered events,

in the above transaction between the event merchant 102a and the consumer 1 12a (for the purchase of the ticket to the concert at Madison Square

Garden), when the purchase of the ticket from the event merchant 102a is attempted, the terminal 1 16a is configured to compile or generate the authorization request (e.g., an ISO 8583 message, etc.), and include or append event content, ticket content and payment content in or to the authorization request. The event content may include, without limitation, the event I ^' D, the event name, the event location, etc. for the selected event, and the ticket content may include, for example, number of tickets, seats, section, ticket type, etc. purchased. The payment content may include, without limitation, a primary account number or PAN, an expiration data, etc. (broadly, payment credentials) for the consumer's payment account (used in the transaction _. ). Such content included in the authorization request may be the result of inputs from consumer i .12a during the transaction, the programming of the terminal i 16a (by the merchant 102a and/or the acquirer 104), and/or direct inputs from the merchant 102a (e.g., via an employee, an attendant, etc). Further, the consumer 1 12a may provide an input (or be prompted to provide such an input) to opt into an event access linking service, as described herein. The authorization request may further include one or mo re indicators of the authorization request being speci fic to a ticket: pu rchase transition (e.g., as included in transaction data in the message, such as a particular MCC for the event merchant 102a, a particular transaction ID for the ticket being purchased, etc.). The indicators may signal to the access engine 1 1 8, then, to act thereon.

The terminal .1 16a is also configured to transmit the authorization request for the transaction, along path A, to the acquirer 1 4, as described above. n turn, the acquirer 104 transmits the authorization request to the payment network 106, and the payment network 106 and/or the access engine ! IS (through access provided by the payment network 106) is configured to route the authorization request to the issuer 108 (again, as described above).

Then, upon receipt of the authorization request (or upon identify ing that the authorization request involves event access (e.g. , includes an event indicator, etc.)), the access engine 1 18 is configured to determine whether the event identified in the authorization request and/or the merchant 1 2a are registered with the access engine 1 18 {&-.g-, in the relational data structure in the above example, etc.). If each is registered (and the transaction is approved by the issuer 108), the access engine 118 is configured to generate a link, between the payment account funding the transactions

(or another payment account as specified by the consumer 1 12a, for example) and the event. The access engine 18 is further configured to append and/or store the link in the access data structure 120 associated with the access engine 1 18 (e.g., in memory 204 included in the access engine 1 1 8, etc.). Optionally, the access engine 1 18 is configured to notify the merchant 102a and/or the consumer 1 12a of the link betvveen the payment account and the event. In connection therewith, contact information for the merchant 102a may be obtained during registration of the merchant 102a to the access engine 1 8 (as described above). And, contact information for the consumer 1 12a may he obtained, by the access engine 1 1 8, based on transaction data generated in connection with purchase of the underlying ticket for the event (where the consumer .1 12a may provide such contact information as part of purchasing the ticket). Alternatively, if the consumer 1 1 2a uses his/her virtual wallet in purchasing the ticket for the event, application notifications may be used to confirm the link between the consumer's payment account and the event, via the wallet.

In addition .in this example, once the transaction for the ticket is approved, and the link .is generated and stored (at the access data structure 120), the payment network 106 and/or the access engine 1 18 is further configured to generate an authorization reply, to be transmitted back to the merchant i02a in response to the authorization request. The authorization reply (e.g., an ISO 8583 message, a 0120 ISO-standard message, another ISO message, etc.) ma be generated, in whole or in part, based on a reply received from the issuer 108, For example, the authorization reply may include the reply from the issuer I OS (indicating approval of the

transaction) with a confirmation number appended thereto.

While the payment network 106 and the access engine 1 18 are described as configured to operate as described above, it should be appreciated that the payment network 105 may be configured to accomplish certain operations herein, while the access engine 1 18 is configured to then accomplish certain other operations. In such embodiments, the payment network 106 and the access engine 1 1 are configured to interact and/or communicate via one or more application programming interface* (APIs), for example, as shown in FIG. 1 , thereby permitting registrations and registration data, event data, event links, authorization requests, authorization replies, etc, to pass therebetween.

it should be appreciated that the payment network 106 and/or the access engine i 18 are configured to perform substantially consistent as described abo ve, for the example transaction between the event merchant 102b and the consumer 1 12b in generating and transmitting the corresponding authorization request (containing event content for the airline flight from St. Louts, Missouri. Lambert Airport, to New York, JFK Airport, and ticket co le l identifying flight #12345). in so doing, a payment account for the consumer 1 12b can then be linked to the event for which the ticket was purchased from the merchant 102b (with the link stored in the access data structure 120). Specifically, while the process and/or content of the authorization request and/or authorization reply may be altered, based on the

particular type of merchant 102b, the operations are substantially consistent

In the illustrated embodiment, the above-described links between the consumers ^* payment accounts and the events are generated based on the authorization messages involving the payment network 1 6, However, it shotski be appreciated that such links ma be generated outside of the payment network 106 in other

embodiments. Specifically, for example, when the example transaction between the event merchant 1 2a and the consumer 112a occurs at the terminal 1 16a, the terminal 1 16a. may c mmunicate directly with the access engine i 18, through one or more APIs and/or the network 1 10 {and not. through the payment network 106), to provide certain content related to the event, the tickets and/or the payment account, in these embodiments, the event merchants 102a-b and/or the consumers 1 12a-b may opt-in for enrollment with the access engine 1 18 (e.g., via the merchant portal as described above, via a similar consumer portal, etc.), to generate the link between the tickets purchased by the consumers .1 12a-b and the consumers ^* payment accounts.

Additionally, or alternatively, the access engine 1 18 may be associated with a network-based application, whereby the consumers i 12a-b may register the purchased tickets to the consumers' selected payment accounts, with the access engine 1 18, to enable the subsequent access interactions for the events corresponding to the tickets, as described below (e.g., via a consumer porta!, etc).

Also in the illustrated embodiment, the access engine 1 1 8 may include one or more APIs, which may be called by the event merchants 102a-b (e.g. _* b the terminals 116a-b when used to perform the purchase transactions for the various tickets, etc.) and/or the issuer 108, etc., in order to facilitate the operations described herein (I.e., apart from the path A of FIG. I), A call to one of the APIs in the system 0 is indicated by the dotted lines in FIG. .1. It should he appreciated that, the access engine I 18 may include other APIs in other embodiments, which may be called b the same and/or other parts of the system .100 (e.g., a network-based application active in communication devices associated with the consumers 1 12a-b, etc.) to access, create, edit, add, or delete, one or more payment account links, or otherwise manage the consumers ' aecoun Is,

Further in the illustrated embodiment, the access engine Π 8 is configured to facilitate access to the events, for which the tickets are purchased b the consumers ί I2a«b from the event merchants it)2a-b, without the consumers J. J 2 -b needing to present the physical tickets for the events. The following describe operation of the access engine 1 18 to facilitate access to the event (e.g., the concert at Madison Square Garden) associated with the ticket purchased by the consumer 1 I 2a from the merchant i 02a. However, it should be appreciated that the access engine 1 18 is configured to perform substantially the same in connection with facilitating access to the event (e.g., the flight from St, Louis, Missouri, Lambert Airport, to ew York, JFK Airport) associated with, the ticket purchased by the consumer I 12b from the merchant i 02b.

fn particular, when the consumer 1 12a. desires to access the event at the event site ! 1 a, the consumer ! 12a presents payment credentials (e.g. in the form of a payment device, etc.) to the event merchant 102a, via the terminal t J.6a, to gain access to the event (potentially without present actual physical tickets, etc.). In response, the terminal 1 1 a is configured to generate an authorization request for the event that is transmitted through the payment network. 06. along pat A. in turn, the payment network 106 and/or the access engine 1 1 8 is configured to intercept the authorization message (e.g. , directly, via an API between the payment network 106 and the access engine 1 1 , etc.), sent, from the event merchant 1.02a, as being an access request. For example, the payme t network 106 and/or access engine 1 1 may detect a reserved MCC, which is reserved for access requests. Like above, the authorization request includes payment, account content, and may further include event content (e.g., an event ID, etc.). in general, the authorization request will not be forwarded along path A to the issuer 108. Once intercepted, ihe access engine 1 1 S is configured to search, in the access data structure 120, for a Sink between the payment account indicated to authorization request and the event

in this example access request, if a link is found in the access data structure 120, the access engine 1 18 is configured to return an authorization reply to the event merchant 1 2a. The authorization reply includes at least an access output and, often, additional ticket content related to the tickets purchased by the consumer 1 12a (e.g., a number of tickets purchased when appropriate; ticket details such as seat/section numbers, etc; and other potentially useful information, etc). The reply, for example, may include the consumer's payment account number as data element (DE) 2, the number of tickets purchased by the consumer (and, thus, the number of accesses allowed to the event) as DE 6, an MCC for the event as DE 18, and the event ID for the particular event as DE 42. Additional details, such as seat/section number(s), etc, may be included in the reply in the same or additional data elements. The detail may be displayed to the merchant 1 2a and/or the consumer 1 12a, at the terminal 1 16a, which may display the ticket details and/or provide a physical print out including the ticket details (e.g., to assist the consumer 1 12a in finding his/her seat, etc). In addition, in some embodiments, event/access details may be provided to the consumer 112a in the form of information displayed on a screen and/or printed on paper or similar .media, and/or provided to a communication device associated therewith.

Alternatively, if no link is found between the consumer's payment account (as presented at the event site 1 i 4a) and the event, the access engine i 1 S is configured to return an authorization message to the event merchant 102a, indicating a denial output for the consumer 1 12a to access the event.

FIG. 3 illustrates an exemplary method 300 of linking a payment account to an event, for use in providing subsequent access to the event based on credentials for the payment account. The exemplary method 300 is described herein in connection with the event merchant 102b of the system. 100 (a lthough the description, is equally applicable to the event merchant 1 2a), and may be

implemented in the access engine 1.18, Further, for purposes of illustration, the exemplary method 300 is also described with reference to computing device 200. However, it should be appreciated that the method 300, or other methods described herein, are not limited to the system 1 0, or computing device 200, And, conversely,

56 the systems and computing devices described herein are not limited to the exemplary method 300,

Initially in the method 300, the consumer i 12b selects, at 302, a ticket for purchase from the event merchant 102b for a flight event. As described above, the flight event, may include an airline flight, which is flight #12345, between two locations (e.g.. New York, NY and Si, Louis, MO, etc.). in so doing, the consumer 1 12b provides various preferences regarding the ticket, such as origin, destination, flight date/time, flight number, desired seat number, ticket type, etc. In addition, the consumer 1 12b provides payment credentials, for the consumer's payment account, to the event merchant 102 b, to effect purchase of the ticket ( g., via a payment device, etc.). This may be done via the terminal 1 16b associated with the event, merchant 102b, but may also be accomplished remote from the event merchant 102b, via a virtual storefront, for example.

As part of the interaction with the terminal 1 1 Ob (or virtual storefront, etc.), the consumer i 1 2b is prompted to opt into linked access entry, with the access engine I I S, whereb the consumer's payment account is linked to the ticket and/or event, and the payment device may then be used to subsequently access the event and/or event site 1 14b (see method 400). In response, the consumer 1 12b opts into the linked access entry, at 304. As part of this operation (and if the consumer 112b has not already done so via a general registration with: the access engine 1 18), the consumer 1 12b may also provide contact information (ag., e-mail address, phone number etc.) for use in receiving subsequent notifications, from the access engine 1 18, regarding the link, the event, etc. Alternatively, if such linked access entry is not available for the particular ticket and/or event, such an option will not be available or presented to the consumer 1 i 2b. Thereafter, the consumer 1 12b submits the transaction for the ticket to the merchant 102b, at 306.

Next in the method 300, the event merchant 102b compiles, at 308, an authorization request for the transaction, in this exemplary embodiment, the termina! 1 161? includes various detail regarding the event (broadly, event content) and the ticket being purchased (broadly, ticket content). Specifically, in this example, the termina! 1 16b is aware of the flight number, the origination city (or airport, name), the destination city (or airport name), flight time date, and further that two tickets are being purchase and seats 12a and 12b, in coach class, are associated with those tickets. As such, the terminal 1 1 compiles the authorization request, which is consistent with, the ISO 8583 standard, with flight #12345, STL, JFK, 09:00,

M.DD.YYYY (event content), and 2, coach, class, 12a, 12b (ticket content) all included in various data elements of the request (e.g., without limitation, in. DE 125; etc.). It should he appreciated that the particular event and ticket content will be different depending on the type of event. For example, the ticket con ten t for a sporting event may include number of tickets, section, row and seat number (for each ticket), etc., while the event content may include the time/date, stadium name, home team, visiting team, etc.

In addition to the event and ticket content, the terminal 1 16 further compiles payment account content into the authorization request (at 308). Pay ment account content includes, as is conventional, the primary account number (PAN) for the pay men ( account, security codes, expiration, date, purchase amount, merchant ID, etc. in addition, the payment account content may include a merchant category code or MCC for the event merchant 102b, and/or a differen MCC. Specifically, for example, the MCC included in. the payment account content may be a reserved MCC, which is not indicative of a category of merchant, but instead is indicative of an access related transaction. Use of the MCC is described further with reference to the payment network 106 and the access engine 1 18.

Once the authorization request is compiled, the terminal 1 16b (or merchant 102b) submits, at. 3 10, the authorization request, along path: A in FIG. 1 , to the acquirer 104 and then to the payment network 106.

In response, the payment network 106 routes the authorization request, at 3.12, to the issuer 108, to determine whether the transaction is approved or declined. As conventional, the issuer 108 may emplo a variety criteri and/or metrics to determine, for example, if the consumer's payment account is in good standing, if sufficient funds are available in the consumer's payment account for the purchase, if the transaction appeal's fraudulent or not, etc. Once the issuer 108 responds (with an authorization reply), the payment network 1 6 determines, based on the authorization reply, whether the transactio is approved or declined, at 314. i f the transaction is declined, the payment network 106 transmits the authorization reply to the event merchant 102b (generally as received from the issuer 1 8), at 31 , declining the transaction, thereby permitting the event merchant 1.02b to halt or terminate the transaction. However, if the transaction is approved, the payment network 106 determines, at 318, whether the event, associated with the ticket purchased by the consumer 112b, and/or the merchant .102b are registered with the access engine ] 18. Specifically, when merchants, including the merchants 102a~b, register with the access engine 118 (or the payment network 106} and/or register events with the access engine 1 18 (or the payment network 106), as described above, a l isting of the registered merchants and/or events is maintained, by the access engine 1 18 (eg., m the relational data structure associated with the access data structure 120, etc.). The registered merchants may be entitled to one or more additional services by the payment network 106, or ma be subject to additional fees and/or other charges for use of the access engine 1 ! 8, which, in mm, provides linked access to their consumers, including consumers 1 12a-b. As such, in the method 300, when the transaction is determined to be approved (at 314), the payment network 106 determines if the merchant 102b and die flight # 1.2345 event are included in the listing of .registered merchants and events {e.g., via communication with the access engine 1 1 such as an API call to the access engine 1 18, to the relational data structure associated with the access engine i 18, etc). If one or the other is not registered, the payment network 106 transmits the authorization .reply to the event merchant 102b (generally as received from the issuer 1 8), at 3 16, approving the transaction, thereby still permitting the event merchant 102b to proceed with the transaction.

Conversely, if the merchant 102b and the flight #12345 event are registered (at 18), as in this example, the payment .network ^' 106 generates and transmits an authorization reply, at 320, The authorization, reply generally includes at least part of the authorization reply received from the issuer 108, but further includes a confirmation number indicating the payment account is linked to the event. In one example, in generating the authorization reply, the payment network .106 merely appends the confirmation number to the authorization reply received from the issuer 108 and iurther transmits the authorization reply, at 320, in another example, the payment network 106 generates an authorization reply based on only a portion of the authorization reply from the issuer 108 and includes the confirmation number, prior to transmitting it, at 320, whereby at least a portion of the authorization reply from the issuer 108 is excluded from the transmitted authorization reply.

Further, as shown in FIG. 3, the authorization reply, generated at 320, is provided to the access engine 1 .18. in response, the access engine 1 .18 forms and stores a link between the a ment account: and the event, at 322, This link may be based on information included in the authorization request and/or the authorization reply, and/or based on. information in die access data structure 120. In particular, the link may include at ieasi the payment account and an event ID for the event, and may further include other details from the e vent content, the ticket content, or the payment account content included in the authorization request (and potentially in the authorization reply), and/or may also include the confirmation number. In one example, when the authorization request is submitted, or upon receiving the authorization reply, the access engine 118 may retrieve the paymen account content and confirmation number from the authorization reply, and retrieve any necessary information for ihe event (e.g., eveni content and ticket content, etc.) from, the acces data structure 120 (e.g., directly, via an API call, etc.). As such, the link is generally created (at least preliminarily) by the access engine 118 (at 322) when the ticket is purchased by the consumer 1 12b from the event merchant 102b. The link may then later, optionally (as indicated b the dotted lines in FIG. 3), be finalized by the access engine Ϊ 18, at 324, upon clearing and settling of the transaction (with

additional/complete clearing information/details for the transaction and/or complete information/details for the event further appended to the link), in this manner, by requiring the link to be finalized, if the underlying transaction for the ticket does not clear, access would not be available granted (even though the link is already created).

As further shown in FIG. 3, the access engine 1 18 then notifies, at 326, the merchant 102b and/or the consumer 112b that the link has been farmed and stored, and is available to be util ized as a manner of access the event. The notification may be provided via e-mail, short message service (SMS) message, etc. The contact information for ihe merchant 102b and/or ihe consumer 112b ma be retrieved from the registration of the merchant 102b and/or the consumer 1 12a-b, as described above.

In response, the merchant 102b records, at 328, the confirmation number associated with the consumer 1 12b, the event and the payment account, in this manner, the merchant 102b is able to maintain a record of the tickets sold for the event or event(s), potentially altering the tickets available for sale by the merchant 102b accordingly (e.g., marking tickets for seats as sold, or reducing a number of available tickets, etc.).

It should again be appreciated that the method 300 may include additional operations, or fewer operations, in other embodiments. In particular, it should be appreciated that the operations attributed to the payment network 106 and the access engine 1 18 may be accomplished by the payment network 106 alone, the access engine 118 alone, or some different combination of the two. Additionally, in at least one embodiment, the access engine 1 18 is incorporated into the payment network ! 06, whereb each operation may be attributed to the payment network 106, etc.

FIG. 4 illustrates an exemplary method 400 of facilitating access to a registered event, tor a consumer, through use of a payment account linked to such access to the event (e.g., via a ticket, etc). The exemplary method 400 is described herein in connection with the event merchant 102b of the system 100 (although the description is equally applicable to the event merchant 102a as well), and may be implemented in the access engine 1 I S of the system 100. Further, for purposes of illustration,, the exemplary method 400 is also described with reference to computing device 200, However, it should be appreciated that the method 400, or other methods described herein, are not limited to the system 1 0, or computing device 200. And, conversely, the systems and computing devices described herein are not limited to the exemplary method 400.

As described in connection with the system 1 0, when the purchase of the ticket (or multiple tickets) for the registered event (e.g., the flight from St. Louis, Missouri. Lambert Airport, to New York, JFK Airport) at the event site 1 14b is completed by the consumer 1 12b, the access engine 1 18 is configured to generate a link (or association) between the purchased ticket (broadly, the access to the event) and the payment account associated with the consumer 1 12b. The payment account may be the payment account used by the consumer ! 12b to purchase the ticket, or it may include another payment account, associated with the consumer 1 12b and specificall selected by the consumer 1 12b for association with the ticket: (e.g., during general registration of the consumer 1 12b for linked access entry, when opting into linked access entry for a particular transaction, etc.). The link between the ticket purchased by the consumer 1 1 2b and the consumer's payment account is then stored in the access data structure 120 associated with the access engine 1 18. With that said, and as described above, in various embodiments, the consumer 1 12b may voluntarily register with the access engine 1 .18 for such linking, or the consumer 112b may be provided an option to link a payment account with the ticket during purchase, or the linking option may be provided to the consumer 1 12b as an optional service by one or more of the payment network 106, the issuer 108, etc.

it should be appreciated that the ticket may be purchased by the consumer 1 12b from the event merchant 102b, as described in connection with the system 100, or from another merchant selling tickets to the same event (e.g.,. on behalf of the event merchant 102b, separate from the event merchant 102b, etc,}, in either case, the access engine i 18 is configured to identify the purchase (e.g., based on transaction data generated in response to the purchase, etc.) and link the ticket to the desired payment account associated with the consumer 1 ί 2b. Or, the consumer 1 12b may voluntaril link the purchased ticket to the payment account, independent of the actual purchase, in addition, the consumer 1 1 b may purchase multiple tickets to the event (e.g., for his/her family, etc.), and the access engine 1 18 may then link the multiple tickets to the consumer's selected payment account. Further, the consumer 1 1 b may purchase tickets to multiple different events, and the access engine 1 18 ma link the different tickets to the consumer's selected payment account.

In any case (and regardless of how or when the consumer's ticket is linked to the consumer's selected payment account), when the consumer 1 12b desires to access the registered event for which the ticket was purchased (e.g., at an airport associated with the event site J 14b), the consumer 1 12b presents information to the event merchant. 102b, at the event site 1 14b for the event, regarding the consumer's payment account linked to the purchased ticket (e.g., an account number, etc.). in response, the event merchant 102b generates an access request for the event (e.g., an ISO 8583 message, another ISO message, another message, etc), and transmits the access request along path A in the system 100. The access request includes payment account data for the consumer's payment account as well as event data for the event to which access is being requested (e.g., based on configuration of the terminal ί 16b, based on inputs to the terminal 1 16b by the consumer ί 12b or other user, etc). In addition, the access request includes an event identifier that distinguishes the access request from other transaction messages transmitted along pat A (e.g., an event ID, etc.). As such, in the method 400, when the event identifier is recognized (e.g., by the payment network 106. etc.), the access request is routed to the access engine 118, in turn, and as shown in FIG, 4, the access engine 1 18 receives the access request from, the event merchant 102b, at 402. As an example, the event merchant 102b may receive payment account information from the consumer 1 12b via the terminal i 16b at the event (e.g., from a payment device presented by the consumer 1 12b to the terminal 116b, where the terminal 1 1 b is a POS terminal; etc.). In response, the terminal 11 b may generate an access request that includes an ISO 8583 authorization, request message, and transmit the message along path A hi the system 100. The authorization request message includes details regarding the event (e.g. , a name of the event, a location of the event, a dale of the event, etc.) and the consumer's payment account (e.g. , a payment account number, etc.), a well as a particular MCC identifying the transaction as an access request transaction, in this example, as the message proceeds along path A in system. KM), the payment network 106 identities the particular MCC in the message and routes the message to an API associated wit the access engine 1 18.

With continued reference to FIG. 4, upo receiving the access request from the event merchant 102b, the access engine 1 1 8 searches, at 404, for a

corresponding payment account link in the access data structure 120. For example, the access engine 1 18 may initially extract the consumer's payment account number and the pertinent event data for the event: from the access request. The access engine 1 18 may then search (e.g., via ke word searching, etc.) in the access data structure 1 0 for the consumer's payment account number to determine if the pay ment account is linked with the particular event to which access is requested. Alternatively, the access engine S 18 may search in the access data structure S 20 for the particular event, and then determine if the consumer's pay ment account number is associated with the particular event in order to determine if the payment account is linked with the event, In either ease, the access engine 1 18 may also determine, as part of the search, how many tickets are available to the consumer 11.2b for use, and if any o the tickets have already been used/claimed.

When a matching link is identified in the access data structure 120, at 406, the access engine 1 1 S transmits an access output to the event merchant 102b, at 408 (e.g., an ISO 8583 message, another ISO message, another message, etc.). The access output: indicates that the consumer's payment, account is linked to the ticket for the particular event (e.g., that the consumer 112b has in fact purchased the ticket for the event, etc.), such that the event merchant 102b can allow the consumer i 12b to access the event. In addition, the access engine 1 I S may optionally (as indicated by the broken lines n FIG, 4) include in/with (he access output, at 410, details of the ticket purchase (e.g., as determined by the access engine 1 18 during (he search at 404, etc.). for example, the access engine 1 18 may include, with the access output, an indication (or indicator) of access to the particular event, as well as seat/section numbers, a total number of tickets purchased, and a total number of tickets used, etc.

In connection with the above example, the access output may include an ISO 8583 authorisation reply message. Here, when the access engine 1 18 determines that the consumer's payment account is linked to (he particular registered event to which access is requested, the access engine 1 Ί 8 generates the reply message and transmits the message to the terminal 1 16b back along path A in the system 100. hi particular, the access engine 1 18 transmits die repl message to the payment network i 06, which in turn transmits the reply message to the terminal .1 i 6b via the acquirer 104, In this example, and as shown in the system 100, (he reply message includes (without limitation) the consumer's payment account number as DE 2, the number f tickets purchased b the consumer 1 12b (and, thus, the number of accesses allowed to the event) as DE 6, the MCC tor the particular event as DE 18, and the event ID for the particular event as DE 42. The reply message thus represents a zero transaction through the payment network 106. In some embodiments, the authorization reply message may include one or more extended data elements (or entries), which may contain additional event and/or access information. For instance, the extended data element may include seat numbers, etc. Then, the terminal 1 16b may print the extended data elements, such as the seat numbers, etc., for the purpose of granting entry and/or providing the consumer 1 12b with additional access and/or event information,

Alternatively in the method 400, when a matching link is not identified by the access engine 1 18 (at 406), the access engine I I S transmits a denial output to the event merchant 102b, at 412. The denial output indicate that the consumer's payment account is not linked to the ticket for the particular event, such that the event merchant i 02b may not allow the consumer 1 i 2b to access the event. In connection with the above example, and as described for the access output, the denial output may include an ISO 8583 authorization reply message generated by the access engine 1 18 and transmitted to the terminal 1 16b in similar fashion to the access output.

FIG. 5 illustrates an exemplary access interlace 500 that may be displayed at a terminal and/or at a portable computing device associated with one or more of a consumer and an event merchant (as defined by instructions therein) in connection with either the access output or the denial output for an event access request (e.g., as described in. the method 400, etc). The interface 500 includes an indication 502 of a particular event (i.e., ABC Concert) to which the consumer is requesting access, as well as an identification 504 of the consumer (i.e., John Smith) and the consumer's linked payment account number. The interface 500 also includes buttons 506, 508 that are configured to be highlighted to indicate that access is either granted to the particular event or denied, respectively.

In the illustrated embodiment, the interface 500 i displayed in connection with access being granted to the even ABC Concert. As such, the button 506 indicating that access is granted to the event is highlighted, in addition, the interface 500 identifies, at the button 506, particular details regarding the event, including the total number of tickets available to John Smith for the event and the section/seat numbers for each of the tickets.

With that said, other interfaces and/or acces inputs or outputs may he used in connection with the system 100 of f 10. 1 and/or the methods 300, 400 of FIGS. 3 and 4. In other embodiments, for example, access interfaces may include additional and/or different fields and/or formats providing additional and/or different data to event merchants and/or consumers for revie /consideration when deciding access to a particular event.

ft should be appreciated that, the functions described herein, in some embodiments, may be described in computer executable instructions stored on a computer readable media, and executable by one or more processors. The c mputer readab ie media is a non-transitory computer readable media. By way of example, and not limitation, such computer readable media can include RAM, ROM, EEPRO. , CD-ROM. or other optical disk storage, magnetic disk storage or other magnetic storage device, or any other medium that can be used to carry or store desired program, code in the form of instructions or data structures and that can be accessed by a computer. Combinations of the above should also be included within the scope of computer-readable media.

It should also be appreciated that one or more aspects of the present disclosure transform, a general-purpose computing device into a special-purpose computing device when configured to perform the functions, methods, and/or processes described herein, As will be appreciated based on the foregoing specification, the above- described embodiments of the disclosure ma be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof, wherein the technical effect may be achieved by performing at least one of the following operations; (a) receiving an authorization request for purchasing access to an event, the authorization request including event content, ticket content, and payment content, the authorization request: associated with a merchant; (b) determining whether the merchant is registered; (c) determining whether ihe event, is registered; (d) when the merchant and the event are registered, storing, in memory, a link between a payment account identified in the payment content and the event, whereb the link is able to be retrieved, by the merchant, via a subsequent authorization request, to indicate access to the event; (e) generating an authorisation reply and transmitting the authorization ^" reply to the merchant; (f) finalizing the link ^" in the memor upon clearing and/or settling of the purchase of the access; and (g) notifying at least one of the consumer and the

merchant of the link between the payment account and the event.

Example embodiments are provided so that this disclosure will be thorough, and will fully convey the scope to those who are skilled in the art.

Numerous specific details are set forth such as examples of specific components, de vices, and methods, to provide a. thorough understandi ng of embodiments of the present disclosure. It will be apparent to those skilled in the art that specific details need not be employed, that example embodiments may be embodied in many different forms and that neither should be construed to limit the scope of the

disclosure. In some example embodiments, well-known processes, well-known device structures, and well-known technologies are not described in detail, in addition, advantages and improvements that may be achieved with one or more exemplary embodiments disclosed herein may provide all or none of the above mentioned advantages and improvements and still, fall within the scope of the present disclosure.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used herein, the singular forms "a," "an,-" and "the" may be intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms "comprises,"

"comprising," "including, ⁴⁵ and "having," are inclusive and therefore specify the presence of staled features. Integers, steps, operations, elements, and/or components, but do uot preclude the presence or addition of oue or more other features, integers, steps, operations, elements, components, and/or groups thereof. The method steps, processes, and operations described herein are not to he construed as necessarily requiring their -performance in the particular order discussed or illustrated, unless specifically identified as an order of performance. It is aiso to be understood i ai additional or alternative steps may be employed.

When a feature is referred to as being "on," "engaged to," "connected to," "coupled to," "associated with," "in communicalion with," or "included with" another element, or layer, it. may be direct iy on., engaged, connected or coupled to, or associated or in communication or included with the other feature, or intervening features may be present. As used herein, the terra "and/or" includes any and all. combinations of one or more of the associated listed items.

Although the terms first, second, third, etc, may be used herein to describe various features, these features should not be limited by these terms. These terms may be only used to distinguish one feature from another. Terms such as "first," "second," and other numerical terms when used herein do not imply a sequence or order unless clearly indicated by the context. Thus, a first feature discussed herein could be termed a second feature without departing from the teachings of the example embodiments.

None of the elements recited in the claims are intended to be a means- plus-function element within the meaning of 35 U.S.C. §1 12(f) unless an element is expressly recited using the phrase "means for," or in the case of a method claim using the phrases "operation for" or "step for."

The foregoing description of the embodiments has been, provided for purposes of illustration, and description, it is not intended to be exhaustive or to limit the disclosure, individual elements or features of a particular embodiment are generally not limited to that particular embodiment, but, where applicable, are interchangeable and can. be used in a selected embodiment, even if not specifically shown or described. The same may also be varied in many ways. Such variations are not to be regarded as a departure from the disclosure, and all such modifications are intended to be included within the scope of the disclosure.