Systems and methods for peer-to-peer single-use access tokens

Abstract

A system for enhancing biometric analysis matching captures a facial image of a person using an image sensor, such as a digital camera. The system may perform image enhancements, such as edge enhancement and contrast enhancement, before performing facial matching. This enhancement may be limited to a predetermined image region based on the illumination of the identified region. The system performs image processing and analysis, including face detection, alignment, feature extraction, and recognition. Results of the image enhancement and analysis may be used to generate a biometric recognition confidence indication. In response, at least in part, to the biometric recognition confidence indication being below a threshold, the system enhances the recognition confidence using an image of the visual indication captured using the image sensor.

Description

[Technical Field]

[0001] All applications for which a foreign or domestic priority claim is identified in the Application Data Sheet filed with this application are hereby incorporated by reference pursuant to 37 CFR 1.57.

[0002]

[0002] The present disclosure relates generally to access tokens, and more particularly to peer-to-peer access token provisioning. [Background technology]

[0003]

[0003] User devices, such as smartphones, are increasingly being used as access tokens to provide physical access to physical locations. However, using a user device as an access device typically requires that an application be downloaded to the smartphone and that the user log in to a pre-configured account. A drawback is that if cellular or Wi-Fi service is unavailable or already overutilized, the application may not be able to download or may take an excessive amount of time to download. This situation may result in the user not being able to gain access to the physical location or having to wait an excessive amount of time to gain access. [Brief explanation of the drawings]

[0004] Aspects of the present specification are described with reference to the drawings summarized below. These drawings and the associated description are intended to illustrate exemplary aspects of the disclosure and are not intended to limit the scope of the invention. [Figure 1A]

[0005] FIG. 1A illustrates an example of a network environment architecture. [Figure 1B]

[0006] FIG. 1B shows an example of a system architecture. [Figure 2]

[0007] FIG. 2 shows an example of the entrance area configuration of the venue. [Figure 3]

[0008] Figure 3 shows an example of the process. [Figure 4A]

[0009] FIG. 4A shows another example of the process. [Figure 4B] FIG. 4B shows another example of the process. [Figure 5]

[0010] FIG. 5 shows an example of a single-use optical token. DETAILED DESCRIPTION OF THE INVENTION

[0005]

[0011] One aspect of the present disclosure relates to systems and methods configured to provide single-use, time-limited tokens that can be configured to enable access to a physical location. Such tokens can be utilized to avoid the need to download dedicated applications (e.g., what are called credential applications) for accessing the physical location. This is particularly advantageous in locations where wireless networks are overloaded, making application downloads very slow. Certain aspects of the present disclosure relate to providing cryptographic security (e.g., through encryption and / or hashing) via corresponding cryptographic processes.

[0006]

[0012] To better understand the advantages of certain aspects of the disclosed technology, an exemplary process for utilizing a downloaded application (a credential application) to access a physical location, such as an event venue hosting a ticketed event, is described below.

[0007]

[0013] An electronic device can be utilized to identify a user using a downloaded application (e.g., an application called a credential app, provided via an application store or by a ticket service selling event tickets). For example, using the downloaded application, a user's mobile device (e.g., a mobile phone) can present one or more unique identifiers (e.g., a unique user device identifier (e.g., mobile ID) and / or a unique user identifier and / or a hash value thereof) to an access control device (e.g., a barcode reader / scanner) within the venue.

[0008]

[0014] These identifiers may be assigned by the authentication system or by the device manufacturer / provider (e.g., mobile phone or SIM card provider) (e.g., IMEI (International Mobile Equipment Identity), MEID (Mobile Equipment Identifier), ESN (Electronic Serial Number), IMSI (International Mobile Subscriber Identifier), etc.). Thus, the device identifier may be different from the phone number associated with the mobile phone. Such user and / or device identifiers may be presented by the mobile device to the access control device via optical indicia (e.g., one- or two-dimensional barcodes and / or characters such as QR codes displayed by an authentication app on the mobile device display), a downloaded application using wireless electromagnetic transmission, or via audio signals.

[0009]

[0015] Such identifiers may optionally be encrypted before transmission and / or presentation by a downloaded credential application hosted on the mobile device. The identifiers may be encoded with a timestamp, as also described elsewhere herein. If the identifier and timestamp are presented via an optical code, the optical code is periodically regenerated to include an updated timestamp (e.g., every 5, 10, 15, 20, or 30 seconds, or within a range of 5 seconds to 5 or 10 minutes). This may prevent screenshots of the optical indicia from being taken and shared for later use because the timestamp would be too old. Examples of using electronic user devices to verify a user's access to a ticketed event at a venue are described elsewhere herein.

[0010]

[0016] Optionally, the optical codes described herein (e.g., one-dimensional or two-dimensional barcodes such as QR codes) may be configured to allow for detection and correction of reading / scanning errors. For example, such errors may be caused by dirt, scratches, or a user's finger obscuring the optical code (e.g., as displayed on a user's mobile device). Error correction may optionally be implemented by adding a Bose-Chaudhuri-Hocquenghem code, such as a Reed-Solomon code, or other error-correcting code to the original data encoded in the optical code. The number of code words of the added Reed-Solomon code may correspond to the number of code words that need to be corrected (e.g., the number of code words of the added Reed-Solomon code may be twice the number of code words that need to be corrected).

[0011]

[0017] In certain configurations, a user may be required to download an application (authentication app) to the user device (e.g., via an app store), log in to a user account through the application, and configure the application with one or more identifiers (e.g., a mobile ID described elsewhere herein, a user-specific unique member ID (e.g., a 32-, 64-, 96-, 129-, or 256-digit alphanumeric identifier), and / or other identifiers). For example, the user may be required to log in to the application, which may then need to connect to a remote server, which may then need to configure the application with one or more of the disclosed device and / or user identifiers. (Alternatively, the application may be self-configurable and access a unique identifier directly from the mobile device and / or receive a user identifier, which may or may not be unique, from the user.) Such a configuration process may be network-intensive and time-consuming, especially if the wireless network is overloaded and network transactions (e.g., application downloads) are slow.

[0012]

[0018] Once downloaded and configured, the authentication app is utilized at a venue to identify the user and verify that the user has access (e.g., a ticket) to a ticketed event at the venue. For example, when attempting to enter a ticketed event at a venue, the user can open the authentication app on their mobile device. The authentication app then generates a token, such as an optical code, that encodes one or more identifiers and a timestamp. Optionally, the unique member ID, unique device identifier, and / or timestamp may be encoded into the token (e.g., a barcode and / or string of characters, such as a QR code), after being protected with encryption and / or hashing or other cryptographic techniques. The token is displayed on the user device's display. The displayed token is then read / scanned by a token reader (e.g., a barcode reader) located at a physical location (e.g., an entrance) within the venue.

[0013]

[0019] As also described elsewhere herein, the token can be periodically regenerated by an authentication app hosted on the user's mobile device to include a new timestamp reflecting the current time. Thus, the mobile device, via an application, locally generates and displays an optical code (e.g., a barcode) unique to the mobile device user. The token (e.g., barcode) may optionally be based on data related to (or partially related to) a venue or event, such as a location name, address, event title, performance name, or event session / show information. In this manner, the token (e.g., barcode) is independent of venue or event data (i.e., does not include venue- or event-identifying data), and the user is not required to store an electronic ticket for the event on their mobile device (although, optionally, an electronic ticket for the event may be stored on the user's mobile device). In this manner, the token (e.g., barcode) can be self-generated by a downloaded authentication information application hosted on the user's device, rather than being generated by a remote system.

[0014]

[0020] More specifically, a user may obtain access to an event at a physical venue. For example, a user may purchase an event ticket through a ticket sales website (e.g., via an authentication system described elsewhere herein) hosted on one or more servers. The server records the ticket purchase in a user account record in a database. The user account record may store one or more device identifiers and / or unique user identifiers (e.g., membership IDs) associated with the user device. Optionally, hash values ​​of the identifiers may be stored in the user record, or hash values ​​may be generated as needed during the authentication / verification process. Illustratively, a hashing process may be performed to map the user and device identifiers to fixed-length hash values. Advantageously, it is extremely difficult to reverse-calculate the user and device identifiers from the hash values. The hashing processes described herein may optionally utilize MD5 (which converts information into a 128-bit fingerprint), SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512, SHA-512 / 224, SHA-512 / 256 hash functions with digest (hash value) lengths of 224, 256, 384, or 512 bits), CRC32 (cyclic redundancy check error detecting code), and / or other hash functions.

[0015]

[0021] A ticket may entitle a user to attend a venue at a specific date and / or time and / or event. A ticket may entitle a user to a specific seat or area within the venue or event. When a user presents a displayed token held on the device to a reader / scanner at the venue, the venue system or a remote authentication system can authenticate the user and verify that the user has access to the venue and / or event for the current time and / or event.

[0016]

[0022] For example, a reader / scanner device at the venue can read / scan and decode the contents of the token to obtain a user ID, a device identifier, and a timestamp (which may optionally be a UTC date / time). The reader / scanner or other system can compare the timestamp to the current time to determine whether the timestamp has expired or meets a threshold date / time range (e.g., the current time plus 15 seconds, 30 seconds, 1 minute, 2 minutes, 3 minutes, 4 minutes, 5 minutes, or other time range). If the date / time has expired, a visual indicator (e.g., device display, LED light, etc.) is issued to indicate authentication failure. This process helps ensure that a user does not simply take a screenshot of the token's optical code and provide it to someone else, thereby allowing the recipient of the screenshot to gain access to a ticketed event.

[0017]

[0023] If the date / time has not expired, the decoded user device identifier and / or user identifier can be used to determine whether a result (e.g., a matching user record) exists in a database that matches the device identifier and / or user identifier. For example, the device identifier and user identifier, or their hash values, can be compared with the device identifiers and user identifiers, or their hash values, in the database. If no match is found, a visual indicator (e.g., a device display, an LED light, etc.) can be issued to indicate that authentication failed.

[0018]

[0024] If a match is found, it can be determined whether venue / event access rights are associated with the user record (e.g., does the user have purchased and still have in possession of a ticket for the event, or has someone properly transferred the ticket to the user). If venue / event access rights are not associated with the user record, a command can be issued to a visual indicator (e.g., device display, LED light, etc.) indicating that authentication failed. If it is determined that venue / event access rights are associated with the user record, a command can be issued to a visual indicator (e.g., device display, LED light, etc.) indicating that authentication / verification was successful, and the user can be granted access to the venue / event.

[0019]

[0025] Optionally, instead of comparing the user identifier and / or device identifier with the user identifier and / or device identifier in the database, a hash value of the user identifier and / or device identifier may be compared with a hash value of the user identifier and / or device identifier in the database. As also described above, if a matching hash value is not found, a command may be issued to a visual indicator (e.g., a device display, an LED light, etc.) indicating that authentication has failed.

[0020]

[0026] If a matching hash value is found in the user record, it is determined whether the user record has been granted access to the venue / event. If access to the venue / event (e.g., a ticket) is not associated with the user record, a command can be issued to a visual indicator (e.g., a device display, an LED light, etc.) indicating authentication failure. If access to the venue / event is associated with the user record, a command can be issued to a visual indicator (e.g., a device display, an LED light, etc.) indicating authentication was successful and access to the venue / event can be granted to the user (e.g., via a computer-controlled barrier or by a human service representative).

[0021]

[0027] However, as mentioned above, traditionally, if a corresponding authentication application is not installed on a user's device (e.g., a smartphone) and the user is not logged in to their account, the token generation, scanning, and authentication process will not begin. A disadvantage is that users arriving at an event may not have the application installed on their device. A further disadvantage is that in many venues, local cellular and Wi-Fi networks can be overloaded with thousands, tens of thousands, or even hundreds of thousands of user devices attempting to access the network. This can result in significant time spent downloading authentication applications, which can be tens to hundreds of megabytes in size, to user devices and logging in to the application. This can delay users' access to the event / venue and can result in unsafe crowding of users while they wait for the application to download. Indeed, such delays can result in users missing portions of a ticketed event.

[0022]

[0028] To overcome the aforementioned technical problems caused by the lack of sufficient cellular or WiFi bandwidth, the following technical solutions can be utilized: A user who has not downloaded an application can approach and utilize a computerized interactive kiosk (e.g., equipped with a touchscreen display, physical keys, a speaker, a microphone, wired and / or wireless network interfaces, etc., optionally mounted on a pedestal or counter and located in a location accessible to event attendees) and / or a human service representative. The user can provide identifying information (e.g., email address and / or phone number) associated with the ticket purchase / acquisition and / or associated with the user account record. For example, the user can provide an email address and / or mobile phone number associated with the ticket purchase / acquisition in a request submitted via the kiosk's user interface or in response to a request from the service representative. A database search can be performed to determine whether the identifying information provided to the kiosk or service representative matches information associated with the user record and / or ticket purchase / acquisition (e.g., for a ticketed event at a venue). For example, a database search can be performed for a user record having the identifying information (e.g., mobile phone number, other electronic address such as a messaging address or email address) provided to the kiosk or service representative.

[0023]

[0029] If a database match is found, a single-use token can be generated (e.g., by a token generation module) and sent to the electronic address (e.g., email address and / or phone number) provided when obtaining the ticket from the ticket service. The token can then be accessed by the user device and displayed on a reader / scanner at the venue (e.g., via a messaging or email application). The token can include an image (e.g., JPEG, PDF, TIFF, BMP, GIF, or other image format) and can include a static optical code (e.g., with a user identifier and mobile device identifier also optically encoded) that mimics one generated by the authentication application described herein. Optionally, however, the optical code need not be periodically regenerated with a new timestamp (as opposed to an application-generated token that is periodically regenerated).

[0024]

[0030] Advantageously, sending the optical code via a messaging service message (e.g., SMS / MMS or other message type) or email utilizes much less network bandwidth than downloading a software application (e.g., a credential application described herein) and can be received by the user device in a very short time (e.g., less than 1 second, 1-5 seconds, 1-10 seconds, 1-30 seconds, etc.). Optionally, the kiosk may print a token that the user presents to a reader / scanner at the venue. This may be advantageous when the user device is unavailable to the user or when the user device does not have access to the electronic address associated with the ticket purchase.

[0025]

[0031] Thus, optionally, if the user record includes a device identifier for the user (e.g., a unique device identifier), the device identifier from the user record may be utilized for the optical code. Optionally, if the user record includes a user identifier (e.g., a unique user identifier), the user identifier may be utilized for the optical code.

[0026]

[0032] Optionally, if the actual user identifier and / or actual device identifier are not available via the user record, the optical code may optionally include a timestamp (either the current time or the current time plus an additional time so that the timestamp expires at a later time) and a unique identifier different from the actual mobile identifier (sometimes referred to as a simulated mobile device identifier), which corresponds to the format (e.g., length, use of allowed characters) of a unique mobile device identifier, but optionally may not be that of an actual mobile device (or may correspond to the unique identifier of an unused device). Similarly, the optical code may optionally include a unique identifier different from the actual user identifier (sometimes referred to as a simulated user identifier), which corresponds to the format (e.g., length, use of allowed characters) of a unique user identifier, but optionally may not be that of an actual user (or may be that of a user who no longer has an account in the authentication / ticketing system).

[0027]

[0033] Optionally, if the optical code does not contain the user's actual user identifier and / or mobile device identifier (and therefore may not be usable to access the actual user record stored in a database), the authentication system and / or venue system may record a "dummy" record. This dummy record indicates that the holder of the single-use token is entitled to admission to the ticketed event. The dummy record may also indicate the seat and / or entrance to which the user is entitled. Thus, when the optical code is read, a database lookup identifies the corresponding dummy record, and the user can verify their access rights accordingly. Optionally, after the single-use token is used, the dummy record may be deleted to reduce memory usage and prevent reuse of the single-use token.

[0028]

[0034] Thus, advantageously, by mimicking or making the identifier in the single-use token identical to the identifier in the "normal" optical code presented by the authentication app, the authentication system and / or venue reader / scanner can read and interpret the optical code and determine the real (or simulated) mobile device identifier, real (or simulated) user identifier, and time code to grant the user entry into the ticketed event venue, just as if it had been presented via a downloaded authentication app. As with the optical code generated by the authentication app, the generated single-use token (e.g., including a barcode) sent to an electronic address may optionally be based solely or partially on data related to the venue or event, such as the location name, address, event title, performance name, event session / show information, etc. In this way, the single-use token (e.g., barcode) is independent of venue data or event data (i.e., does not include data identifying the venue or event). However, in this scenario, the single-use token (e.g., barcode) is not self-generated, downloaded to, and hosted on the user device by the credential application, but instead is generated by a system separate and independent from the user device.

[0029]

[0035] As previously mentioned, the static optical code included in the single-use token may optionally include a timestamp. Thus, the static optical code can only be used to obtain access for a threshold period of time after the time indicated in the timestamp (e.g., the current time plus 15 seconds, 30 seconds, 1 minute, 2 minutes, 3 minutes, 4 minutes, 5 minutes, or other time range). Optionally, the token generation module may determine when the token expires (i.e., when it can no longer be used to obtain access to ticketed events at the venue) by mathematically adding the threshold period to the time included in the timestamp (e.g., expiration date = threshold period + timestamp). The expiration date is transmitted to the user's electronic address to inform the user of the amount of time available before the token expires. Optionally, the token generation module may further determine the user's assigned seat from the user record. A seat identifier may be associated with the token and transmitted to the user's electronic address for display on the user device.

[0030]

[0036] When a single-use token is used to access an event, a corresponding usage record is optionally stored in a database. If someone attempts to reuse a single-use token by presenting it to a venue reader / scanner, a lookup process may determine that the token is no longer valid and issue a command to a visual and / or audible indicator (e.g., device display, LED light, etc.) to indicate authentication failure.

[0031]

[0037] Certain embodiments will be described with reference to the drawings.

[0032]

[0038] 1A illustrates an example of a network environment that can be used to implement certain exemplary processes described herein. An authentication system 102A can communicate via a network 100A (e.g., the Internet, an intranet, a cellular network, and / or other network) with one or more venue systems 108A and / or computerized kiosk systems 104A (which may be located at a pedestal or counter and available for direct use by event attendees) that may be located at the venue of a ticketed event.

[0033]

[0039] For example, a particular venue system 108A may have a corresponding authentication reader 106A (sometimes referred to as a reader or scanner) located at a venue entrance (an entrance to the venue building or an entrance to a restricted area within the building). The particular authentication reader / scanner 106A may include, by way of example, a camera and / or scanner and / or other device configured to read a token containing an optical indicia (e.g., a barcode (a one-dimensional or two-dimensional barcode such as a QR code)). The token may include a unique user identifier, a unique device identifier, and / or a timestamp for authentication purposes. For example, a scanner may read an optical code (e.g., a barcode) by shining a light beam onto the optical code and measuring the amount and pattern of reflected light. The particular venue system 108A may include a network interface configured to communicate with the authentication system 102A and any other systems via the network 100A. Similarly, the kiosk system 104A may include a network interface for communicating with the venue system 108A and / or the authentication system 102A.

[0034]

[0040] The venue system 108A, authentication reader 106A, and / or authentication system 102A may hash the data accessed from the read / scanned token (e.g., a unique user identifier, a unique mobile device identifier, and / or other data) and compare it to data obtained from the user record (e.g., a unique user identifier, a unique mobile device identifier, and / or other data) to determine whether the user possessing the token is authorized to access the ticketed event, as described elsewhere herein.

[0035]

[0041] The authentication system 102A may store user account information, which may include some or all of the following user-related data: username, user email address, user mobile phone number / SMS / text message address, user avatar, geographic information (e.g., physical address, zip code, city name, etc.), unique user identifier (e.g., alphanumeric identifier, fingerprint data, facial recognition data, iris recognition data, and / or the like), unique user device identifier (a device identifier disclosed elsewhere herein (e.g., IMEI, MEID, ESN, IMSI, and / or system-assigned identifier, which may optionally be different from and may not include a mobile device phone number), event identifiers corresponding to events to which the user has access, user preferences (e.g., favorite performers, favorite venues, favorite music styles, etc.), and / or other user-related data disclosed herein).

[0036]

[0042] Optionally, a user may be able to obtain multiple tickets to a particular event (e.g., if attending together as a group). Corresponding records may be stored in the user account, and optionally, the same token may be used to simultaneously obtain access rights for participants in the group. Optionally, the user may provide an account identifier for each person in the group who has an account with authentication system 102A or an associated system, and the corresponding tickets (and associated venue and event access rights) may be associated with each person's record (including biometric identifiers, user identifiers, and / or user device identifiers).

[0037]

[0043] Authentication system 102A may optionally store, for a given user, one or more user identifiers, passwords (e.g., text, alphanumeric user identifiers, user-specified, assigned by an electronic system, user email address, user phone number, etc.), authentication application serial numbers, and / or other account access tokens. The user identifiers, passwords, authentication application serial numbers, and / or account access tokens may be unique. Optionally, the combination or pairing of the user identifier and device identifier may be unique even if the user identifiers, passwords, authentication application serial numbers, and / or account access tokens are not unique.

[0038]

[0044] The kiosk system 104A may include a display (which may include a touchscreen), a physical keyboard, a speaker, a microphone, and / or a printer. As also described elsewhere herein, a user may utilize the kiosk system 104A to obtain a single-use token for gaining access to a ticketed event at a venue (e.g., if the user has access to the ticketed event but does not have a credential application installed on their mobile device). Also, as described elsewhere herein, the single-use token (e.g., encoding a real or simulated mobile device identifier, a real or simulated user identifier, and / or a time code) may mimic an optical code generated by an application configured to be downloaded to the user device for authentication purposes. The single-use token may be sent to an electronic address (e.g., an SMS / MMS message to a mobile phone number, an email to an email address, etc.) associated with the user and / or user device, which may have been provided or utilized when the corresponding ticket was originally obtained. Optionally, kiosk system 104A may be configured to print single-use tokens on a physical medium so that users who do not have a mobile device or access to an electronic address can use the printed single-use token to access a ticketed event. Thus, although certain embodiments may refer to generation and / or presentation of single-use tokens via a mobile device, optionally, the disclosed system may also enable generation and / or presentation of single-use tokens via a printed medium (e.g., paper, plastic, other printed media).

[0039]

[0045] User devices 110A, 112A, 114A can be in network communication with authentication system 102A. A particular user device may optionally download and execute a credential application (e.g., from an application store or via a ticketing website). This application can be used for ticket search, ticket purchase (via authentication system 102A), and / or presentation of authentication data / information, such as tokens containing optical codes described herein. Additionally, a given user device can host a messaging application (e.g., SMS / MMS, multi-platform messaging application, and / or the like) and / or an email application configured to receive messages (e.g., single-use tokens, emails, notifications, and / or the like) from other systems described herein, such as authentication system 102A, venue system 108A, kiosk system 104A, and / or other systems. For example, a user device can be configured to receive single-use tokens sent by one or more systems disclosed herein (e.g., kiosk system 104A). By way of example, the user device may be a computerized mobile device such as a smartphone, a tablet computer, a laptop computer, a wearable device (e.g., a network-connected smart watch), a handheld game console, or the like.

[0040]

[0046] FIG. 1B is a block diagram illustrating example components of authentication system 102A. The exemplary authentication system 102A includes an arrangement of computer hardware and software components that can be used to implement aspects of the present disclosure. Those skilled in the art will understand that more (or fewer) components than those illustrated in FIG. 1B may be included. Authentication system 102A may include a cloud-based computer system. Optionally, the computer hardware and / or software components illustrated in FIG. 1B may additionally or alternatively be included in venue system 108A and / or kiosk system 104A.

[0041]

[0047] With respect to cloud-based computer system implementations, a cloud-based computer system may include a hosted computer environment (sometimes referred to as a "cloud" computer environment) that includes a collection of physical computer resources that are remotely accessible, located in different facilities, and rapidly available on demand. Certain data described herein may optionally be stored using data stores that comprise the hosted storage environment. This storage environment includes a collection of physical data storage devices that are remotely accessible and rapidly available on demand (sometimes referred to as "cloud" storage).

[0042]

[0048] The authentication system 102A includes one or more processing units 120B (e.g., one or more general-purpose processors and / or high-speed graphics processors), one or more network interfaces 122B, a non-transitory computer-readable medium drive 124B, and an input / output device interface 126B, all of which can communicate with each other via one or more communication buses. The network interface 122B provides connectivity to one or more networks or computer systems (e.g., venue / kiosk systems, user devices, event promoters, seating chart visualization systems, etc.) and can provide the services described herein. The processing unit 120B can receive information (e.g., verification / authentication data (e.g., biometric data, user identifiers, device identifiers, etc.), verification / authentication requests, etc.) and / or instructions from other computer devices, systems, or services via the network, provide response data, and / or execute instructions. The processing unit 120B can also communicate with the memory 124B and provide output information via the input / output device interface 126B. The input / output device interface 126B may also accept input from one or more input devices such as a keyboard, mouse, digital pen, touch screen, microphone, camera, and the like.

[0043]

[0049] The memory 128B may include computer program instructions that the processing unit 120B executes to implement one or more aspects of the present disclosure. The memory 128B generally includes RAM, ROM (and variations thereof, such as EEPROM), and / or other permanent or non-transitory computer-readable storage media. The interface module 130B provides access to data in the memory 120B and allows data to be stored in the memory 120B. The memory 120B may store an operating system 132B, which provides computer program instructions used by the processing unit 120B in the general management and operation of the biometric authentication module 134B (including its components).

[0044]

[0050] Memory 128B can store user account records, which can include a username, a user's email address, a user's phone number / SMS / text message address, geographic information (e.g., a physical address, a zip code, a city name, etc.), one or more unique or non-unique user identifiers (e.g., an alphanumeric identifier, fingerprint data, facial recognition data, iris recognition data, gait data, and / or the like described elsewhere herein), one or more unique or non-unique user device identifiers, an event identifier corresponding to an event to which the user has access, a seat identifier corresponding to a seat assigned to the user at the corresponding event, an access identifier corresponding to a location within the venue to which the user has access at the corresponding event, a hash of the user device and / or user identifier, user preferences (e.g., favorite performers, favorite venues, favorite music styles, other preferences described herein, and / or the like), payment instrument data, and / or other user data described elsewhere herein. Memory 128B can also store event, access token, and venue information described elsewhere herein. Additionally, memory 128B may optionally store simulated records granting users of the single-use tokens described herein rights to access ticketed events at a venue.

[0045]

[0051] Some or all of the data and content described herein may optionally be stored in a relational database, an SQL database, a NOSQL database, or other database type. Because content elements may include large images (e.g., still photos (e.g., photos of biometric features), videos (e.g., videos of biometric features), multi-layered graphics, etc.) that may be difficult to process in traditional databases, some or all of the content elements (e.g., BLOBs) may be stored in files, and corresponding reference information may be stored in a database. Optionally, memory 128B may include one or more third-party cloud-based storage systems.

[0046]

[0052] The biometric authentication module 134B may include a GUI component that generates a graphical user interface and processes user input, and a search component (which may include a search engine used to search for ticketed events). The biometric authentication module 134B may also include a multi-factor authentication component configured to identify and authenticate users. As described herein, identification / authentication may be performed by comparing a hash of a unique user identifier and a unique device identifier with those generated by the authentication system 102A. By way of further example, authentication may be performed by decrypting data including the unique user identifier and / or the unique device identifier (e.g., using a private key or a key used for encryption) and comparing the decrypted data with data stored by the authentication system 102A. Optionally, the Advanced Encryption Standard (AES), a symmetric encryption algorithm that encrypts fixed data blocks (628 bits), may be used. As yet another example, Rivest-Shamir-Adleman (RSA) encryption / decryption technology may optionally be utilized. As yet another example, triple DES (Data Encryption Standard) encryption / decryption technology may optionally be utilized. As yet another example, a hash function may be utilized. Optionally, additionally or alternatively, authentication may be performed using biometric data of the user (e.g., iris data, fingerprint data, facial data, etc.).

[0047]

[0053] The access rights verification component can be configured to determine whether an identified / authenticated user has access to an event at a venue (and / or portion of an event venue). For example, the access rights verification component can be configured to determine whether an identified user has a ticket to an event at a venue at a given date and time, for a given seat or seating area (e.g., by accessing a record corresponding to the identified user and determining whether there is an access rights indication for the identified user to the event at the current date and time).

[0048]

[0054] The ticket issuance module 136B may be configured to allow a user to view information about a ticketed event, access a seating map for the event venue, view available / unavailable venue seats, access images of the view from a particular seat, view ticket prices, create a user account (which may optionally include some or all of the user account information described herein), purchase or otherwise obtain one or more access rights (e.g., access tokens / tickets) to the event, store an indication of the access rights obtained by the user, and / or recommend events to the user (e.g., by using user preferences, access token acquisition history, geographic location, event sponsorships, etc.).

[0049]

[0055] Image analysis processing module 138B may perform image analysis (e.g., on images of optical indicia encoding encrypted authentication data, images of biometric features (e.g., iris, face, finger, etc.), etc.) and perform contrast enhancement, blur correction, and / or image rotation, thereby enhancing the decoding and decryption of images of optical indicia (e.g., barcodes captured using a camera device) and / or biometric features.

[0050]

[0056] 2 illustrates an example venue authentication configuration. Attendees 202 of a ticketed event may queue or wait at the entrance to the venue for admission. A reader / scanner 204 may be positioned to capture or read an image of optical authentication data (e.g., a one-dimensional or two-dimensional barcode such as a QR code encoding a user identifier, a device identifier, and / or a timestamp) from a user device 206. The reader / scanner 204 may include a barcode scanner that shines a light beam (e.g., via one or more LEDs) on the barcode, measures the amount and pattern of reflected light, converts the light energy into data via a decoder, and transmits the data to a computer (e.g., venue system 108A and / or authentication system 102A). Additionally or alternatively, the reader / scanner 204 may include a camera (e.g., that takes an image of the barcode, converts the barcode into data, and transmits the data to a computer such as venue system 108A and / or authentication system 102A). The entrance to the venue may optionally be configured with a barrier 208 (e.g., turnstile or gate) that may be computer controlled and may unlock and / or open (e.g., by using electric motors, solenoids, and / or other actuators) in response to identifying the participant and / or verifying that the participant has access rights to enter the venue during the current time period during which the event is being held.

[0051]

[0057] The images and / or data from the reader / scanner 204 (or data derived from the information captured by the reader / scanner 204) can be transmitted to an authentication system, such as authentication system 102A and / or venue system 108A, to identify and / or determine whether the participant has access to the venue (e.g., access to the event at the current time). The authentication system 102A can transmit data to the venue device 210 indicating whether the participant has access.

[0052]

[0058] Device 210 may display visual and / or audible indications indicating whether the participant is authorized to access the event. If a determination is made to deny a user access to the event, optionally, one or more of the disclosed systems may instruct device 210 to display a reason for the denial (e.g., no matching user record found, no user record associated with a ticket for the event, an expired access token, etc.). Device 210 may include a portable handheld device (e.g., one held by venue personnel controlling access to the venue) and / or a fixed display / lighting indicator (e.g., mounted on a stand, barrier 208, wall, etc.). Device 210 may also be combined with a reader / scanner, such as reader / scanner 204, into a single integrated device. For example, device 210 may be configured with one or more indicator lights (e.g., red and / or green LED lights) and / or a flat panel display to indicate whether a user of device 206 should be allowed entry or denied entry to a ticketed event venue (e.g., in response to a failure to authenticate the user and / or to verify that the user possesses a valid ticket for the event).

[0053]

[0059] Referring to Figure 3, an example process is shown that can be implemented using one or more of the systems disclosed herein to generate single-use tokens that mimic tokens generated by a credential application downloaded and running on a user's mobile device.

[0054]

[0060] At block 300, a request for an access token (e.g., a single-use access token) is received from a user at the ticketed event venue (e.g., a user possessing a mobile device that has downloaded an authentication application). The request may be received via controls presented by a user interface provided by a computerized kiosk (located at a pedestal or counter and available for direct use by event attendees) in network communication with venue systems and / or a remote authentication system, or may be received by a service representative.

[0055]

[0061] In block 302, an electronic address (e.g., a mobile phone number, other messaging address, email address, and / or the like) may be received from the user via a user interface provided by the kiosk or a service representative that may then be entered at a computer terminal. The electronic address may be provided by the user in response to a request for an electronic address provided by the user interface via the kiosk or by the service representative. The request may specify that the user should provide an electronic address that the user previously provided when acquiring (purchasing or otherwise receiving) tickets / access to a ticketed event or an electronic address associated with the user's user record.

[0056]

[0062] At block 304, a search may be performed in one or more databases (e.g., a venue system database or a remote authentication system) for a user record associated with the electronic address. If a matching user record is not identified, at block 305, an error message may be generated indicating that a user record corresponding to the electronic address was not found. For example, the error message may be presented via a display and / or speaker on the kiosk or a display and / or speaker on another computer / computer terminal. The error message may indicate the reason for the error message (e.g., a user record associated with the electronic address was not found).

[0057]

[0063] If a user record associated with the electronic address is identified through the database search, a determination may be made in block 306 whether the user record is associated with access (e.g., tickets) to ticketed events at the venue. If the user record is not associated with access to ticketed events at the venue, an error message may be generated in block 307, optionally indicating that the user's account is not associated with access to ticketed events. For example, the error message may be presented via a display and / or speaker on the kiosk or another computer display and / or speaker.

[0058]

[0064] If it is determined that access to the ticketed event is associated with the user record, then a single-use token may be generated at block 308, as also described elsewhere herein. Thus, optionally, if a user record exists that includes a device identifier for the user (e.g., a unique device identifier such as an IMEI, MEID, ESN, IMSI, and / or system-assigned identifier, which may be different from and independent of the device's phone number), the device identifier from the user record may be used for the optical code. Optionally, if a record for the user includes a user identifier (e.g., a unique user identifier), the user identifier may be used for the optical code. Additionally, the optical code may optionally include a timestamp (the current time or the current time plus an additional time such that the timestamp expires at a later time). Optionally, the device identifier, user identifier, and / or timestamp may be encrypted (e.g., using one or more encryption methods described herein).

[0059]

[0065] Optionally, if the actual user identifier and / or actual device identifier are not available via the user record, the optical code may optionally include a timestamp (the current time or the current time plus an additional time so that the timestamp expires at a later time), a unique generated identifier (sometimes referred to as a simulated mobile device identifier). This identifier corresponds to the format (e.g., length, use of allowed characters) of a unique mobile device identifier, but may optionally not be that of an actual mobile device (or may correspond to the identifier of a device that is no longer in use). Similarly, the optical code may optionally include a unique identifier (sometimes referred to as a simulated user identifier) ​​that is different from the actual user identifier. This identifier corresponds to the format (e.g., length, use of allowed characters) of a unique user identifier, but may optionally not be that of an actual user (or may be that of a user that no longer has an account with the authentication / ticketing system). For example, the optical code may include a timestamp (the current time or the current time plus an additional time so that the timestamp expires at a later time), a simulated mobile device identifier, and a simulated user identifier. If the credential application generates an encrypted version of the identifier and / or timestamp, the simulated identifier and / or timestamp may be encrypted as well.

[0060]

[0066] As previously mentioned, the timestamp can be the current time plus an additional time, such that it expires at a later time. The additional time can be determined using the physical distance a kiosk or service representative travels to the entrance of the venue where the token reader / scanner is located and the estimated time it will take the user to travel that distance. The travel time (e.g., walking time) can be determined (which can be performed using a computer system such as the system described herein) by taking into account the predicted or estimated pedestrian volume along the route from the kiosk / service representative to the token reader / scanner. Optionally, the additional time can be dynamically set based on real-time or near-real-time (e.g., in the range of 1-5 minutes, 1-10 minutes, or 1-15 minutes) route images using a learning engine that can identify / estimate traffic volume and travel time from the route images. For example, if the estimated travel time is 2 minutes, the timestamp can be set by adding the estimated travel time to the current time. Optionally, the additional time can be set to be less than the estimated travel time (e.g., a percentage of the estimated travel time) to ensure that the patron's actual time of arrival at the token reader / scanner is not earlier than the timestamp time. For example, if the estimated travel time is 2 minutes, the timestamp can be set by adding 50% of the estimated travel time (1 minute in this example) to the current time.

[0061]

[0067] As also described herein, advantageously, by mimicking the identifier to that of a "normal" optical code presented by an authentication app, an authentication system and / or venue reader / scanner can read and interpret the optical code and determine that the real (or simulated) mobile device identifier, real (or simulated) user identifier, and time code grant the user the same rights to enter the ticketed event venue as if they had been presented via a downloaded authentication app. As noted above, the generated single-use token barcode may optionally not be based on data related to the venue or event (e.g., it may not include venue location, venue name, venue address, event name, seat number, etc.). Thus, the generated single-use token barcode is independent of venue or event data (i.e., it does not include data identifying the venue or event) and is not self-generated by an authentication app downloaded and hosted on the user device, but rather is generated by a system separate and independent from the user device.

[0062]

[0068] In block 310, the expiration date for the single-use token (after which the token can no longer be used to gain access to ticketed events at the venue) is calculated by adding a threshold period to the time contained in the timestamp. For example, if the current time is 12:00 PM and the single-use token is only valid for 15 minutes, the expiration date is 12:15 PM.

[0063]

[0069] Optionally, if the generated single-use token does not include the user's actual user identifier and / or mobile device identifier (and therefore may not be usable to access an actual user record), a "dummy" record may be generated and recorded in a database (e.g., an authentication system and / or venue system) in block 312. This dummy record indicates that the holder of the single-use token is entitled to admission to the ticketed event. This record may also indicate the seat and / or entrance to which the user is entitled. Thus, when the optical code is read, a database lookup identifies the corresponding dummy record, thereby confirming that the user has access rights. Optionally, after the single-use token is used, the dummy record may be deleted to reduce memory usage and prevent reuse of the single-use token.

[0064]

[0070] At block 314, the generated single-use token is sent to an electronic address associated with the access / ticket acquisition, optionally in association with an expiration date and / or seat identifier.

[0065]

[0071] 4A and 4B, an example process is shown for identifying a person at a venue using an optical token and determining whether the identified person currently has access to the venue (e.g., for a particular event). This process may be performed in whole or in part by the venue system, or in whole or in part by an authentication system or other system, and may be performed in conjunction with a user device.

[0066]

[0072] In block 402, a token (e.g., a single-use access token) presented via a user device is read / scanned by a reader / scanner at the venue. For example, the access token may include a computer-readable optical indicia (e.g., a barcode such as a QR code that encodes data). In block 404, a decoding and / or decryption process is used to convert the token to data. For example, the barcode may encode a user identifier and / or a device identifier and / or a timestamp and / or a hash value thereof, which can be decoded. Additionally, the barcode may include encrypted versions of the aforementioned data, which can be encrypted using a public key and decrypted using a private key.

[0067]

[0073] In block 406, it is determined whether the data includes data corresponding to a user identifier (e.g., in the correct format, i.e., with the correct number and type of characters), data corresponding to a device identifier (e.g., in the correct format, i.e., with the correct number and type of characters), or hash values ​​thereof, and a timestamp.

[0068]

[0074] If the format is determined to be malformed, an access denial indication is generated in block 408. For example, a corresponding message or instruction may be sent to a device at the entrance to the event venue where the reader / scanner is located, indicating that the user is not authorized to access. The message or instruction may activate corresponding visual and audible indicators to provide a human-perceivable indication of success / failure, such as illuminating a red light or displaying an access denial text and / or graphic message on the device. If the format is correct, the mobile device identifier value, user identifier value, and timestamp value are decoded from the token.

[0069]

[0075] At block 410, a determination is made as to whether the token has expired. For example, the reader / scanner or other system may compare the timestamp with the current time to determine whether the timestamp has expired or meets a threshold date and time range (e.g., the current time plus 15 seconds, 30 seconds, 1 minute, 2 minutes, 3 minutes, 4 minutes, 5 minutes, or other specified time range). If the token has expired, at block 412, an access denied / token expired indication may be generated. For example, a corresponding message or instruction may be sent to a device at the entrance to the event venue where the reader / scanner is located, indicating that the user is unauthorized and / or that the token has expired. This message or instruction may activate corresponding visual and audible indicators to provide a human-perceivable indication of success / failure, such as illuminating a red light and / or displaying an access denied text and / or graphic message on the device.

[0070]

[0076] If it is determined that the token is not expired, then in block 414, the device identifier and user identifier (or hash value or other processed data) decrypted and / or decrypted from the token are compared with those in a user record database, and in block 416, it is determined whether a user record exists with a matching device identifier and user identifier (or hash value or other processed data). As described elsewhere herein, in certain circumstances, a dummy record corresponding to the single-use token may be generated and stored in the database. Thus, if the token read / scanned in block 402 is a single-use token, it will match the dummy record.

[0071]

[0077] If a matching user record (corresponding to the user and device identifiers contained in the read / scanned token) is not found, an access denied / record not found indication is generated in block 418. For example, a corresponding message or instruction may be sent to a device at the entrance to the event venue where the reader / scanner is installed, indicating that the user is not authorized and / or that no matching record was found. This message or instruction may activate corresponding visual and audible indicators to provide a human-perceivable indication of success / failure, such as illuminating a red light or displaying a text and / or graphic message that access is denied to the device.

[0072]

[0078] If a matching user record (or dummy record) is found, then in block 420, it may be determined whether access rights exist (e.g., one or more tickets for one or more attendees) for a ticketed event at the venue associated with the user record (or dummy record).

[0073]

[0079] If there are no access rights associated with the user record (or dummy record), an access denied / no ticket indication is generated in block 422. For example, a corresponding message or instruction may be sent to a device at the entrance to the event venue where a reader / scanner is installed, indicating that the user is not authenticated and / or does not have a ticket for the event. This message or instruction may activate corresponding visual and audible indicators to provide a human-perceivable indication of success / failure, such as illuminating a red light or displaying an access denied text and / or graphic message on the device.

[0074]

[0080] If the user record (or dummy record) is granted access, then in block 424 it is determined whether the single-use access token has already been used (e.g., by referencing a database record associated with the user or the single-use token). If it is determined that the single-use access token has already been used, then in block 426 an access denied / no ticket indication is generated. For example, a corresponding message or instruction may be sent to a device at the entrance to the event venue where a reader / scanner is installed, indicating that the user is not authorized and / or that the single-use access token has already been used. This message or instruction may activate corresponding visual and audible indicators to provide a human-perceivable indication of success / failure, such as illuminating a red light or displaying an access denied text / graphic message on the device.

[0075]

[0081] Even if it is determined that the single-use access token has already been used, an access permission indication may be generated in block 428. If there are multiple tickets associated with the token, the indicator may indicate the number of tickets. For example, a corresponding message or instruction may be sent to a device at an entrance to an event venue where a reader / scanner is installed, indicating the number of participants authorized to access the event at the venue (e.g., the user presenting the token and the number of additional participants accompanying the user). The message or instruction may cause corresponding visual and audible indicators to provide a human-perceptible indication of success, such as illuminating a green light or displaying access permission text and / or a graphic message on the device. Optionally, information indicating that the single-use token was used to access the event may be stored in association with a user record or single-use token record to prevent unauthorized reuse of the single-use token.

[0076]

[0082] 5 shows an example of a single-use optical token and associated data. As also described elsewhere, the optical token may optionally include a QR code encoding an encrypted user identifier, device identifier, and / or timestamp. The QR code may be displayed in association with a seat identifier and expiration date, as also described elsewhere.

[0077]

[0083] Although access tokens are sometimes referred to as one-time or single-use access tokens, the access token may optionally be configured to be limited to a threshold number of uses greater than one (e.g., to allow a user who possesses the access token to leave and re-enter the event venue up to a threshold number of times during the event). Alternatively, the access token may be configured to allow the holder unlimited access to the event venue while the event is running (e.g., to allow a user who possesses the access token to leave and re-enter the venue no more than a threshold number of times during the event). Optionally, the access token may be configured to allow unlimited access to the event venue until a timestamp indicates that the access token has expired.

[0078]

[0084] Thus, a method and system are described that allows access tokens to be sent to a user device and utilized to access a location, even when the user device does not have a credential application hosted on it.

[0079]

[0085] The methods and processes described herein may have fewer or additional steps or states, and the steps or states may be performed in a different order. Not all steps or states need to be reached. The methods and processes described herein may be embodied by software code modules executed by one or more general-purpose computers and may be fully or partially automated. The code modules may be stored on any type of computer-readable medium or other computer storage device. Some or all of the methods may alternatively be embodied in whole or in part in dedicated computer hardware. The systems described herein may optionally include a display, a user input device (e.g., a touch screen, a keyboard, a mouse, voice recognition, etc.), a network interface, etc.

[0080]

[0086] The results of the disclosed methods can be stored in any type of computer data repository, such as a relational database and a flat file system using volatile and / or non-volatile memory (e.g., magnetic disk storage, optical storage, EEPROM and / or solid-state RAM).

[0081]

[0087] The various illustrative logic blocks, modules, routines, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, the various illustrative components, blocks, modules, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the particular application and design constraints imposed on the overall system. The described functionality may be implemented in various ways for each particular application, and such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure.

[0082]

[0088] Furthermore, the various illustrative logic blocks and modules described in connection with the embodiments disclosed herein may be implemented or performed by machines such as a general-purpose processor device, 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 device may be a microprocessor, but may alternatively be a controller, microcontroller, state machine, combinations thereof, or the like. A processor device may include electrical circuitry configured to process computer-executable instructions. In another embodiment, a processor device includes an FPGA or other programmable device that performs logical operations without processing computer-executable instructions. A processor device may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or other similar configurations. While described herein primarily with respect to digital technology, a processor device may also include primarily analog components. The computing environment includes any type of computing system, including, but not limited to, a microprocessor-based computing system, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computing engine within a consumer electronics product.

[0083]

[0089] Elements of the methods, processes, routines, or algorithms described in connection with the embodiments disclosed herein may be implemented directly in hardware, or in software modules executed by a processor device, or in a combination of both. The software modules may be stored in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or other non-transitory computer-readable storage medium. An exemplary storage medium may be coupled to the processor device such that the processor device can read information from, and write information to, the storage medium. Alternatively, the storage medium may be integral to, the processor device. The processor device and the storage medium may be located in an ASIC. The ASIC may be located in a user terminal. Alternatively, the processor device and the storage medium may be located as discrete components in a user terminal.

[0084]

[0090] As used herein, conditional language (such as "can," "can be," "might," "for example," etc.) is generally intended to indicate that certain features, elements, and / or steps are included in certain embodiments, but not in other embodiments, unless specifically stated otherwise or understood otherwise by context. Thus, such conditional language is generally not intended to imply that features, elements, and / or steps are somehow essential to one or more embodiments, or that one or more embodiments necessarily include logic that determines whether those features, elements, and / or steps are included or performed in a particular embodiment, with or without other input or prompting. Terms such as "comprise," "have," and the like are synonymous and used in an inclusive and open-ended manner and do not exclude additional elements, features, acts, operations, etc. Additionally, the term "or" is used in an inclusive (not exclusive) sense, so that, for example, when connecting a list of elements, the term "or" may refer to one, some, or all of the elements in the list.

[0085]

[0091] Alternative expressions such as "at least one of X, Y, and Z" are understood to indicate that an item, term, etc. can be any of X, Y, and Z, or any combination thereof (e.g., X, Y, and / or Z) in the sense commonly used in the context, unless specifically stated otherwise. Thus, such alternative expressions are not intended to, and should not be interpreted to, require that at least one of X, at least one of Y, or at least one of Z be present in a particular embodiment.

[0086]

[0092] Although the term "click" is used when a user selects a control, menu selection, etc., other user inputs, such as voice commands, text input, gestures, etc., can also be used. User input can be provided, for example, through an interface such as a text field into which the user enters text and / or through a menu selection (e.g., a drop-down menu, list, or other arrangement in which the user can check boxes or otherwise make a selection, a group of individually selectable icons, etc.). When a user provides input or activates a control, a corresponding computer system can perform a corresponding operation. Some or all of the data, input, or instruction provided by the user can optionally be stored in a system data store (e.g., a database) from which the system can access and retrieve such data, input, or instruction. The notifications / alerts and user interfaces described herein can be provided through web pages, dedicated or non-dedicated telephone applications, computer applications, short message service (e.g., SMS, MMS), instant messages, email, push notifications, voice, pop-up interfaces, and / or other means.

[0087]

[0093] The user terminals described herein may take the form of mobile communication devices (e.g., mobile phones), laptops, tablet computers, interactive televisions, gaming consoles, media streaming devices, head-wearable displays, network-enabled watches, other wearable computing devices, etc. User terminals may optionally include displays, user input devices (e.g., touch screens, keyboards, mice, voice recognition, etc.), network interfaces, etc.

[0088]

[0094] While the foregoing detailed description has illustrated, described, and pointed out novel features applicable to various embodiments, it should be understood that various omissions, substitutions, and changes can be made in the form and details of the illustrated apparatus or algorithms without departing from the spirit of the disclosure. It should be understood that certain embodiments described herein may be embodied in a form that does not provide all of the features and advantages described herein, since some features may be used or practiced in isolation from other features. The scope of the specific embodiments disclosed herein is indicated by the appended claims, rather than the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1. 1. A computer-implemented method for electronically generating a time-limited, single-use access token that includes an encrypted and / or hashed identifier, comprising: receiving, at a computer system, a request for a single-use optical token from a user at a first venue of a first event; receiving, at the computer system, from the user at the first venue of the first event, an electronic address that purports to be associated with access rights obtained remotely from the first venue for the first event at the first venue; searching a database for a record associated with said electronic address; In response at least in part to identifying a first record associated with the electronic address, determining whether the first record is associated with the access rights for the first event; In response at least in part to determining that the first record is associated with the access rights for the first event, generating a token including a computer readable optical code including a device identifier and a user identifier encrypted using a first key and a timestamp; determining an expiration date associated with the token including the device identifier and the user identifier and the computer readable optical code including the timestamp, wherein the device identifier and the user identifier are encrypted using the first key, and the computer readable optical code does not include a ticket, venue identifier, or event identifier; determining a seat associated with the first record; sending, while the first user is at the first venue, to the electronic address using a messaging service, the token including the expiration date, a seat identifier corresponding to the seat associated with the first record, the device identifier and the user identifier, and a computer readable optical code including the timestamp, wherein the device identifier and the user identifier are encrypted using the first key, and the electronic address is accessible from a first device of the first user; reading the token, including the computer readable optical code including the device identifier and the user identifier, from a display of the first device with an optical reader, wherein the device identifier and the user identifier are encrypted using the first key; decrypting the encrypted device identifier and the user identifier using a second key; determining whether the decrypted device identifier and the user identifier correspond to those of the first record; and sending instructions causing an access permission indication to be displayed by a venue device in response at least in part to determining that the decrypted device identifier and the user identifier correspond to those of the first record.

2. 2. The method of claim 1, wherein determining whether the decrypted device identifier and the user identifier correspond to those of the first record further comprises comparing hash values ​​of the decrypted device identifier and the user identifier with hash values ​​of the device identifier and the user identifier accessed from the first record.

3. 2. The method of claim 1, wherein the token including the computer-readable optical code including the device identifier, the user identifier, and the timestamp further includes error correction implemented using a Bose-Chaudhuri-Hockenhem code.

4. The method of claim 1 , further comprising determining from the timestamp whether the token has expired after being read by the optical reader.

5. The method of claim 1 , wherein the first device comprises a mobile phone.

6. providing a credential application for download to a second device associated with a second user, the credential application configured to generate a second token including a second computer-readable optical code that includes a device identifier associated with the second device, a user identifier associated with the second user, and a timestamp; using the optical reader to read the second token from a display of the second device, the second token including the second computer-readable optical code including the device identifier associated with the second device, the user identifier associated with the second user, and the timestamp; decrypting the encrypted device identifier associated with the second device and the user identifier associated with the second user; determining whether the device identifier associated with the second device and the user identifier associated with the second user correspond to those in the second record; 10. The method of claim 1, further comprising: transmitting, at least in part, instructions to cause the venue device to display a second access permission indication in response to determining that the decrypted device identifier associated with the second device and the user identifier associated with the second user correspond to those of the first record.

7. 10. The method of claim 1, further comprising determining an estimated travel time from a first location of the venue to a second location of the venue, wherein the timestamp is determined based at least in part on a current time and the estimated travel time from the first location of the venue to the second location of the venue.

8. The method of claim 1 , wherein the computer system comprises a kiosk with a display and a user input device configured to accept the electronic device directly from the user.

9. a computing device; and a non-transitory computer-readable memory storing instructions that, when executed by the computing device, cause the computing device to perform operations, the operations including: receiving a request for a single-use optical token from a user at a first venue of a first event; receiving, from the user at the first venue of the first event, an electronic address purportedly associated with access rights obtained remotely from the first venue for the first event at the first venue; searching a data store for a record associated with the electronic address; In response at least in part to identifying a first record associated with the electronic address, determining whether the first record is associated with the access rights for the first event; generating, at least in part in response to determining that the first record is associated with the access rights for the first event, a token including a computer readable optical code including a device identifier and a user identifier and a timestamp; determining an expiration date associated with the token including the device identifier and the user identifier and the computer readable optical code including the timestamp, wherein the computer readable optical code does not include a ticket, venue identifier, or event identifier; sending, while the first user is at the first venue, to the electronic address using a messaging service, the expiration date, a seat identifier corresponding to the seat associated with the first record, and the token, the token including a computer readable optical code including the device identifier and the user identifier, and the timestamp; reading the token, including the computer-readable optical code containing the device identifier and the user identifier, and the timestamp, from a display of the first device using an optical reader; determining whether the device identifier and the user identifier correspond to those of the first record; and transmitting instructions causing an access permission indication to be displayed by a venue device in response at least in part to determining that the device identifier and the user identifier correspond to those of the first record.

10. 10. The system of claim 9, wherein determining whether the device identifier and the user identifier correspond to those of the first record further comprises comparing hash values ​​of the device identifier and the user identifier with hash values ​​of the device identifier and the user identifier accessed from the first record.

11. 10. The system of claim 9, wherein the token including the computer-readable optical code including the device identifier and the user identifier further includes error correction implemented using a Bose-Chaudhuri-Hockenhem code.

12. 10. The system of claim 9, further comprising determining from the timestamp whether the token has expired after being read by the optical reader.

13. The system of claim 9 , wherein the first device comprises a mobile phone.

14. providing a credential application for download to a second device associated with a second user, the credential application configured to generate a second token including a second computer-readable optical code that includes a device identifier associated with the second device, a user identifier associated with the second user, and a timestamp; using the optical reader to read the second token from a display of the second device, the second token including the second computer-readable optical code including the device identifier associated with the second device, the user identifier associated with the second user, and the timestamp; determining whether the device identifier associated with the second device and the user identifier associated with the second user correspond to those in the second record; and transmitting instructions causing a second access permission indication to be displayed by the venue device in response at least in part to determining that the device identifier associated with the second device and the user identifier associated with the second user correspond to those of the first record.

15. The operation is determining an estimated travel time from a first location of the venue to a second location of the venue; The system of claim 9 , wherein the timestamp is determined based at least in part on a current time and the estimated travel time from the first location of the venue to the second location of the venue.

16. A non-transitory computer-readable storage medium storing instructions that, when executed by a computer system, cause the operations to be performed, the operations including: receiving a request for a single-use optical token from a user at a first venue of a first event; receiving, from the user at the first venue of the first event, an electronic address purportedly associated with access rights obtained remotely from the first venue for the first event at the first venue; searching a data store for a record associated with the electronic address; determining, at least in part in response to identifying the first record associated with the electronic address, whether the first record is associated with the access rights for the first event; generating, at least in part in response to determining that the first record is associated with the access rights for the first event, a token including a computer readable optical code including a device identifier and a user identifier and a timestamp; sending, while the first user is at the first venue, to the electronic address using a messaging service, a seat identifier corresponding to the seat associated with the first record, and the token including a computer-readable optical code including the device identifier, the user identifier, and the timestamp; reading the token, including the computer-readable optical code containing the device identifier and the user identifier, and the timestamp, from a display of the first device using an optical reader; determining whether the device identifier and the user identifier correspond to those of the first record; and transmitting instructions that cause an access permission indication to be displayed by a venue device in response at least in part to determining that the device identifier and the user identifier correspond to those of the first record.

17. The operation is determining an expiration date associated with the token including the device identifier and the user identifier, and the computer readable optical code including the timestamp; and transmitting the expiration date to the electronic address.

18. 17. The non-transitory computer-readable storage medium of claim 16, wherein determining whether the device identifier and the user identifier correspond to those of the first record further comprises comparing hash values ​​of the device identifier and the user identifier with hash values ​​of the device identifier and the user identifier accessed from the first record.

19. 17. The non-transitory computer-readable storage medium of claim 16, wherein the token including the computer-readable optical code including the device identifier and the user identifier further includes error correction implemented using a Bose-Chaudhuri-Hockenhem code.

20. The operation is 17. The non-transitory computer-readable storage medium of claim 16, further comprising determining from the timestamp whether the token has expired after being read by the optical reader.

21. The non-transitory computer-readable storage medium of claim 16 , wherein the first device comprises a mobile phone.

22. The operation is providing a credential application for download to a second device associated with a second user, the credential application configured to generate a second token including a second computer-readable optical code that includes a device identifier associated with the second device, a user identifier associated with the second user, and a timestamp; using the optical reader to read from a display of the second device a second token including the second computer-readable optical code that includes the device identifier associated with the second device, the user identifier associated with the second user, and the timestamp; determining whether the device identifier associated with the second device and the user identifier associated with the second user correspond to those in the second record; and transmitting instructions that cause a second access permission indication to be displayed by the venue device in response at least in part to determining that the device identifier associated with the second device and the user identifier associated with the second user correspond to those of the first record.

23. The operation is 17. The non-transitory computer-readable storage medium of claim 16, further comprising determining an estimated travel time from a first location of the venue to a second location of the venue, wherein the timestamp is determined based at least in part on a current time and the estimated travel time from the first location of the venue to the second location of the venue.

Images