RU2792695C2 - Synchronizing the state of the marker - Google Patents

Abstract

FIELD: computer technology.

SUBSTANCE: result is achieved by submitting, by means of a first service provider application of a plurality of service provider applications on the communication device, to the computer of the first service provider, a first request for a first application token; receiving, by the first service provider application on the communication device, from the first service provider computer, an encrypted application token corresponding to the first application token; receiving, by the account management application on the communication device, from the first service provider application on the communication device, the encrypted application token; sending, by means of the account management application on the communication device, to the token service computer in communication with the computer of the first service provider, a token issuance request with an encrypted application token, receiving, by means of the account management application on the communication device, from the token service computer, the first application token with the container wherein the token container is associated with a container identifier and a token state associated with the first application token, the token state and the container identifier being maintained by the token service computer, the token state including at least one of a newly generated token, an extinguished token, and value-added token and store the first application token in a token container in the account management application.

EFFECT: technical result consists in providing the ability to control access to resources using application tokens, ensuring data security.

23 cl, 14 dwg

Description

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional Application No. 62/693,631, filed July 3, 2018, the contents of which are incorporated herein by reference in their entirety.

BACKGROUND OF THE INVENTION

[0002] Digital means for accessing resources are becoming increasingly popular. A communication device such as a smartphone may be equipped with various applications for interactions such as travel, entertainment, and shopping. One example is a wallet application that can store payment data associated with one or more payment instruments. The saved payment details can be presented through the wallet application to complete the transaction. Another example is a ticketing and buying application that can store a quick response (QR) code that can be scanned to redeem a ticket for a trip, event, or the like.

[0003] As the number of such applications increases, application integration becomes more difficult. For example, there may be thousands of transportation and entertainment providers, hundreds of third-party ticket sellers, and dozens of wallet app providers. To allow users to use their chosen wallet provider to purchase tickets through hundreds or thousands of possible channels, each of the hundreds or thousands of providers must be able to communicate with each of the wallet providers.

[0004] Another disadvantage of many resource access applications is the use of barcodes, such as QR codes, which typically must be manually selected by the user and can be difficult to scan into a reader at the access point. In addition, such codes are easily transferred and copied, making it difficult for the supplier to maintain control over their use.

[0005] Embodiments of the present invention address these and other disadvantages both individually and collectively.

SUMMARY OF THE INVENTION

[0006] According to some embodiments, the process of managing application tokens may include providing the first service provider application on the communication device to the computer of the first service provider with a first request for the first application token, receiving the account management application on the communication device from the computer of the token service in communication with the computer the first service provider, the first application token, and storing the first application token in a token container in the account management application.

[0007] According to other embodiments, the communication device may include a memory, a processor, a persistent computer-readable medium containing instructions that, when executed by the processor, perform the steps: providing the application of the first service provider on the communication device to the computer of the first service provider of the first request for the first application token ; receiving by the application for managing the account on the communication device from the service computer of tokens in communication with the computer of the first service provider, the first application token; and storing the first application token in the token container in the account management application.

[0008] According to other embodiments, the method may include receiving by the service provider computer from the service provider application on the communications device a request for an application token; and transmitting, by the service provider computer, a token issuance request to the service computer for issuing an application token to the token container in the account management application on the communication device.

[0009] According to other embodiments, the service provider's computer may include a memory, a processor, and a readable medium containing instructions that, when executed by the processor, perform the steps of: receiving, from a service provider application on a communications device, a request for an application token; and transmitting the issuance request to the token service computer to issue the application token to the token container in the account management application on the communication device.

[0010] According to other embodiments, the method may include receiving, on a service computer, issuance request tokens to issue an application token to a token container in an account management application on a communication device, wherein the communication device also includes a service provider application associated with the service provider computer, and transferring to the account management application on the communication device from the service computer the tokens of the application token to the token container in the account management application on the communication device.

[0011] According to other embodiments, the token service computer may include a memory, a processor, and a readable medium containing instructions that, when executed by the processor, perform the steps of: receiving a issuance request for issuing an application token to a token container in an account management application on a communication device wherein the communication device also comprises a service provider application associated with the service provider computer and transferring to the account management application on the communication device from the service computer the application token to the token container in the account management application on the communication device.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] FIG. 1 shows a communications device communicating with a set of service provider computers and an account management server, in accordance with some embodiments.

[0013] FIG. 2A-2B show communications devices communicating with a set of service provider computers, in accordance with some embodiments.

[0014] FIG. 3 shows the process and system for issuing and redeeming an application token in accordance with some embodiments.

[0015] FIG. 4A-4B show a block diagram of a communication device according to some embodiments.

[0016] FIG. 5 shows a block diagram of a service provider's computer according to some embodiments.

[0017] FIG. 6 is a block diagram of a token service computer according to some embodiments.

[0018] FIG. 7 shows the process of issuing an application token according to some embodiments.

[0019] FIG. 8 shows another application token issuance process according to some embodiments.

[0020] FIG. 9 shows an application token redemption process according to some embodiments.

[0021] In FIG. 10-11 show schemes for updating loyalty data according to some embodiments.

[0022] FIG. 12 shows a flow diagram of a process for managing application tokens and token states, in accordance with some embodiments.

IMPLEMENTATION OF THE INVENTION

[0023] Methods for managing an application token are described. In some embodiments, the first service provider's application on the communication device may provide the first service provider's computer with a first request for a first application token. The account management application on the communication device receives, from the token service computer in communication with the computer of the first service provider, the first application token. The first application token is stored in the token container in the account management application.

[0024] In some embodiments, the service provider may operate the token service computer to issue application-specific tokens that are associated with a token container. Application-specific tokens may have their own token states, and application tokens and their respective token states may be issued to the user's communication device. When the application token stored on the communication device is used, the state of the token can be updated. In this way, data security and convenience can be ensured when combined with data such as ticketing and purchasing information (such as travel and trip information), loyalty information, or other application-specific information or data.

[0025] Before discussing the embodiments of the present invention, a description of certain terms may be helpful in understanding the embodiments of the present invention.

[0026] A "communication device" may be a device that includes one or more electronic components (eg, an integrated circuit) that can communicate with another device. A "portable communication device" may be one form of a communication device that can be carried and controlled by a user. The portable communications device may provide remote network communication functionality and may be configured to send and receive data or messages to and from other devices. The portable communication device may take the form of a mobile device such as a mobile phone (e.g., smartphone, cellular phone, etc.), tablet devices, portable media player, personal digital assistant (PDA) devices, wearable computing device (e.g., watch ), an electronic reader, etc., or the form of a card (such as a smart card) or key fob, etc. Examples of portable communication devices may also include portable computing devices (eg, laptop, netbook, ultrabook, etc.). The portable communication device may also be in the form of a vehicle (eg, an automobile, such as a car) provided with communication and/or network connectivity functionality.

[0027] A "server computer" may include a powerful computer or a cluster of computers. For example, a server computer may be a large mainframe computer, a cluster of minicomputers, or a group of servers that function as one unit. In one example, the server computer may be a database server connected to a web server. The server computer may be connected to the database and may include any hardware, software, other logic, or a combination of the foregoing to serve requests from one or more client computers. The server computer may include one or more computing devices and may use any of a variety of computing structures, arrangements, and compilations to serve requests from one or more client computers.

[0028] An "application" may be a computer program that is used for a specific purpose.

[0029] A "Time Item" may include data relating to any suitable time. For example, the time data element may be a time, date, month, year, or any suitable combination of the above. The time data element may also be derived from a time, date, month, year, or any suitable combination of the above. The encrypted time item may be an item that may include an encrypted time, date, month, year, and/or a suitable combination of the above.

[0030] An "application token" may be an identifier used to control access to a resource or location. The application token may, for example, be an e-ticket. As another example, an application token may be associated with a loyalty program (eg, a loyalty credit). In some embodiments, the application token format may include some indication that may be used by the receiving entity to identify the received information as an application token. In some embodiments, the token format may also allow the receiving entity to identify the issuer associated with the application token. For example, the token format may include a token issuer identifier to identify the issuer of the token.

[0031] A "token issuer", "token provider", "token service computer", or "token service system" may include a system that services tokens. In some embodiments, the token service computer may facilitate the request, definition (eg, generation) and/or issue of tokens, as well as maintaining a defined mapping of tokens to other data in a repository (eg, a token store). In some embodiments, the token service computer may set a token assurance level for a given token to indicate the trust level of the token's pegging. The token service computer may include or communicate with a token store that stores generated tokens. The token service computer may support the processing of transaction tokens submitted using tokens. In some embodiments, the token service system may include a token conversion computer alone or in combination with other computers, such as a computer in a transaction processing network. Various actors in the tokenization environment may assume roles as a token service provider. For example, payment networks and issuers or their agents can become a token service provider by implementing token services according to embodiments of the present invention.

[0032] An "access device" can be any suitable device for communicating with a merchant's computer or a transaction processing network (eg, a payment processing network) and for interacting with a consumer's communication device. The access device may generally be located at any suitable location, such as the location of a merchant. The access device may be in any suitable form. Some examples of access devices include gates, point-of-sale (POS) devices, cell phones, PDAs, personal computers (PCs), tablet personal computers, dedicated hand-held readers, set-top boxes, electronic cash registers (ECRs), automatic cash registers (ATM), virtual cash registers (VCR), kiosks, security systems, access systems, websites, etc. The access device may use any suitable contact or non-contact mode of operation to send or receive data from or associated data to or from the consumer communication device. In some embodiments where the access device may comprise a POS terminal, any suitable POS terminal may be used and may include a reader, a processor, and a computer-readable medium. The reader may include any suitable contact or non-contact mode of operation. For example, to interact with a consumer communications device, exemplary readers may include radio frequency (RF) antennas, optical scanners, barcode readers, or magnetic stripe readers.

[0033] "Issue" may include the process of providing data for use. For example, issuance may include granting, delivering, or making available a token on a communication device. Withdrawal can be performed by any entity within the transaction system or outside of it. For example, in some embodiments, tokens may be issued to a mobile device by an issuer or a transaction processing network. Issued tokens may have corresponding token data stored and maintained in a token store or token registry. In some embodiments, a token store or token registry may generate a token, which may then be issued or delivered to a device. In some embodiments, an issuer may specify a range of tokens from which a token can be generated and issued. Additionally, in some embodiments, the issuer may generate a token value and notify the token store about it and provide token entry information (eg, token attributes) for storage in the token store.

[0034] A "user" may include a person who uses a communication device to conduct a transaction. The user may also be referred to as a consumer or account holder.

[0035] A "key" may refer to an element of information used in a cryptographic algorithm to transform input data into another representation. The cryptographic algorithm may be an encryption algorithm that converts the original data to an alternative representation, or a decryption algorithm that converts the encrypted information back to the original data. Examples of cryptographic algorithms may include advanced encryption standard (AES), data encryption standard (DES), triple data encryption standard/algorithm (TDES), or other suitable algorithms. The key used in the cryptographic algorithm may be of any suitable length (eg, 56 bits, 128 bits, 169 bits, 192 bits, 256 bits, etc.). In some embodiments, a longer key length may provide stronger encryption that is less susceptible to hacking.

[0036] A "digital signature" or "cryptographic signature" may include a type of electronic signature that encrypts documents with digital codes that are particularly difficult to copy. A digital signature may include data used to provide proof or evidence of the origin and identity of an electronic record or message. Digital signatures may be based on public key cryptography (i.e. asymmetric cryptography). Digital signatures may be created using a public key algorithm such as the Rivest-Shamir-Adleman (RSA) algorithm. To create a digital signature, signing software can be used to create a one-way hash of electronic data that must be signed by the signer. The signer's private key is then used to encrypt the hash and generate a digital signature. In other cases, a symmetric key from a symmetric key pair may be used to create a digital signature.

[0037] The term "validation" may include the act of verifying or confirming that information is legitimate. An example would be the act of verifying that a digital signature attached to an electronic record is indeed valid and has been signed by the entity claiming to have created the digital signature. In some embodiments, digital signatures may be validated according to a verification algorithm in combination with the signer's public key. In other cases, if the original data was signed using a symmetric key from a symmetric key pair, the validity of the signature can be verified using the corresponding symmetric key.

[0038] An "Authorization Request Message" may be a message that requests authorization for an interaction, such as a transaction. In some embodiments, the authorization request message may be an electronic message that is sent to the payment processing network and/or the issuer of the ticket, token, payment card, etc. for the purpose of requesting authorization for a transaction. The authorization request message, in some embodiments, may conform to ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a consumer using a payment device or checking account. The authorization request message may include an issuer account identifier, which may be associated with a payment device or settlement account. The authorization request message may also contain additional data elements corresponding to "identity information", including, by way of example only: service code, CVV (card authentication code), dCVV (dynamic card authentication code), expiration date, etc. .d. The authorization request message may also contain "transaction information", such as any information associated with the current transaction, such as transaction amount, merchant ID, merchant location, etc., as well as any other information that can be used in determining whether the transaction should be identified and/or authorized.

[0039] The "Authorization Response Message" may be an email response to an authorization request message. In some embodiments, the authorization response message may be generated by the issuing financial institution, service provider, or payment processing network. The authorization response message may include, by way of example only, one or more of the following status indicators: "approval"—the transaction has been approved; "rejection" - the transaction was not approved; or "call center", a response that requires more information, with the seller having to call a toll-free phone number for authorization. The authorization response message may also include an authorization code, which may be a code that the credit card issuing bank returns in response to an authorization request message in an email (either directly or through a payment processing network) to the merchant's access device ( e.g. POS equipment), which denotes the approval of a transaction. The code can serve as confirmation of authorization. As noted above, in some embodiments, the payment processing network may generate or forward an authorization response message to the merchant.

[0040] "Authorization processing" or "authorization operations" may include at least generating and sending an authorization request message and/or an authorization response message. Authorization processing may further include determining whether to authorize the transaction.

[0041] A "transaction processing system" may include a network of one or more devices that can process and forward transaction request messages. An exemplary transaction processing system may include subsystems, networks, and data processing operations used to support and deliver authorization services, stop list services, transaction evaluation services, and clearing and settlement services. An example of a transaction processing system is VisaNet™. Transaction processing systems such as VisaNet™ can process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, may include a VIP system (Visa Integrated Payments System), which processes authorization requests, and a Base II system, which performs clearing and settlement services.

[0042] "Processor" may refer to any suitable device or devices for computing data. A processor may comprise one or more microprocessors working together to perform a desired function. The processor may include a CPU that includes at least one high speed data processor suitable for executing software components to execute user and/or system generated requests. The CPU may be a microprocessor such as an Athlon, Duron and/or Opteron from AMD; PowerPC from IBM and/or Motorola; Cell architecture processor from IBM and Sony; Celeron, Itanium, Pentium, Xeon and/or XScale from Intel; and/or similar processor(s).

[0043] "Memory" can be any suitable device or devices that can store electronic data. Suitable memory may include a permanent computer-readable medium that stores instructions that can be executed by the processor to implement the desired method. Examples of memory elements may include one or more memory chips, disk drives, and so on. Such memory elements may be operated in any suitable electrical, optical and/or magnetic mode of operation.

[0044] FIG. 1 shows a communications device 110 in communication with a set of service provider computers 112-116 and an account management server 118, in accordance with some embodiments. The service provider computers shown in FIG. 1 include service provider computer A 112, service provider computer B 114, and service provider computer C 116.

[0045] The service provider computers 112-116 may correspond to different service providers or service provider agents. As an example, service providers may facilitate access to a place or event. Examples of service providers include a travel agency (for example, providing rail or bus services), an airline, and a movie theater. Service provider agents can facilitate access to resources on behalf of several different service providers (for example, a website that sells tickets from different airlines, or a ticketing agency).

[0046] Each of the computers (112-116) of the service provider is associated with a corresponding application (102-106) of the service provider. The service provider A 112 is associated with the service provider application A 102 . The service provider's computer B 114 is associated with the service provider's application B 104. The service provider computer C 116 is associated with the service provider application C 106 . Service provider applications 102-106 may be used to control access to a resource. For example, a user may interact with a service provider's application to purchase a ticket for a trip.

[0047] As shown in FIG. 1, the service provider applications 102-106 are in communication with the account management application 108. The account management application 108 may be used to centrally manage data to facilitate resource access through the service provider applications 102-106. For example, the account management application 108 may be a digital wallet and may store digital currency, tickets, and the like. through a set of service provider applications.

[0048] Each service provider application 102-106 may use different formats, data, and data structures. In order for the service provider applications 102-106 to use the features of the account management application 108, each service provider application must be integrated into the account management application 108, and the account management application 108 must be able to process the data provided by each provider application 102-106. services.

[0049] Referring to FIG. 2A, there are several account management application providers. Different communication devices/users may choose different applications for account management. For example, communication devices from different manufacturers may be compatible with different respective proprietary account management applications. As another example, the user may select one or more preferred account management applications to install on the communication device.

[0050] As shown in FIG. 2A, each of the three different communication devices, communication device A 210, communication device B 220, and communication device C 230, is equipped with a different respective account management application. Communications device A 210 contains application A 212 for account management. The communication device B 220 contains an application B 222 for account management. Communications device C 230 contains application C 232 for account management.

[0051] Each account management application (account management application A 212, account management application B 222, and account management application C 232) is configured to store data associated with different service providers. Account management applications 212, 222, 232 are communicatively connected to service provider computer A 240, service provider B 250, service provider C 260, and service provider D 270. Account management applications 212, 222, 232 may require interaction with any given service provider computer to facilitate service delivery.

[0052] As a specific example, the user uses a communication device A 210 that is equipped with a particular electronic wallet, application A 212 for account management. The user frequently travels by train and purchases train tickets from several different service providers. In order to use the e-wallet to manage all of these train tickets, the account management application A includes programs configured to interact with various service provider computers. The service provider's computer A is managed by the local light rail service. The service provider's computer B 250 is under the control of the intercity train service. The service provider's computer C 260 is managed by the travel agency. The provider's computer D 270 is controlled by a travel aggregator service that allows users to compare prices from different providers. The user buys tickets from each of these providers at different times. Accordingly, the account management application A includes code configured to interact with each service provider computer (A 240, B 250, C 260, and D 270) to receive tickets in various formats provided by the respective service provider computers and perform communication with the relevant computers of the service provider to confirm the validity and redemption of tickets. Similarly, service providers must integrate with various account management applications. For example, communication device B has a different wallet installed than communication device A (account management application B 222 instead of account management application A 212), and communication device C has another electronic wallet installed (account management application C 232). Each service provider's computer must have the functionality to interact with and understand each of these account management applications.

[0053] FIG. 2B shows a system 200B with a token service computer 282 (eg, managed by a token service provider) that facilitates integration of multiple account management applications and service provider computers, according to embodiments. System 200B includes communication device A 216, communication device B 226, communication device C 236, token service computer 282, service provider computer A 242, service provider B 252, service provider C 262, and service provider computer D 272.

[0054] Each of the communication devices contains a corresponding account management application. Communications device A 216 contains application A 218 for account management. Communication device B 226 contains application B 228 for account management. Communications device C 236 contains application C 238 for account management.

[0055] In contrast to the system shown in FIG. 2A in the system of FIG. 2B, by means of the token service computer 282, the account management applications 218, 228, 238 can communicate through a single interface, the token service computer 282, rather than adapt to different service provider computers 242, 252, 262, 272. Similarly, the service provider computers 242, 252, 262, 272 may communicate with the token service computer 282. Accordingly, the use of the token service computer facilitates communication between the parties.

[0056] FIG. 3 shows an overview of the interaction between communication device 360, token service computer 330, service provider website 320, access device 350, and service provider computer 340, according to some embodiments. The service provider's computer 340, access device 350, and service provider's website 320 may be associated with a service provider, such as a public transportation provider, a concert hall, a travel agency, a ticketing agency, or the like. For example, the service provider's computer 340 is a server computer associated with US Railroads. The service provider's website 320 is the US Railroads public website. The access device 360 is a gate access terminal for accessing a particular platform of a railroad station operated by US Railroads. Communication device 360 may be, for example, a mobile phone with near proximity capability. The communications device 360 includes a service provider application A 362 (which corresponds to US Railroads) and a service provider application B 364 (which corresponds to another service provider).

[0057] First, the user interacts with the communications device 360 to purchase a US Rail pass. The user may purchase a ticket through the application A 362 of the service provider and/or through the website 320 of the service provider.

[0058] In step S1, the application of the communication device 360 may transmit the ticket purchase information to the service provider's website 320 in case the user purchases the ticket through the application 362. Alternatively, the user may directly interact with the service provider's website 320 through a browser on the device 360 communications. In step S2, the service provider's website 320 transmits the ticket purchase information to the service provider's computer 340.

[0059] In step S4, the service provider's computer 340 processes the ticket purchase, which may include coordinating with external transaction processing systems and/or issuers to confirm purchase details and debit the account. The service provider computer 340 may issue an application token 366 representing the ticket and store a record of the application token 366 .

[0060] In step S5, the service provider computer 340 may initiate execution by the token service computer 330. The service provider computer 340 may send application token 366 information to the token service computer 330 .

[0061] In step S6, the token service computer 330 may prepare a token container 367 associated with the application token 366. In some embodiments, the token service computer 330 generates a token container 367 for issuance to the communication device 360 . The token service computer 330 may receive an application token 366 received from the service provider computer 340 . The token service computer 330 may place an application token in a token container. The token service computer 330 may generate and store a container identifier (ID) 342 in association with the token container 367 . The container ID 342 may be, for example, a sixteen-digit number, a name, or the like that characterizes the token container 367 . The container ID 342 may be stored in the token service computer 330 and/or the service provider 340 . The token service computer 330 may further set and store the token state 344 associated with the application token 366 . The state 344 of the token may correspond to the state of the application token. Examples of token states 344 include: newly generated, redeemed, and value added.

[0062] In step S7, the token service computer 330 may issue a token container 367 and/or an application token 366 to the communication device 360 . The token service computer 330 transmits the token container 367 and the application token 366 to the communication device 360 via any suitable form of wireless or wired communication.

[0063] Communication device 360 stores a token container 367, which in turn stores application tokens 366. Application tokens are associated with access to different locations or resources. For example, one app token corresponds to a California Airlines flight ticket on July 3, 2019, another app token corresponds to a train ticket for a US Rail travel on July 4, 2019, and a third app token corresponds to a concert ticket to a particular concert. Application tokens associated with different service providers can be stored in one token container 367 . Alternatively, multiple token containers may be issued, eg, one per service provider or per service provider application.

[0064] In step S8, communication device 360 interacts with access device 350 to gain access to a location or resource. In this particular example, the user puts their shortwave enabled phone to the gate to access the train platform. Communication device 360 transmits application tokens 366 to access device 350 .

[0065] In step S9, the access device 350 checks the headers of the application tokens 366 and identifies an application token 366 that corresponds to "US Rail". The access device 350 transmits a signal causing the gate to open and allowing the user access to the railway platform. The access device 350 may send an acknowledgment back to the communication device 360 causing the communication device 360 to mark the US Rail travel application token 366 as used.

[0066] In step S10, the access device 350 transmits information to the computer 340 of the service provider. The information transmitted indicates that the US Rail travel app token has been redeemed.

[0067] In step S11, the service provider computer 340 updates its record database to indicate that the application token has been redeemed. Updating the records may include changing the saved state 344 of the token associated with the redeemed application token 366 .

[0068] FIG. 4A shows a block diagram of a communication device 401 according to some embodiments. Communications device 401 may include device hardware 404 coupled to memory 402. Device hardware 404 may include processor 405, communications subsystem 409, user interface 406, and display 407 (which may be part of user interface 406).

[0069] The processor 405 may be implemented as one or more integrated circuits (eg, one or more microprocessors and/or microcontrollers with a single core or multiple cores) and is used to control the operation of the portable communication device 401. The processor 405 may execute a plurality of programs in response to the program code or computer readable code stored in the memory 402 and may support multiple concurrently executing programs or processes.

[0070]The communications subsystem 409 may include one or more transceivers and/or connectors that may be used by the communications device 401 to communicate with other devices and/or to connect to external networks such as the Internet. In some embodiments, communication subsystem 409 may further include a contactless element, which is typically implemented as a semiconductor chip (or other data storage element) with an associated wireless (eg, data) element, such as an antenna. The contactless element may be connected to (eg, built into) the communication device 401 and data or control commands that are transmitted over the cellular network may be applied to the contactless element via a contactless element interface (not shown). The contactless element may be capable of transmitting and receiving data using a near field wireless communication capability. Communications subsystem 409 may contain components for both a polling device (eg, receiving data) and a polling device (eg, sending data). Therefore, the communication device 401 may be able to communicate and transmit data or control commands both over a cellular network (or any other suitable wireless network, such as the Internet or other data network), and through short-range communications. Communications device 401 may also include an antenna for wireless communication (eg, data communication).

[0071] The user interface 406 may include any combination of input and output elements to enable the user to interact with the communication device 401 and use its functionality. In some embodiments, the display 407 may be part of the user interface 406. The display 407 and user interface 406 may allow the user to see information and messages. The communication device may further include input elements to allow a user to enter information into the device, a speaker to allow the user to listen to voice communications, music, etc., and a microphone to allow the user to transmit their voice through the communication device 401.

[0072] Memory 402 may be implemented using any combination of any number of non-volatile memory elements (eg, flash memory) and volatile memory elements (eg, DRAM, SRAM) or any other persistent storage media, or a combination of the above media. Memory 402 may store a mobile operating system 420 and an application environment 410 that contains one or more applications to be executed by processor 405.

[0073] Application environment 410 may include applications that are used to manage application tokens. In some embodiments, the applications may include service provider application A 412, service provider application B 414, and account management application 416.

[0074] Applications (A 412 and B 414) of the service provider may contain functionality for providing access to services or other resources. Examples of service provider applications include ticketing and purchasing applications, public transportation applications, and vendor applications. The service provider's applications may be communicatively linked to respective service provider's computers to perform end functions such as selling or redeeming tickets.

[0075] An account management application 416 may include functionality for managing one or more accounts. Examples of account management applications 416 include mobile or digital wallet applications, issuer applications, and banking applications. The account management application 416 may provide a single application for storing and managing functions associated with service provider application A 412 and service provider application B 414.

[0076] Memory 402 may include code executable by processor 405 for implementing a method comprising: providing an application of a first service provider on a communication device to a computer of a first service provider of a first request for a first application token; receiving by the application for managing the account on the communication device from the service computer of the tokens in communication with the computer of the first service provider, the first application token; and storing the first application token in the token container in the account management application.

[0077] FIG. 4B shows a detailed view of an account management application 416 according to some embodiments. The account management application 416 may store application tokens 417-1-417-n and token states 418-1-418-n. The account management application 416 can securely store application tokens 417-1-417-n and token states 418-1-418-n, for example, using cryptography and/or a secure hardware element.

[0078]In some embodiments application tokens 417-1-417-n are electronic tickets associated with purchased services or goods. When a user receives multiple services or goods from a service provider, the services or goods may be further associated with application-specific tokens. For example, when obtaining travel tickets for a route consisting of several stages, each ticket can be issued as a digital ticket and represented by an application token. Alternatively or additionally, application tokens may represent loyalty data (eg, reward points for loyal customers). Each application token 417-1-417-n may also have its own corresponding token state 418-1-418-n. Each token state can represent one or more token attributes of the corresponding application token. Continuing with the transportation system example above, each token state can represent attributes such as whether or not a ticket has been used for that leg of the journey.

[0079] Communication device 401 may store issued application tokens 417-1-417-n and associated token states 418-1-418-n in a digital container accessible by account management application 416. The issued application tokens 417-1-417-n can be used to access a product or service of the associated service provider. For example, the issued application token can be provided from the communication device 401 to the access device at the gate to gain access to the transportation system. When the application token is consumed, the service provider may update the token state for the application token on the communication device 401 . For example, when the ticket is used, the service provider may change the token state for the token representing the ticket from an unused state to a used state. In some embodiments, the service provider may update the state of the token on the communication device 401 by sending a state update request to the token service computer (e.g., as shown in FIG. 6), and the token service computer may update its own token state and synchronize the update with the device. 401 connections.

[0080] The account management application 416 may further store logs of when and where interactions occur that are associated with application tokens. Therefore, the validity of the application token can be confirmed upon redemption.

[0081] FIG. 5 shows a block diagram of a service provider computer 501 according to some embodiments. The service provider computer 501 includes a network interface 502, a processor 504, a memory 506, and a computer-readable medium 508.

[0082] Processor 504 may be implemented as one or more integrated circuits (eg, one or more single or multi-core microprocessors and/or microcontrollers). The processor 504 may be used to control the operation of the computer 501 of the service provider. The processor 504 may execute a plurality of programs in response to the program code or computer readable code stored in the memory 506. The processor 504 may include functionality to support a plurality of concurrently executing programs or processes.

[0083] The network interface 502 may be configured to connect to one or more communication networks to allow the service provider computer 501 to communicate with other entities such as a resource provider computer, transport computers, a routing management interface, and so on. For example, communication with transport computers may be direct, indirect, and/or through an application programming interface (API).

[0084] Memory 506 may be implemented using any combination of any number of non-volatile memory elements (eg, flash memory) and volatile memory elements (eg, DRAM, SRAM) or any other persistent storage medium or combination of storage media.

[0085] Computer-readable media 508 may include one or more persistent media for storage and/or transmission. Suitable media include, for example, random access memory (RAM), read only memory (ROM), magnetic media such as a hard disk or floppy disk, or optical media such as a compact disc (CD) or DVD (digital versatile disk) , flash memory, etc. Computer readable medium 208 may be any combination of such storage or transmission devices.

[0086] The computer-readable medium 508 may comprise program code stored as a sequence of instructions or commands. Computer readable medium 508 contains code executable by processor 504 for implementing the methods described herein. The computer-readable medium 508 may include a communication module 510, an encryption module 512, an emitter module 514, and a validation module 516. Each of these modules may include code configured to perform the functions described below in conjunction with processor 504.

[0087] Communications module 510 may contain code that causes processor 504 to generate messages, route messages, reformat messages, and/or otherwise communicate with other entities.

[0088] In embodiments of the present invention, encryption module 512 may include any suitable encryption algorithms for encrypting data. Suitable data encryption algorithms may include DES, triple DES, AES, etc. Encryption module 512 may also store encryption keys that can be used with such encryption algorithms. Other keys of any relevant key pairs may be stored in the encryption module 612 in the token service computer 601 . Encryption module 512 may use symmetric or asymmetric encryption approaches to encrypt and/or verify data. The token service computer and the service provider computer 501 may have (store) the respective cryptographic keys of the cryptographic key pair.

[0089] Issuing module 514 may contain code that causes processor 504 to generate an application token. The issuing module can receive requested details such as trip, event, or item data. The issuing module can generate an application token corresponding to the requested details. The issuing module may further comprise code for processing payment data to process account information for purchasing an application token (which may be performed in cooperation with one or more external payment processing networks and/or banks).

[0090] Validation module 516 may contain code that causes processor 504 to validate the application token. App token validation may include one or more of: verifying stored records of the app token, verifying the digital signature of the app token, and/or processing received verification data. The validation module may further comprise code that causes the processor 504 to update the state of the token associated with the application (eg, by marking the application token as used, expired, etc.).

[0091] FIG. 6 shows a block diagram of a token service computer 601 according to some embodiments. The token service computer 601 includes a network interface 602, a processor 604, a memory 606, and a computer-readable medium 608.

[0092] Processor 604 may be implemented as one or more integrated circuits (eg, one or more single or multi-core microprocessors and/or microcontrollers). The processor 604 may be used to control the operation of the token service computer 601. Processor 604 may execute a plurality of programs in response to program code or computer readable code stored in memory 606. Processor 604 may include functionality to support multiple concurrently executing programs or processes.

[0093] The network interface 602 may be configured to connect to one or more communication networks to allow the gateway server 600 to communicate with other entities such as a resource provider computer, transport computers, a routing management interface, and so on. For example, communication with transport computers may be direct, indirect, and/or via an API.

[0094] Memory 606 may be implemented using any combination of any number of non-volatile memory elements (eg, flash memory) and volatile memory elements (eg, DRAM, SRAM), or any other persistent storage medium, or combination of media.

[0095] Computer-readable media 608 may include one or more persistent media for storage and/or transmission. Suitable media include, for example, random access memory (RAM), read only memory (ROM), magnetic media such as a hard disk or floppy disk, or optical media such as a compact disc (CD) or DVD (digital versatile disk) , flash memory, etc. The computer-readable medium 608 may be any combination of such storage or transmission devices.

[0096] The computer-readable medium 608 may comprise program code stored as a sequence of instructions or instructions. Computer readable medium 608 contains code executable by processor 604 for implementing the methods described herein. The computer-readable medium 608 may include a communication module 610, an encryption module 612, an issue module 614, and an update module 616. Each of these modules may include code configured to perform the functions described below in conjunction with processor 604.

[0097] Communication module 610 may contain code that causes processor 504 to generate messages, route messages, reformat messages, and/or otherwise communicate with other entities.

[0098] In embodiments of the present invention, encryption module 612 may include any suitable encryption algorithms for encrypting data. Suitable data encryption algorithms may include DES, triple DES, AES, etc. Encryption module 612 may also store encryption keys that can be used with such encryption algorithms. Other keys of any relevant key pairs may be stored in the encryption module 512 in the computer 501 of the service provider. Encryption module 612 may use symmetric or asymmetric encryption approaches to encrypt and/or verify data. The token service computer 601 and the service provider computer 501 may have (store) the respective cryptographic keys of the cryptographic key pair.

[0099] Issuance module 614 may contain code that causes processor 604 to generate a token container. The issuing module may, for example, include code configured to generate a token container for a particular communications device and/or application token.

[0100] Update module 616 may contain code for updating the token container and/or application token. The update module may include code configured to add application token(s) to the token container. The update module 516 may include code configured to update the state of the token associated with the application token (eg, by marking the application token as used, adding a value, adding a stage to a journey, updating loyalty data, etc.).

[0101]In some embodiments the token service computer may include a token store (not shown). As an example, a token store can store application tokens. Each application token may also be stored in association with its own corresponding token state (as described above with respect to FIG. 4). Application tokens and corresponding token states may be stored in a token store and issued to a communications device (eg, as illustrated and described with reference to FIG. 4). When an app token is redeemed (for example, for a trip, access to an event, or the like), the token state for the app token can be updated in the token store.

[0102] In FIG. 7 shows a process 700 for issuing an application token according to some embodiments. The communications device 750 may have an account management application 754 installed thereon, such as a mobile wallet application, and a service provider application 752, such as a merchant application or a travel application, associated with the service provider's computer 760. The application token issuance process 700 may be the primary process for issuing application tokens to the communications device 750 .

[0103] Initially, the user may interact with the communication device 750 to purchase an application token. The user may select an application token to purchase, for example, through the service provider's application 752 and/or a web browser that links to the service provider's website. As another example, a user may purchase an application token through a kiosk, such as a subway station or airport. The service provider application 752 can determine if the application token and/or token container exists on the communication device 750. The service provider application 752 may, for example, send a query to the account management application 754 to determine if account tokens have previously been issued and/or whether the token container is currently stored in the account management application 754 or elsewhere on the device 750 connections. Alternatively, or additionally, the service provider application 752 may search for records stored in the service provider application 752 and/or the service provider's computer 760.

[0104] In step S702, the service provider's application 752 may send a request for an application token to the service provider's computer 760. The request may include details related to the application token (for example, one ticket for a train ride from Amsterdam to Munich). The request may include payment information, such as an account number that will be used to pay for the application token. In some embodiments, the request may further include an indication that this is the first request for an application token. The request may be transmitted over a wired or wireless connection between the communications device 750 and the service provider's computer 760. The service provider computer 760 may receive a request from the service provider application 752 for an application token.

[0105] In step S704, the service provider's computer 760 may verify the user, communication device 750, and/or payment information and generate an application token. The application token may, for example, be generated in the form of a digital ticket. The application token may include permission access information (eg, one train ride, entry to a specific concert, access to a specific building, etc.). The application token may include information characterizing the service provider (eg, the application token may include a header indicating that the service provider is "Travel Corp."). The application token may have a format and/or size specific to the service provider. As examples, one service provider may store the application token as a file type different from other service providers, and different service providers may set different fields to store different types of information (for example, one may store the date, time, service provider ID as the first three header fields, while another service provider may store the location, amount, token ID as the first three header fields).

[0106] The service provider computer 760 may package the generated application token into an encrypted payload (eg, a JavaScript Object Notation (JSON) web encryption payload). In some embodiments, the service provider computer 760 may store one encryption key (eg, short-lived Elliptic Curve Cryptography (ECC) public key) and the token service computer 770 may store another corresponding encryption key. The service provider computer 760 may encrypt the application token. The service provider computer 760 may generate an encrypted payload, including at least an encrypted application token.

[0107] In step S706, the service provider computer 760 transmits the encrypted payload to the service provider application 752 installed on the communication device 750. The service provider application 752 receives the encrypted payload.

[0108] In step S708, the service provider application 752 transmits the encrypted payload to the account management application 754. The account management application may not be able to decrypt/view the contents of the encrypted packet at this time.

[0109] In step S710, the account management application 254 may send a issuance request to the token service computer 770. The account management application 254 may further request from the token service computer 770 registration for the user and/or communication device.

[0110] The token service computer 770 may decrypt the encrypted payload upon receipt. Token service computer 770 and service provider computer 760 may share symmetric encryption keys that allow them to encrypt and decrypt application tokens, or parts thereof. In other embodiments, token service computer 770 and service provider computer 760 may respectively use a public key to encrypt the application token portion and a private key to decrypt the application token portion.

[0111] In some embodiments, the token service computer 770 may determine that a token container should be generated for the application token. The token service computer may receive an indication that a token container is required in the received registration and issuance request based on information provided by the service provider application 752 and/or the account management application 754. Alternatively or additionally, the token service computer 770 may determine that a token container is required based on viewing stored data associated with the communication device 750 and/or the account management application 754.

[0112] The token service computer 770 may perform operations to register a user and/or communication device with the token service. The registration may include, for example, the issuance of cryptographic keys or passwords.

[0113] The token service computer 770 generates a token container. The token service computer may generate a token container that may store a plurality of application tokens. As an example, a token container may be capable of storing at least 100 twenty-byte application tokens. The length of application tokens can be specific to different service providers. The token container may be generated to include a token container entry associated with the application token. For example, a token container entry might have the following format: follow data length (1 byte), program ID (4 bytes), time interval in minutes (2 bytes), and application token (1-250 bytes). The token container may be associated with an identifier (eg, such as a sixteen-digit number unique to the token container). The token container may also be specifically formatted for the service provider 750, and other token containers for other service providers may be formatted the same way or differently.

[0114] The token service computer 770 may further perform operations to change the application token. The token service computer 770 may cryptographically sign the application token using the key of the token service computer 770. The token service computer 770 may further modify the application token for use by the application 754 for account management. The token service computer 770 may, for example, convert an application token from a first format to a second format. Alternatively or additionally, the token service computer 770 may add or modify header information associated with the application token.

[0115] In step S712, the token service computer 770 may issue an application token to the account management application 754. The token service computer 770 may pass the application token to the account management application. The token service computer 770 may send a token container with an application token (eg, the application token is stored in the token container). The account management application can accept and store an application token in a token container in the account management application. The application token, or additional data associated with the application token, may include a container identifier that may identify the token container in which the application token will be stored.

[0116] In some embodiments, the token service computer 770 may send a notification to the service provider computer 760 indicating that an application token has been issued to the communication device 750.

[0117] In FIG. 8 shows another process 800 for issuing an application token, according to some embodiments. The communication device 850 may have an account management application 854 installed thereon, such as a mobile wallet application. The communication device 850 further comprises a service provider application A 852 and a service provider application B 856. The application token issuance process 800 may be the next issuance event after the first issuance (eg, as described above with respect to FIG. 7).

[0118] Initially, the user may interact with the communication device 850 to purchase an application token. The user may select an application token to purchase, for example, through the service provider's application 852 and/or a web browser that links to the service provider's website. The service provider application A can determine if the application token and/or token container exists on the communication device 850. The service provider application A 852 may, for example, send a query to the account management application 854 to determine if application tokens have previously been issued and/or whether a token container is currently stored in the account management application 854. Alternatively, or additionally, service provider application A 852 may search for records stored in service provider application A 852 and/or service provider computer A 860.

[0119] In step S802, the service provider's application A 852 may send a request for an application token to the service provider's computer A 860. The request may include information related to the application token (for example, one ticket for a train ride from Munich to Prague). The request may include payment information, such as an account number that will be used to pay for the application token. In some embodiments, the request may further include an indication that this is the next application token request. The request may be transmitted over a wired or wireless connection between the communications device 850 and the service provider's computer A 860.

[0120] In step S804, the service provider's computer A 860 may verify the user, communication device 850, and/or payment information and generate an application token. The application token A may, for example, be generated in the form of a digital ticket. Application token A may include permission access information (eg, one train ride, entry to a certain concert, access to a certain building, etc.). The application token A may include information characterizing the service provider A (eg, the application token may include a header indicating that the service provider A is the Portland Metropolitan Transportation Authority). Application token A may have a format and/or size specific to service provider A.

[0121] In step S806, the service provider computer A 860 transmits the application token information to the token service computer 870. Service provider computer A 860 may send token service computer 870 information about that particular application token (eg, a particular trip or event). The service provider computer A 860 may optionally transmit information about a previously issued token container (eg, a token container ID).

[0122] The token service computer 870 receives the application token information and prepares the application token information for transmission to the account management application 854. In some embodiments, the token service computer 870 performs operations to change the application token so that it can be used by the application 854 for account management. The token service computer 870 may, for example, convert an application token from a first format to a second format. Alternatively or additionally, the token service computer 870 may add or modify header information associated with the application token. The token service computer 870 may further cryptographically sign the application token using the key of the token service computer 870.

[0123] In step S808, the token service computer 870 transmits the application token (application token A) to the account management application 854. The token service computer 870 may send application token A with information indicating that application token A should be stored in a token container with a specific identifier (eg, 123459789). The account management application 854 may receive and store the application token A in a token container in the account management application 854.

[0124] In some embodiments, token service computer 870 may send a notification to service provider computer A 860 indicating that application token A has been issued to communication device 850.

[0125] Subsequently, the user may interact with the application associated with another service provider, service provider B, to purchase a second application token. For example, app token A could be for a first leg of a rail trip purchased from a first rail operator, and app token B could be for a second leg of a rail trip purchased from a second rail operator. As another example, Application Token A could be a Transylvania Airlines ticket purchased from the Transylvania Airlines application. Subsequently, the user may purchase another Transylvania Airlines ticket through the ticket aggregator application. The user can initiate the purchase of application token B through the application B 856 of the service provider. Alternatively, or additionally, the user may initiate the purchase of an application token through the service provider's website (eg, through a web browser application on communication device 850).

[0126] In step S812, the service provider's application B 856 may send a request for an application token to the service provider's computer B 880. The request may include information related to the application token. The request may include payment information, such as an account number that will be used to pay for the application token. In some embodiments, the request may further include an indication that this is the next application token request. The request may be transmitted over a wired or wireless connection between the communications device 850 and the service provider's computer B 880.

[0127] In step S804, the service provider's computer B 860 may verify the user, communication device 850, and/or payment information and generate an application token B. Application token B may, for example, be generated in the form of a digital ticket. Application token B may include permission access information (eg, one train ride, entry to a certain concert, access to a certain building, etc.). Application token B may include information characterizing service provider B (eg, application token B may include a header indicating that the service provider is "Travel Corp."). Application token B may have a format and/or size specific to service provider B. In some embodiments, issuing and/or verifying an application token may include exchanging data with another service provider. For example, if service provider B is a ticketing application and service provider A is a concert venue, service provider B may negotiate a ticket purchase from the concert venue/service provider A before issuing application token B.

[0128] In step S816, the service provider computer B 880 transmits the application token information to the token service computer 870. The service provider computer B 880 may send to the token service computer 870 information about that particular application token (eg, a particular trip or event). The service provider computer B 880 may further transmit information about the previously issued token container (eg, token container ID).

[0129] The token service computer 870 receives the application token information and prepares the application token information for transmission to the account management application 854. In some embodiments, the token service computer 870 performs operations to change the application token so that it can be used by the application 854 for account management. The token service computer 870 may, for example, convert an application token from a first format to a second format. Alternatively or additionally, the token service computer 870 may add or modify header information associated with the application token. The token service computer 870 may further cryptographically sign the application token using the key of the token service computer 870.

[0130] In step S818, the token service computer 870 transmits the application token (application token B) to the account management application 854. The token service computer 870 may send application token B with information indicating that application token B should be stored in a token container with a specific identifier (eg, 123459789). The account management application 854 may receive and store an application token in a token container in the account management application.

[0131] In some embodiments, token service computer 870 may send a notification to service provider computer B 880 indicating that application token B has been issued to communication device 850.

[0132] FIG. 9 shows an application token redemption process according to some embodiments. The user can redeem the application token (which is issued as described above with respect to FIGS. 7 and/or 8) using the communication device 950. The communication device may communicate with the access device 960 to redeem the application token, and the access device 960 may communicate with the service provider computer 970 on the server side. Access device 960 may, for example, be a ticket scanner at a travel agency or at an event location. As another example, access device 960 may be a POS device. As shown in FIG. 9, the account management application 952 is used to redeem the application token. In other embodiments, the application token may be redeemed through the service provider's application.

[0133] In step S901, the account management application 952 interacts with the access device 960 to redeem the application token. The interaction may include, for example, the user touching the communication device 950 to the access device. The account management application 952 may initiate a communication session with the access device. The communication session may be via short-range proximity communication (eg, using the EMV proximity communication standard). Alternatively or additionally, the account management application 952 may communicate with the access device 960 via any suitable wired or wireless form of communication. Based on the interaction, the account management application may send to the access device 960 an authorization request for the application token.

[0134] The account management application 952 may transfer all or part of the stored application tokens to the access device 960. In some embodiments, the user may initially select an appropriate application token (eg, by selecting one of multiple tickets displayed through the account management application 952). The account management application 952 may then push the selected application token to the access device 960 . Alternatively, the account management application may identify one or more suitable application tokens to push to the access device 960 . For example, the access device transmits the identifier of the access device to the application 952 for account management. The access device ID indicates that the access device is managed by "Super Tix". Accordingly, the account management application 952 identifies the four application tokens that are identified as associated with "Super Tix" and sends the four identified application tokens to the access device. As another example, the account management application 952 may transfer the entire token container and all application tokens within it to the access device 960 .

[0135] In some embodiments, the account management application 952 and/or access device may further process event and/or device dependent data for use in validating current and/or future redemptions. For example, access device 960 may provide one or more of a timestamp, a program identifier, a location name, and/or a terminal identifier to an account management application. The account management application 952 may optionally generate a timestamp for comparison with the received timestamp.

[0136] In some embodiments, account management application 952 may retrieve a cryptographic key (eg, private key) stored on communication device 950 and may then use the retrieved key to sign event-specific and/or device-specific data. This can be used later by the service provider computer 970 to verify that the communication device 950 was the source of the request. In some embodiments, the verification may be performed by the service provider's computer 970 using a public key associated with the private key with which the event and/or device dependent data is signed. For example, in some embodiments, the event dependent data may be a nonce object, and the nonce object may be signed with a private key residing in a security element on communication device 950. The account management application 952 may generate a nonce object and may extract the private key from the secure element on the communication device 950 in order to sign it. The signed nonce may then be provided to the service provider computer 970 alone or with the nonce. This will allow the service provider computer 970 to confirm that the account management application 952 and the access device 960 have communicated via the communication device and that the redemption request is from the correct account management application.

[0137] In step S902, the access device 960 receives and parses one or more application tokens. In the event that access device 960 accepts multiple application tokens, access device 960 may identify an application token to redeem. The access device 960 can identify the access token for redemption based on a comparison of the parameters associated with the access device with the application token data. For example, the access device may be located in London. If there are four train tickets in account management application 952, and one of the train tickets is associated with a London origin, then access device 960 can use the application token details to identify and select an application token associated with a London origin for repayment.

[0138] In some embodiments, access device 960 validates the application token offline. The application token could be cryptographically signed by the token service computer that issued the application token. Access device 960 may have stored the cryptographic key of the token service computer that issued the application token. The access device 960 can use the stored cryptographic key and the predetermined algorithm to validate the cryptographic signature of the token service computer, thereby verifying the validity of the application token without having to send requests to other computers. This is especially useful in situations where you need to quickly verify the validity of an application token, or when you are not connected to the Internet. For example, at a transit toll gate, it is desirable to quickly check the validity of a ticket so that a user can quickly pass through it. Alternatively, or additionally, access device 960 may validate the application token using device data and/or events, as described below with respect to step S906. Alternatively, or additionally, the access device 960 may send a request for validation by the service provider's computer 970.

[0139] In some embodiments, at step S904, the access device 960 sends an application token authorization request to the service provider's computer 970. Access device 960 may send an application token authorization request as received. Alternatively, access device 960 may modify the application token authorization request before it is sent to service provider computer 970 (eg, by selecting one from a set of accepted application tokens, changing the state of the token, and/or the like). If the access device 906 has already validated the application token authorization request, then the access device 906 may include data indicating that the request has been validated.

[0140] In step S906, the service provider computer 970 receives and processes the application token authorization request. The service provider computer 970 may validate the received application token authorization request. In some embodiments, the access device 960 may have already validated the application token request, in which case the service provider computer 970 may validate or flag the validation. Alternatively, the service provider computer 970 may independently validate the application token. The service provider's computer may, for example, validate the digital signature of the application token. As another example, the service provider computer 970 may compare the received application token with the stored application tokens to perform validation. After validating the application token, the service provider computer 970 can change the stored state of the token to mark the application token as redeemed.

[0141] In addition, the previously described device and/or event dependent signed data can also be verified by the service provider's computer 970. Device and/or event dependent data may be obtained from access device 960 and/or communication device 950. For example, in some embodiments, as mentioned above, device and/or event dependent data may be signed with an encryption key in a security element in communication device 950. The resulting digital signature can be verified by the service provider's computer 970 using the appropriate encryption key (eg, public key) to ensure that the correct communication device 950 is requesting redemption of the application token.

[0142] In step S908, the service provider computer 970 transmits an application token authorization response to the access device 960 . The response may indicate whether the application token is valid. In some embodiments, step S908 may be omitted. For example, if the access device validated the application token offline, the access device may not need to receive additional validation information from the service provider's computer 970.

[0143] In step S910, the access device 960 sends a response to the account management application 952. In some embodiments, the access device 960 may transmit a response within the same near-proximity session in which the request was received. The response may indicate whether the request has been validated (eg, permission to access a location or resource should be granted) or not validated (eg, access should be denied). In the event that the validity of the request/application token has been validated, the access device may allow such access (eg, by opening a gate or transmitting a notification to an operator (eg, someone controlling entry to the location). Step 910 may occur before steps 904-908 in if the access device has performed offline validation Alternatively, the access device 960 may perform step 910 after steps 904-908 if the service provider computer 970 has validated the application token.

[0144] In step S912, the account management application 952 may update the state of the token associated with the application token. In some embodiments, the account management application may immediately update the state of the token by marking the application token as "used" after sending the request to S901. Alternatively or additionally, the account management application 952 may update the state of the token based on the information received in the response in step S910.

Transport environment

[0145] In some embodiments, an enhanced tokenization system may be used in the transport environment. Transportation media may include the sale and purchase of tickets for public transport and long-distance travel. The sale and purchase of tickets for public transport is characterized by the fact that ticket prices do not change, customer service is carried out as they appear, the tariff is calculated upon the fact of the service, and is usually associated with urban agglomerations with technical means at the entrance / exit. Public transport ticket sales and purchases can use offline data authentication, and contactless cards and mobile wallets can be used, with low slowdown rates and high customer satisfaction. For long-distance travel, consumers may want guaranteed seats (eg, prepaid bookings), fares may fluctuate (eg, early bookings may reduce fares), and tickets may cost more than public transport tickets. Fare calculation can also be complex and may take into account whether it is a single or return trip, season pass, group discount, etc. Stations may also not be gated and may require ticket checks.

[0146] The purchase and display of tickets can be handled by a ticketing and purchasing application associated with the service provider or application. In some embodiments, only some selected trips may correspond to digital tickets and be processed by the tokenization system. The ticketing and purchasing application can indicate which trips qualify. A ticketing application can create a digital ticket container (token container) by push issuance (if one does not already exist) and inform the transport backend service system to push the tickets (e.g. in the form of application tokens and token states) into the digital token container of the consumer's communications device. The transport backend serving system may add/update tickets to the token container by repeated repersonalization (eg, updating the state of the token). The ticketing and purchasing application may receive updates from the transport backend service system showing which tickets have been used, partially used, or not used. In some embodiments, the tickets that are pushed to the token container can come from a variety of sources, such as purchases directly from a ticketing and purchasing application, in-person purchases, or online purchases via a website.

[0147] In some embodiments, the consumer may select a container of digital tickets before touching the gate to prevent the default payment token from being charged for the trip. The consumer can select a digital ticket in the mobile wallet application on the consumer's communication device and perform a touch on the gate. The gate can read the token (for example, it can be sent as an issuer's trust data), and the communication device can write the gate data to a transaction log. The gate can validate the ticket and open, allowing the consumer access to the transport system. The gate can write the station ID to the transaction log (for example, the station ID and timestamp can be written to the log). The transaction log can be used to control the postback and confirm the validity in the salon. It should be noted that several valid tickets can exist in the digital token container on the communication device at the same time. In some embodiments, all valid tickets may be transferred to the gate upon touch (eg, a single ticket and a season pass may exist simultaneously), and the transport backend serving system may apply rules to determine which ticket to mark as used. Digital tickets can be punched (for example, update the state of the token to partially used or used), but do not need to be removed from the digital token container. In some embodiments, only an authenticated reader may be able to punch tickets (eg, read, write, update a digital token container). In some embodiments, authenticated registration (eg, encrypted registration) may be used for fraud prevention and privacy protection, but may increase the complexity (eg, key management) of the system.

[0148] The tokenization described herein in the sale and purchase of a digital ticket includes the concept of using a token container for application tokens as a mechanism for realizing one-touch tickets. The token container can securely maintain ticket states, communicate with gate readers using a contactless mechanism (e.g., Near Field Communication (NFC)), and allow the ticket issuing entity to dynamically personalize their properties (e.g., update the state of the token). A touch using a token container and/or an application token may not result in a payment transaction, but may only result in a closed communication between the gate and the ticket issuing entity (eg, a transport operator). Tokenization in the sale and purchase of digital tickets enables instant issuance of tickets, can be interoperable globally using proximity reader technology, provides a better user experience for the consumer than alternatives (paper tickets, QR codes, etc.). ), and can have low maintenance costs while being scalable and reliable under high loads.

Loyalty environment

[0149] In some embodiments, the enhanced tokenization system may also be used to manage loyalty information stored in digital token containers. Loyalty information provided by the issuer may be received by the merchant in the following ways. The issuer may optionally provide loyalty information as part of the Token Activation Request (TAR) response. The token service computer may dynamically inject loyalty data into the state of the token at the time of issuance. The digital wallet application may be responsible for transmitting loyalty information to the terminal as part of a payment transaction. Different issuers may have differences regarding the loyalty tokens and refinement tokens that must be transferred during a transaction. Each issuer may use its own tags, and there may be differences in the number of tags used and the content carried by those tags. In some embodiments, issuer-provided loyalty data may be carried in issuer trust data within file control information (FCI) or issuer application data (IAD), which may be of variable length. The token service computer may place this data during impersonation (and during re-personification) (eg, token state updates). Issuer trust data in the FCI may be provided to the terminal in response to an application identifier select command from the terminal, and issuer trust data in the IAD may be provided to the terminal in response to a get processing options command from the terminal.

[0150]Fig. 10 and 11 illustrate examples of loyalty transactions. In these examples, an issuer (eg, a bank) generates loyalty data (eg, to manage loyalty rewards). In other examples, loyalty data can be generated service providers such as merchants, transport service providers, etc.

[0151] FIG. 10 illustrates a loyalty data flow according to some embodiments. In some embodiments, issuers may optionally send back loyalty data and additional issuer data in TAR responses. In the first step, the consumer can accept the terms and conditions of the issuer in the wallet application. In the second step, the wallet application may initiate a token issue call to the token service computer. In a third step, the token service computer may send a token activation request (TAR) to the issuer. In a fourth step, the issuer may respond to the TAR and optionally send back loyalty data and additional issuer trust data. In a fifth step, the token service computer may inject loyalty data and additional data provided by the issuer into the token personification (eg, token state) and return the token personification to the wallet application. In the sixth step, the wallet application issues the token (and its token state) to the consumer device.

[0152] FIG. 11 illustrates a loyalty data update flow according to some embodiments. Issuers may be able to update loyalty (and other issuer trust data) if it changes via updates (eg replacement/upgrade). This can be done through issuer-initiated repersonalization (eg, refreshing the state of the token). In the first step, the issuer can send updated loyalty information using the push method via an API call. In a second step, the token service computer can enter this information into the personification of the token and trigger a re-personification call (eg, update the state of the token) to the wallet application. The wallet application may communicate with the token service computer to retrieve a new personification for the token and update the personification (eg, state of the token) stored in the wallet application.

[0153] In FIG. 12 shows a flow diagram of a process 1200 for managing tokens and token states, according to some embodiments. Process 1200 may be performed, for example, by a server computer associated with the token service computer. Process 1200 may begin at block 1202 by receiving an issue request from an application provider (eg, ticketing agent, transport operator, merchant, etc.) to issue an application token to the user's communications device.

[0154] At block 1204, the application token and the token state of the specified application token may be associated with a transaction token associated with the user in the token store. At block 1206, the application token and the token state of said application token may be issued to the user's communications device. At block 1208, process 1200 may receive a state update request from an application provider to update the token state of the specified application token.

[0155] At block 1210, process 1200 may update the token state of the specified application token. The token state of the specified application token is stored in the token store. At block 1212, the updated state of the token stored in the token store may be synchronized with the state of the token in the communication device. In some embodiments, the state of the token may be referred to as "personalization" and may include usage information such as transportation information and/or loyalty information.

Examples of event-specific data and device-specific data

[0156] The communication device and the access device may monitor, store, and analyze event-specific data and/or device-specific data. This data may be used to validate interactions, track and prevent fraud. Also, in transport-related settings, it may be important to track when a user touches an access device when entering and exiting (for example, if the application token is based on a time period, such as a day pass). The following examples show the types of event-specific data and device-specific data that a communication device and an access device can be adapted to manage.

Access device

[0157] The access device may provide the following information to the account management application:

timestamp - exact timestamp (5 bytes)

Timestamp Conversion Factor - Coefficient for converting to UTC (1 byte)

Program ID - program ID (4 bytes)

Period number - the period assigned by the program (2 bytes)

Location name - unique location assigned by the program (20 bytes)

Terminal identifier - a unique identifier of the terminal (access device) assigned to a specific location in the program (2 bytes)

The program operator is responsible for maintaining the above data accurately. For example, in the event of a power failure or system reboot, the timestamp must be synchronized, and whenever a period expires, the period number must increment on all access devices in the system.

[0158] The access device must also be able to verify the signature provided by the account management application. The access device's logic for accepting a particular application token or detecting fraud is program dependent.

Communication device

[0159] In addition to the time stamp of the access device, the account management application may be able to obtain the universal time stamp (UTC) of the communication device. This can be achieved through a number of mechanisms.

If the device can receive a global positioning system (GPS) signal, the app has access to the time in the GPS signal.

If your device has network access, it can get cellular network time or get signed time from a number of services if data services are available.

If the device does not have access to the network or to a GPS signal, there are still aspects that can be performed if the application has been able to access the exact time since the last boot. The device keeps track of the time since the last boot, so this can be used in conjunction with the last received correct time to calculate the current correct time.

[0160] The account management application may include a journal with the following capabilities:

Ability to log a minimum of 100 touches (40 bytes/touch=4000 bytes).

The format of the log entry is as follows (defined length values without delimiters):

Time stamp on the terminal (access device) (5 bytes) - The source is the terminal

Program ID (4 bytes) - Source is terminal

Period number (2 bytes) - The source is the terminal

Location name (20 bytes) - Source is terminal

Terminal ID (2 bytes) - The source is the terminal

Application timestamp (5 bytes) - Source is application

Status word (2 bytes) - the source is the application

Example token container specifications

[0161] The account management application may include a token container with the following capabilities:

Ability to store a minimum of 100 tickets 20 bytes long (2500 bytes).

The maximum entry size is 255 bytes - 5 bytes of the header and 250 bytes of the ticket data blob (application token).

Since the actual length of application tokens varies by program, the actual number of application tokens that can be stored/maintained in a container will vary, and ensuring that memory garbage collection occurs whenever a container approaches its maximum capacity is the responsibility of the application to account management and/or computer token services.

[0162] The token container entry format may be as follows (length/value pair):

Length of subsequent data (1 byte)

Program ID (4 bytes)

Interval in minutes (2 bytes)

Ticket data binary object (application token) (1-250 bytes)

[0163] The methods described herein have many advantages. With the token service computer, each individual service provider application does not need to be integrated with each individual account management application. Thus, the functions performed by the token service computer simplify integration and improve scalability.

[0164] In addition, the cryptographic techniques described herein enhance the security of issuing and redeeming application tokens such as digital tickets. Data is signed and verified using secure keys. These cryptographic operations may additionally use interaction-specific data. Accordingly, the system can ensure that a user/device attempting to access a location or resource using an application is the user or device for which the application token was issued.

[0165] Additional benefits include offline verification capabilities. The access device can cryptographically verify that the application token is valid without having to communicate with an internal server. Accordingly, the validity of the application token can be verified much faster than if messages were sent to and from a remote server. The validity of the application token can be further verified without an internet connection. These improvements are especially useful in a transport environment where speed and portability are key.

[0166] Next, a computer system that can be used to implement any of the entities or components described herein will be described. Subsystems in a computer system are interconnected via a system bus. Additional subsystems include a printer, keyboard, fixed disk, and a monitor that can be connected to a display adapter. Peripherals and input/output (I/O) devices that can be connected to the I/O controller can be connected to the computer system using any number of means known in the art, such as a serial port. For example, a serial port or external interface may be used to connect the computing device to a wide area network such as the Internet, a mouse input device, or a scanner. The system bus interconnection allows the CPU to communicate with each subsystem and manage the execution of instructions from system memory or a fixed disk, as well as the exchange of information between subsystems. The system memory and/or the fixed disk may be a computer readable medium.

[0167] Any of the software components or functions described herein may be implemented as program code executable by a processor using any suitable computer language such as, for example, Java, C++, or Perl, using, for example, traditional or object-oriented approaches. The program code may be stored as a series of instructions or instructions on a computer-readable medium such as random access memory (RAM), read only memory (ROM), a magnetic medium such as a hard disk, or an optical medium such as a CD-ROM. Any such computer-readable medium may reside on or within a single computing device and may be present on or within different computing devices within a system or network.

[0168] The above description is illustrative and not restrictive. Many variations of the present invention will become apparent to those skilled in the art upon reading the present description. Therefore, the scope of the present invention should not be defined with reference to the foregoing description, but should instead be determined with reference to the subject claims, along with their full scope or equivalents.

[0169] The methods and processes described herein are illustrative in nature, and the methods and processes according to some embodiments may perform one or more of the steps in a different order than those described herein, include one or more additional steps not described separately, omit one or more steps, combine one or more steps in one step, split one or more steps into multiple steps, and/or include any combination of the foregoing.

[0170] One or more features from any embodiment can be combined with one or more features from any other embodiment without departing from the scope of the present invention.

[0171] Singular forms denote "one or more" unless otherwise noted separately.

[0172] All patents, patent applications, publications and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. None of these documents is accepted as a prototype.

Claims (66)

1. A method for managing application tokens, which are identifiers used to control access to a resource or place, the method comprising the steps of: submitting, by means of a first service provider application of a plurality of service provider applications on the communication device, to the computer of the first service provider, a first request for a first application token; receiving, by the first service provider application on the communication device, from the first service provider's computer, an encrypted application token corresponding to the first application token; receiving, by the account management application on the communication device, from the first service provider application on the communication device, an encrypted application token; transmitting, by means of the account management application on the communication device, to the token service computer in communication with the computer of the first service provider, a token issuance request with an encrypted application token; receiving, by means of an account management application on the communication device, from the token service computer, a first application token with a digital token container, wherein the digital token container is generated for the first application token and associated with the container identifier and the state of the token associated with the first application token, while maintaining the state the token and the container ID is performed by the token service computer, wherein the token state includes at least one of a newly generated token, a redeemed token, and a value-added token; And storing the first application token in the digital token container in the account management application. 2. The method of claim 1, wherein the token service computer and the first service provider computer have respective cryptographic keys of the cryptographic key pair. 3. The method of claim 2, wherein the cryptographic key pair is a symmetric key pair. 4. The method of claim 1, further comprising the steps of: submitting, by means of the application of the second service provider on the communication device, to the computer of the second service provider, a second request for the second application token; receiving, by the account management application on the communication device, from the token service computer in communication with the computer of the second service provider, the second application token; And storing the second application token in the digital token container in the account management application. 5. Communication device for managing application tokens, which are identifiers used to control access to a resource or place, while the communication device contains: memory; CPU; a durable computer-readable medium containing instructions that, when executed by a processor, perform the steps of: submitting, by the first service provider application of the plurality of service provider applications on the communication device, to the computer of the first service provider, a first request for a first application token; receiving, by the first service provider application on the communication device, from the computer of the first service provider, an encrypted application token corresponding to the first application token; receiving, by the account management application on the communication device, from the first service provider application on the communication device, an encrypted application token; transmitting, by the account management application on the communication device, to the token service computer, a token issuance request with an encrypted application token; receiving, by the account management application on the communication device, from the token service computer, a first application token with a digital token container, wherein the digital token container is generated for the first application token and associated with the container identifier and the state of the token associated with the first application token, while maintaining the state the token and the container ID is performed by the token service computer, wherein the token state includes at least one of a newly generated token, a redeemed token, and a value-added token; And storing the first application token in a digital token container in the account management application. 6. The communication device according to claim 5, wherein the token service computer and the first service provider computer have respective cryptographic keys of the cryptographic key pair. 7. Communication device according to claim 6, wherein the cryptographic key pair is a symmetric key pair. 8. Communication device according to claim 5, wherein the steps further comprise: submitting, by the application of the second service provider on the communication device, to the computer of the second service provider, a second request for a second application token; receiving, by the account management application on the communication device, from the token service computer in communication with the computer of the second service provider, the second application token; And storing the second application token in a digital token container in the account management application. 9. A method for managing application tokens, which are identifiers used to control access to a resource or place, the method comprising the steps of: receiving, by the service provider computer from the service provider application of the plurality of service provider applications on the communication device, an application token request; And transmitting, by the service provider's computer, a token issuance request to the service computer for issuing an application token to the digital token container in the account management application on the communication device, the transmission of the issuance request comprising the steps of: transmitting, by means of the service provider's computer, to the service provider's application, the encrypted application token, and transmitting, by the service provider application to the token service computer, the issuance request and the encrypted application token, wherein the encrypted application token corresponds to said application token, wherein a digital token container is generated for the application token and is associated with the container identifier and the token state associated with the encrypted application token wherein the token state and container ID are maintained by the token service computer, wherein the token state includes at least one of a newly generated token, a redeemed token, and a value-added token. 10. The method of claim 9, wherein the digital token container is passed to the account management application with the application token. 11. The method of claim 9, wherein the service provider's computer sends a issuance request directly to the token service computer. 12. The method according to any one of claims 9 and 11, wherein the digital token container is stored in the account management application before said receipt. 13. Service provider's computer for managing application tokens, which are identifiers used to control access to a resource or place, while the computer contains: memory; CPU; a durable computer-readable medium containing instructions that, when executed by a processor, perform the steps of: receiving, from the service provider application of the plurality of service provider applications on the communication device, an application token request; And transmitting the issuance request to the token service computer for issuing the application token to the digital token container in the account management application on the communication device, wherein the transmission of the issuance request comprises: transfer, to the service provider's application, an encrypted application token and transmission, by a service provider application to the token service computer, of a request for issuance and an encrypted application token, wherein the encrypted application token corresponds to said application token, wherein a digital token container is generated for the application token and associated with a container identifier and a token state associated with the encrypted application token wherein the token state and container ID are maintained by the token service computer, wherein the token state includes at least one of a newly generated token, a redeemed token, and a value-added token. 14. The service provider computer of claim 13, wherein the service provider computer sends the issuance request directly to the token service computer. 15. The service provider's computer according to claim 13 or 14, wherein the digital token container is stored in the account management application before said acceptance. 16. A method for managing application tokens, which are identifiers used to control access to a resource or place, the method comprising the steps of: receiving, at the token service computer, an issuance request, in encrypted form, for issuing an application token to a digital token container in an account management application on the communication device, the communication device also comprising a service provider application associated with the service provider computer; decrypting the issuance request; generate an application token; And transmitting, to the account management application on the communication device, from the token service computer, the application token to the digital token container in the account management application on the communication device, wherein the digital token container is generated for the application token and associated with the container ID and the state of the token associated with the application token wherein the token state and container ID are maintained by the token service computer, wherein the token state includes at least one of a newly generated token, a redeemed token, and a value-added token. 17. The method of claim 16, wherein the token service computer transmits a digital token container with an application token. 18. The method of claim 16, wherein the token service computer transmits the digital token container before receiving the issuance request. 19. The method of claim 16 or 18, wherein the token service computer receives a issuance request from the service provider computer. 20. A token service computer for managing application tokens, which are identifiers used to control access to a resource or place, whereby the computer contains: memory; CPU; a durable computer-readable medium containing instructions that, when executed by a processor, perform the steps of: receiving a issuance request, in encrypted form, to issue an application token to a digital token container in an account management application on the communication device, the communication device also comprising a service provider application associated with the service provider's computer; decrypting the issuance request; generating an application token; And transferring, to the account management application on the communication device, from the token service computer, the application token to the digital token container in the account management application on the communication device, wherein the digital token container is generated for the application token and associated with the container ID and the state of the token associated with the application token wherein the token state and container ID are maintained by the token service computer, wherein the token state includes at least one of a newly generated token, a redeemed token, and a value-added token. 21. The token service computer of claim 20, wherein the digital token container is transmitted to the account management application with the application token. 22. The token service computer of claim 20, wherein the token service computer transmits the digital token container before receiving the issuance request. 23. The token service computer of claim 20, wherein the token service computer receives a issuance request from the service provider computer.

Images