Token fail-safe system and method

Abstract

A method includes a token requestor computer sending a first authorization request message including a token and a first cryptogram to a server computer for authorizing an interaction. The token requestor computer receives a first authorization response message including a response code from the server computer and then generates a cryptogram request message including the token or a token identifier and the response code. The token requestor computer sends the cryptogram request message to a token provider computer, which generates a second cryptogram. The token requestor computer receives the second cryptogram and a credential and generates a second authorization request message including the second cryptogram and the credential. The token requestor computer sends the second authorization request message to the server computer. A second authorization response message is received from the server computer in response to the second authorization request message. The second authorization response message indicates whether the interaction is authorized.

Description

[0001] Cross-references to related applications

[0002] none. Background Technology

[0003] Token-based interactions are performed to allow users to access resources provided by resource providers. Tokens can be provided to authorizing entities to authorize the interaction. If a token interaction fails, the interaction is terminated. Token interactions can fail for various reasons. For example, malfunctions may occur due to errors or other non-malicious causes. For illustration, token interactions may fail due to incorrect ciphertext, incorrect tokens, missing data fields, blacklisted tokens, etc.

[0004] However, currently, when token interaction fails, users and resource providers can only try to execute the same authorization request again. This makes it highly likely that it will fail again.

[0005] The embodiments of this disclosure individually and collectively address this problem and others. Summary of the Invention

[0006] One embodiment relates to a method comprising: sending a first authorization request message, comprising a token and a first cryptographic message for authorizing an interaction between a user and a resource provider, to a server computer, wherein the token is associated with a credential; receiving a first authorization response message, comprising a response code, from the server computer by the token requester computer; in response to receiving the first authorization response message, generating a cryptographic message request message comprising a token or a token identifier associated with the token and the response code by the token requester computer; sending the cryptographic message request message to a token provider computer, wherein the token provider computer generates a second cryptographic message and provides the second cryptographic message and the credential to the token requester computer; receiving the second cryptographic message and the credential from the token provider computer by the token requester computer; generating a second authorization request message comprising the second cryptographic message and the credential by the token requester computer; sending the second authorization request message to the server computer for interaction; and receiving a second authorization response message from the server computer in response to the second authorization request message, the second authorization response message indicating whether the interaction is authorized.

[0007] Another embodiment relates to a method comprising: sending an authorization request message, comprising a token requester computer and a cryptographic message for an interaction between an authorized user and a resource provider, to an authorized entity computer, wherein the token is associated with a first credential; receiving, by the token requester computer, the authorization response message comprising a response code indicating a reason for the interaction being rejected; generating, by the token requester computer, a second cryptographic message request message comprising a token identifier associated with the token, the response code, and an authorization flag indicating that the interaction was rejected; sending, by the token requester computer, the second cryptographic message request message to a token provider computer, wherein the token provider computer generates the second cryptographic message and provides the second cryptographic message and the first credential to the token requester computer; receiving, by the token requester computer, the second cryptographic message and the first credential from the token provider computer; generating, by the token requester computer, a second authorization request message comprising the second cryptographic message and the first credential; and sending, by the token requester computer, the second authorization request message to the authorized entity computer, wherein the authorized entity computer determines whether to authorize the interaction.

[0008] Another embodiment relates to a token requester computer, including a processor and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to implement a method. The method may include: sending to a server computer the first authorization request message including a token and a first cryptographic message for authorizing an interaction between a user and a resource provider, wherein the token is associated with a credential; receiving from the server computer the first authorization response message including a response code; in response to receiving the first authorization response message, the token requester computer generating a cryptographic message request message including the token or a token identifier associated with the token and the response code; sending the cryptographic message request message to a token provider computer, wherein the token provider computer generates a second cryptographic message and provides the second cryptographic message and the credential to the token requester computer; receiving from the token provider computer the second cryptographic message and the credential; generating a second authorization request message including the second cryptographic message and the credential; sending the second authorization request message to the server computer for interaction; and receiving from the server computer the second authorization response message in response to the second authorization request message, the second authorization response message indicating whether the interaction is authorized.

[0009] Another embodiment relates to a method comprising: receiving, by a token provider computer, a cryptographic request message including a token or a token identifier associated with the token and a response code from a token requester computer; determining, by the token provider computer, whether to provide the cryptographic message to the token requester computer based on the response code; generating the cryptographic message by the token provider computer; generating, by the token provider computer, a cryptographic response message including the cryptographic message and a credential; and providing the cryptographic response message to the token requester computer, wherein the token provider computer sends the authorization request message including the cryptographic message and the credential to a server computer for interaction, and receives, in response to the authorization request message, an authorization response message from the server computer, the authorization response message indicating whether the interaction is authorized.

[0010] Further details regarding embodiments of this disclosure can be found in the detailed description and the accompanying drawings. Attached Figure Description

[0011] Figure 1 A block diagram of a token system according to an embodiment is shown.

[0012] Figure 2 A block diagram of components of a token requester computer according to an embodiment is shown.

[0013] Figure 3 A flowchart illustrating a token processing method according to an embodiment is shown.

[0014] Figure 4 A flowchart illustrating a secure location access method according to an embodiment is shown. Detailed Implementation

[0015] Before discussing the embodiments of this disclosure, some terms may be described in further detail.

[0016] "User" can include an individual. In some embodiments, a user may be associated with one or more personal accounts and / or user devices. In some embodiments, a user may also be referred to as a cardholder, account holder, or consumer.

[0017] A “user device” can be a device operated by a user. Examples of user devices can include mobile phones, smartphones, cards, personal digital assistants (PDAs), laptops, desktop computers, server computers, vehicles (e.g., automobiles), simplified client devices, tablet PCs, and so on. Furthermore, a user device can be any type of wearable technology device, such as a watch, headphones, glasses, etc. A user device can include one or more processors capable of processing user input. A user device can also include one or more input sensors for receiving user input. As is known in the art, there are various input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. User input obtained by input sensors can come from various data input types, including but not limited to audio data, visual data, or biometric data. A user device can include any electronic device that can be operated by the user, and said electronic device can also provide remote communication capabilities with a network. Examples of remote communication capabilities include using mobile phone (wireless) networks, wireless data networks (e.g., 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that can provide access to a network (e.g., the Internet or a private network).

[0018] A “ciphertext” can include obscure text, such as encrypted text. Ciphertext can be formed by encrypting input data using an encryption key (such as a symmetric encryption key). In some embodiments, the ciphertext is reversible, allowing the same symmetric key to be used to obtain the input used to form the ciphertext for decryption. In some embodiments, the ciphertext can also be a digital signature if the input data is encrypted using the private key of a public / private key pair. The digital signature can be verified using the public key of the public / private key pair. In some embodiments, the ciphertext can include a Dynamic Card Verification Value (dCVV).

[0019] In embodiments of the invention, the ciphertext can be generated in any suitable manner. In some embodiments, the input to the ciphertext may include data elements, including account identifiers such as a master account number, and variable data elements such as a counter, time of day, or interaction value. Such data can be included using encryption processes such as DES, Triple DES, or AES using any suitable encryption key. The encryption key may also be a UDK (Unique Derived Key) and may be generated based on device-specific information such as an account number, which can be encrypted using a Master Derived Key (MDK). The ciphertext can be verified by another computer, such as a remote computer, by decrypting the ciphertext and comparing it with other data (e.g., an account number stored in a file), or by encrypting other input and subsequently comparing the encrypted result with the ciphertext.

[0020] A “credential” can include any evidence of authorization, rights, or privileges. For example, an access credential can include permission to access certain tangible or intangible assets (such as buildings or documents). Examples of credentials can include passwords, passcodes, or confidential messages. In another instance, a payment credential can include any suitable information associated with and / or identifying an account (e.g., a payment account and / or a payment device associated with that account). This information can be directly related to the account or can be derived from account-related information. Examples of account information can include “account identifiers” such as PAN (primary account number or “account number”), tokens, sub-tokens, gift card numbers or codes, prepaid card numbers or codes, usernames, expiration dates, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification value, and so on. An example of a PAN is a 16-digit number, such as “4147 0900 0000 1234”. In some embodiments, credentials can be considered sensitive information.

[0021] A "token" can be a value that can be used to process data. In some embodiments, the token is a value generated by a remote computer used in the authentication process. In some cases, the token can be a substitute for a real credential. A token can be a string of numbers, letters, or any other suitable characters.

[0022] The term "verification" and its derivatives can include the process of using information to determine whether an underlying subject is valid under a given set of conditions. Verification can include any comparison of information to ensure that certain data or information is correct, valid, accurate, legitimate, and / or credible.

[0023] "Interaction" can include reciprocal effects or influences. "Interaction" can include communication, contact, or exchange between parties, devices, and / or entities. Example interactions include transactions between two parties and data exchange between two devices. In some embodiments, an interaction can include a user requesting access to secure data, secure web pages, secure locations, etc. In other embodiments, an interaction can include a payment transaction in which two devices can interact to facilitate the payment. In some embodiments, an interaction can include location access interaction.

[0024] "Interaction data" can include data related to the interaction and / or data recorded during the interaction. In some embodiments, interaction data can be transaction data. Interaction data can include data used to process and complete the interaction. For example, interaction data can include amounts (e.g., transaction amount, data volume, and time volume, etc.). Interaction data can include transaction codes, currency codes, dates and / or times, resource provider identifiers, and / or any other suitable data used in the interaction. Interaction data can include values ​​or quantities, information associated with a first party (e.g., aliases, identifiers, contact addresses, etc.), information associated with a second party (e.g., aliases, device identifiers, contact addresses, etc.), one-time values ​​(e.g., random values, temporary values, timestamps, counts, etc.), and / or any other suitable information.

[0025] An "authorization request message" can be an electronic message requesting authorization for an interaction. In some embodiments, the authorization request message is sent to the network processing computer and / or the issuer of the payment card to request transaction authorization. According to some embodiments, the authorization request message may comply with International Organization for Standardization (ISO) 8583, a standard for systems that exchange information related to electronic transactions associated with payments made by a user using a payment device or payment account. The authorization request message may include an issuer account identifier that can be associated with the payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information," including (by way of example only): service code, card verification value (CVV), dynamic card verification value (dCVV), primary account number or "account number" (PAN), payment token, username, expiration date, etc. The authorization request message may also include "transaction information," such as any information associated with the current transaction, such as transaction value, merchant identifier, merchant location, acquiring bank identifier (BIN), card acceptor ID, information identifying the item being purchased, etc., and any other information that may be used to determine whether to identify and / or authorize the transaction.

[0026] An "authorization response message" can be a message responding to an authorization request message. In some cases, an authorization response message can be an electronic message response to an authorization request message generated by the issuing financial institution or a network processing computer. By way of example only, an authorization response message may include one or more of the following status indicators: Approval – the transaction is approved; Rejection – the transaction is not approved; or Call Center – further information is pending, and the merchant must call the toll-free authorization number. An authorization response message may also include an authorization code, which can be a code indicating approval of the transaction returned by the credit card issuing bank to the merchant's access device (e.g., a POS device) in response to the authorization request message in the electronic message (directly or via a network processing computer). This code can serve as evidence of authorization.

[0027] "Authorizing entity" can be the entity requesting authorization. Examples of authorizing entities can be issuers, government agencies, document repositories, access administrators, etc. Authorizing entities can operate authorizing entity computers. "Issuer" can refer to a commercial entity (e.g., a bank) that issues and optionally maintains user accounts. Issuers can also issue payment credentials to consumers that are stored on user devices (such as cellular phones, smart cards, tablets, or laptops, or in some embodiments, portable devices).

[0028] A "resource provider" can be an entity that can provide resources such as goods, services, information, and / or access. Examples of resource providers include merchants, data providers, transportation departments, government entities, venue and residential operators, etc. A "merchant" can typically be an entity that participates in a transaction and can sell goods or services or provide access to goods or services.

[0029] An "authorization flag" may include variables used to indicate specific attributes of the authorization process. The authorization flag can be a Boolean value (e.g., 0 or 1, true or false, etc.). The authorization flag can indicate whether an interaction is authorized. For example, the authorization flag can indicate that an interaction is denied, or it can indicate that an interaction is authorized. In some embodiments, the authorization flag may be referred to as a contingency plan indicator (e.g., an indication to deny initial authorization, and processing may contingent on using credentials instead of tokens).

[0030] A "response code" can include a series of letters, numbers, or other symbols in response to a request. A response code can be generated in response to an authorization request message and can be included in an authorization response message. A response code can indicate the reason for rejecting the interaction. For example, a response code can indicate that token interaction is rejected due to incorrect password, incorrect token, missing data fields, fraudulent attempts, or any other suitable reason for rejecting token interaction.

[0031] A “processor” can include means for performing a task. In some embodiments, a processor can include any suitable one or more data computing means. A processor can include one or more microprocessors that work together to perform a desired function. A processor can include a CPU that includes at least one high-speed data processor sufficient to execute program components for performing user and / or system-generated requests. A CPU can be a microprocessor, such as AMD’s Athlon, Duron, and / or Opteron; IBM and / or Motorola’s PowerPC; IBM and Sony’s Cell processors; Intel’s Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

[0032] "Memory" can be any suitable one or more devices capable of storing electronic data. Suitable memory can include non-transitory computer-readable media whose storage can be executed by a processor to implement desired methods. Examples of memory can include one or more memory chips, disk drives, etc. Such memory can be operated using any suitable electrical, optical, and / or magnetic modes of operation.

[0033] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers that work like cells. In one example, a server computer can be a database server coupled to a web server. A server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations to serve requests from one or more client computers.

[0034] Embodiments of this disclosure allow contingency plans or fault protection features that permit subsequent requests for credentials after a token interaction fails. The token requester computer can request credentials after a token authorization interaction fails. The credentials can then be provided in a second authorization request message used to authorize the authorizing entity computer. However, the token requester computer's plaintext retention of the credentials may be limited to cases where the first authorization attempt fails. Therefore, the token requester computer's access to the credentials is restricted. Furthermore, after the token requester computer has authorized an interaction using the credentials, the network processing computer can monitor future interactions performed by the token requester computer against the credentials. If the token requester computer subsequently uses the credentials fraudulently or incorrectly, the network processing computer can reject the interaction authorization request.

[0035] For example, in various embodiments, a token provision and activation process may occur. For instance, a token requester initiates a token request for a first credential (e.g., a PAN). The first credential information is verified and stored in a database associated with the token provider's computer, and can then be delivered to an authorized entity for verification. The token provider's computer then generates a token and returns it to the token requester.

[0036] At any subsequent appropriate point in time, the user initiates an interaction, or the token requester uses the token to initiate an interaction initiated by the resource provider. The token is accompanied by an associated token ciphertext, which can be used to ensure that domain restriction controls can be applied. An authorization request message, including the token, the ciphertext, and the interaction data, is sent from the token requester's computer to the authorizing entity's computer via a network processing computer. The authorizing entity's computer may refuse the interaction for a specified reason (e.g., in response code "05"). For example, a rejection response code "05" could indicate that the token interaction was rejected due to the submission of an incorrect ciphertext, etc.

[0037] The authorizing entity computer can then generate an authorization response message including an indication that the interaction was denied and a response code, and send it to the token requester computer. The token requester computer can then send a new cryptographic request to the token provider computer, the cryptographic request containing a token reference ID, a rejection response code, and an authorization flag indicating that the interaction was denied. The authorization flag can also be represented as a contingency plan indicator.

[0038] The token provider computer receives the request, verifies that the previous ciphertext request was generated within a predetermined time period, and then retrieves the first credential from the database. The token provider computer then returns the first credential along with the new ciphertext to the token requester computer. In some embodiments, the newly generated ciphertext may include an authorization flag. The new ciphertext may be generated based on a second credential associated with the first credential (e.g., an existing card verification value). Ciphertext generated by encrypting input data can be described as ciphertext generated based on the input data.

[0039] The token requester computer can then send a second authorization request message to the network processing computer, including a first credential for interaction and a new ciphertext, wherein the new ciphertext has been verified. In some embodiments, the network processing computer can insert an authorization flag into the second authorization request message, which is then sent to the authorizing entity computer.

[0040] The authorizing entity computer then receives a second authorization request message containing the first credential and the new ciphertext. The authorizing entity computer then recognizes that the current interaction is a "response plan" interaction from a specific token requester and makes the relevant authorization decision. The authorizing entity computer can then send a second authorization response message back to the network processing computer, which in turn provides the second authorization response message to the token requester computer.

[0041] The network processing computer then monitors the token requester's computer to ensure that no additional interactive messages are received without the appropriate ciphertext and message content. Otherwise, the token requester's computer will not be allowed to use the first credential.

[0042] Figure 1A system 100 according to an embodiment of the present disclosure is illustrated. System 100 includes a user device 102, a resource provider computer 104, a token requester computer 106, a token provider computer 108, a transport computer 110, a network processing computer 112, and an authorization entity computer 114. In some embodiments, the token requester computer 106 and the resource provider computer 104 may be included in a single computer (collectively referred to as token requester computer 120 in some embodiments) capable of performing the processes executed by both the token requester computer 106 and the resource provider computer 104. For example, a resource provider may also be a token requester.

[0043] User device 102 can perform operational communications with token requester computer 106 and resource provider computer 104. Token requester computer 106 can perform operational communications with token provider computer 108 and resource provider computer 104. Transmission computer 110 can perform operational communications with resource provider computer 104 and network processing computer 112. Network processing computer 112 can perform operational communications with token provider computer 108 and authorizing entity computer 114.

[0044] To simplify the explanation, Figure 1 A certain number of components are shown. However, it should be understood that embodiments of the invention may include more than one of each component. Furthermore, some embodiments of the invention may include more than one of each component. Figure 1 The components shown are fewer or more components.

[0045] At least Figure 1 Messages between devices in System 100 can be sent using secure communication protocols, such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), SSL, ISO (e.g., ISO 8583), etc. The communication network can include any one and / or a combination of the following: direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); an Operational Mission as a Node on the Internet (OMNI); a secure custom connection; a wide area network (WAN); a wireless network (e.g., employing protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.); etc. The communication network can use any suitable communication protocol to generate one or more secure communication channels. In some cases, the communication channel can include a secure communication channel, which can be established in any known manner, such as by using mutual authentication and session keys, and by establishing a Secure Sockets Layer (SSL) session.

[0046] User device 102 may include any suitable user device (e.g., laptop computer, mobile phone, etc.). A user of user device 102 can interact with a resource provider on resource provider computer 104 to gain access to resources. The interaction can be initiated by either the user or the resource provider. To complete the interaction, it can be authorized by authorization entity computer 114. Resource provider computer 104, in conjunction with token requester computer 106, can request a token from token provider computer 108. The token may be associated with the user's primary credentials. For example, the user may have primary credentials as a primary account (PAN). The PAN is associated with tokens stored on token provider computer 108 or with a token database (not shown) that communicates operationally with token provider computer 108.

[0047] Token provider computer 108 can send a token and the associated cryptographic text to token requester computer 106 for interaction. For example, token requester computer 106 can obtain user identification information (e.g., first credential, user identifier, etc.), which can be provided to token provider computer 108 to request a specific token from the user. Upon receiving the token, token requester computer 106 and / or resource provider computer 104 can generate an authorization request message including interactive data, the token, and the cryptographic text. The authorization request message can be provided to authorization entity computer 114 via transmission computer 110 and network processing computer 112.

[0048] Authorizing entity computer 114 can be configured to determine whether to authorize an interaction. Authorizing entity computer 114 can determine to reject the interaction and then generate an authorization response message including an indication that the interaction was rejected and a response code. The response code indicates the reason for the rejection of the interaction. The response code can be a numerical value, where the value relates to the reason. For example, the response code could be "05," which indicates that the interaction was rejected due to an incorrect ciphertext. For example, the ciphertext might be expired or incorrect. As another example, the response code could indicate that the interaction is highly likely to be fraudulent.

[0049] Authorizing entity computer 114 can send an authorization response message to resource provider computer 104 via transmission computer 110 and network processing computer 112. Resource provider computer 104 can send an authorization response message indicating that interaction has been denied to token requester computer 106.

[0050] The token requester computer 106 can be configured to request a second ciphertext from the token provider computer 108, and then send the second ciphertext and other associated data to the authorizing entity computer 114 in a second authorization request message via the resource provider computer 104, the transmission computer 110, and the network processing computer 112, as further detailed herein.

[0051] Figure 2 A block diagram of a token requester computer 200 according to an embodiment is shown. The exemplary token requester computer 200 may include a processor 204. The processor 204 may be coupled to a memory 202, a network interface 206, and a computer-readable medium 208. The computer-readable medium 208 may include a token request module 208A and a supplementary cryptographic request module 208B.

[0052] Memory 202 can be used to store data and code. Memory 202 can be coupled internally or externally to processor 204 (e.g., a cloud-based data storage device) and can include any combination of volatile and / or non-volatile memory such as RAM, DRAM, ROM, flash memory, or any other suitable memory device. For example, memory 202 can store tokens, interaction data, authorization flags, response codes, etc.

[0053] The computer-readable medium 208 may include code executable by processor 204 for performing a method comprising: sending a first authorization request message, comprising a token requester computer and a first cryptographic message for authorizing an interaction between a user and a resource provider, to a server computer, wherein the token is associated with a credential; receiving a first authorization response message, comprising a response code, from the server computer by the token requester computer; in response to receiving the first authorization response message, generating a cryptographic request message, comprising a token or a token identifier associated with the token and the response code, by the token requester computer; sending the cryptographic request message, comprising a token requester computer and a token provider computer, wherein the token provider computer generates a second cryptographic message and provides the second cryptographic message and the credential to the token requester computer; receiving the second cryptographic message and the credential from the token provider computer by the token requester computer; generating a second authorization request message, comprising the second cryptographic message and the credential, by the token requester computer; sending the second authorization request message, comprising the token requester computer and the second authorization request message, to the server computer for interaction; and receiving a second authorization response message, comprising an indication whether the interaction is authorized, from the server computer in response to the second authorization request message.

[0054] The token request module 208A may include code or software executable by the processor 204 for requesting a token from the token provider computer. The token request module 208A, in conjunction with the processor 204, may generate a token request message to request a token from the token provider computer 108. The token request module 208A, in conjunction with the processor 204, may generate a token request message to include credentials, user identifiers, or any other user identification information received from the resource provider computer 104, the user device 102, or stored in the memory 202 of the token requester computer 200.

[0055] In some embodiments, in response to a token request message, the token requester computer 200 may receive a token, a token identifier, a ciphertext, and / or other data associated with the aforementioned data items, such as an expiration date, from the token provider computer.

[0056] The auxiliary ciphertext request module 208B may include code or software executable by the processor 204 for requesting a second ciphertext. The auxiliary ciphertext request module 208B, in conjunction with the processor 204, may generate a second ciphertext request message after a first authorization request message for the interaction is rejected. The auxiliary ciphertext request module 208B, in conjunction with the processor 204, may generate a second ciphertext request message including a token identifier associated with the token, a response code, and an authorization flag indicating that the interaction has been rejected. Instead of indicating that the interaction has been rejected, the auxiliary ciphertext request module 208B, in conjunction with the processor 204, may retrieve the response code and authorization flag from an authorization response message.

[0057] In some embodiments, the auxiliary cryptographic request module 208B, in conjunction with the processor 204, can generate and set an authorization flag to indicate that the interaction is rejected, and then include the authorization flag in the second cryptographic request message.

[0058] Network interface 206 may include an interface that allows token requester computer 200 to communicate with external computers. Network interface 206 may enable token requester computer 200 to transfer data to and from another device (e.g., token provider computer, resource provider computer, etc.). Some examples of network interface 206 may include a modem, a physical network interface (e.g., an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a PCMCIA slot and card, etc. Wireless protocols enabled by network interface 206 may include Wi-Fi. TMData transmitted via network interface 206 may be in the form of signals, which may be electrical signals, electromagnetic signals, optical signals, or any other signals that can be received by an external communication interface (collectively, "electronic signals" or "electronic messages"). These electronic messages, which may include data or instructions, may be provided between network interface 206 and other devices via a communication path or channel. As described above, any suitable communication path or channel may be used, such as wires or cables, optical fibers, telephone lines, cellular links, radio frequency (RF) links, WAN or LAN networks, the Internet, or any other suitable medium.

[0059] Figure 3 A flowchart illustrating a token processing method according to an embodiment is shown. This will be described in the context of user interactions with resource providers, such as payment transactions. Figure 3 The method is illustrated. The interaction can be initiated by a resource provider or a user. In some embodiments, a first authorization request message including a token can be rejected by the authorizing entity computer. The system can be configured to execute a contingency plan process to provide a second authorization request message to the authorizing entity computer if the first authorization request message fails.

[0060] Prior to step 320, the user may interact with a resource provider (e.g., a merchant) using their user device. This interaction may be a payment transaction (e.g., for purchasing goods or services), an access transaction (e.g., for accessing a transportation system), or any other suitable transaction. The user may use their user device, for example, electronically in an online transaction, to instruct the resource provider to provide payment account information. In some cases, the user device may send a request to token requester computer 302 to request a token for the interaction. In other cases, the user device may send a request to resource provider computer 306. In response, resource provider computer 306 may communicate with token requester computer 302 to request a token for the interaction.

[0061] In step S320, the token requester computer 302 may request a token from the token provider computer 304. The token requester computer 302 may request a token associated with a user of the user device or a payment device associated with the user. For example, in some embodiments, the token requester computer 302 may receive credentials, a user identifier, or any other user identification information from the user device, which may be provided to the token provider computer 304. The token provider computer 304 may determine the appropriate token based on the user identification information.

[0062] In step 322, the token provider computer 304 may determine the token associated with the user, and then in step 324, send the token to the token requester computer 302. In some embodiments, the token provider computer 304 may generate the token using an algorithm. In other embodiments, the token provider computer 304 may retrieve the token from a database.

[0063] The token provider computer 304 may also send the cryptographic text associated with the token along with the token to the token requester computer 302. In some embodiments, the token provider computer 304 may also send a token identifier that identifies the token to the token requester computer 302. The token identifier may be any appropriate number of supplementary values ​​that may be linked to the token, but are not the token itself, and are not a credential specifically associated with the token.

[0064] In some embodiments, the token provider computer 304 may store the time and date associated with the sending of the token and ciphertext. This can be done to prevent any subsequent token and ciphertext requests from being fraudulently replayed after an unreasonable period of time.

[0065] At step 326, after receiving the token from the token provider computer 304, the token requester computer 302 can send the token to the resource provider computer 306. In some embodiments, when the resource provider computer 306 and the token requester computer 302 are integrated into a single computer (e.g., respectively...), Figure 1 and Figure 4 When the token requester computer 120 (or 402) is in operation, the token requester computer 120 may generate an authorization request message. The authorization request message may include a token and a ciphertext (e.g., a first ciphertext) for authorizing interaction between the user and the resource provider. After generating the authorization request message (e.g., the first authorization request message), the token requester computer may provide the authorization request message to a server computer. The server computer may include an authorization entity computer 312. The message provided from the token requester computer 302 to the server computer (e.g., the authorization entity computer 312) may be provided via any other computer (e.g., the resource provider computer 306, the transmission computer 308, and / or the network processing computer 310). Specifically, the token requester computer may send the first authorization request message to the server computer, which is both the network processing computer 310 and the authorization entity computer 312. The first authorization request message may be sent to the authorization entity computer 312 via the network processing computer 310, as described with reference to steps 326-334.

[0066] For example, to authorize an interaction, an authorization request message is generated by either the token requester computer 302 or the resource provider computer 306, and then forwarded to the transmitting computer 308 in step 328. The authorization request message may include a token and a ciphertext. The authorization request message may also include any interaction data associated with the interaction. Such interaction data may include, for example, a transaction channel indicator (e.g., an e-commerce transaction channel or a physical point-of-sale transaction channel), an amount, a resource provider identifier, a date, a time, etc.

[0067] In step 330, after receiving the authorization request message, the transmission computer 308 sends the authorization request message to the network processing computer 310.

[0068] At step 332, after receiving the authorization request message, network processing computer 310 can determine the credentials associated with the token. For example, at step 333, network processing computer 310 can send a credential request message to token provider computer 304. The credential request may include the token, ciphertext, and transaction channel indicator. After receiving the credential request, token provider computer 304 can determine the credentials associated with the token and also determine whether the ciphertext was previously issued and associated with the correct transaction channel. Token provider computer 304 can then send a credential response to network processing computer 310. The credential response may include the credentials, ciphertext, and an indication of the token's use in the correct transaction channel. After receiving the credentials associated with the token, network processing computer 310 can insert the credentials, along with optional ciphertext and an indication of the token's use in the correct transaction channel, into the authorization request message. For example, the authorization request message may then include both the token and the credentials associated with the token.

[0069] In step 334, after obtaining the credentials, the network processing computer 310 may then send an authorization request message to the corresponding authorization entity computer 312 associated with the authorization entity that manages the user account.

[0070] At step 336, after receiving the authorization request message, the authorization entity computer 312 can determine whether to authorize the interaction between the user and the resource provider. In this example, the authorization entity computer 312 can refuse the interaction. The authorization entity computer 312 can determine a response code indicating the reason for refusing the interaction. The response code can be an alphanumeric value, such as 05, ABCD, DC01, etc. Token-based interactions can be refused for any suitable reason. For example, the response code could indicate a refusal due to an incorrect password, a token that does not match the credentials associated with the correct user, an expired password, an expired token, a fraudulent interaction attempt, etc. In other cases, the interaction can be refused due to a lack of funds associated with the account or a high probability of fraud.

[0071] The authorized entity computer 312 then generates an authorization response message that includes an indication and response code indicating that the interaction was denied, as well as a token, credentials, interaction data, and / or password.

[0072] In step 338, after generating the authorization response message, the authorization entity computer 312 then provides the authorization response message to the network processing computer 310.

[0073] At step 340, network processing computer 310 may evaluate the authorization response message to determine whether the authorizing entity computer 312 has authorized the interaction. Network processing computer 310 may remove credentials from the authorization response message, such that the authorization response message contains a token but not credentials.

[0074] At step 342, the network processing computer 310 can then send the authorization response message to the transmission computer 308.

[0075] In step 344, after receiving the authorization response message, the transmission computer 308 may send the authorization response message to the resource provider computer 306.

[0076] At step 346, after receiving an authorization response message from the server computer (e.g., from the authorizing entity computer 312 via network processing computer 310), the resource provider computer 306 may evaluate the authorization response message to determine whether the interaction was authorized by the authorizing entity computer 312. In this example, the authorization response message includes an indication that the interaction was rejected and a response code. If the interaction is rejected, the resource provider computer 306 may send an authorization response message to the token requester computer 302 at step 348.

[0077] At step 350, the token requester computer 302 may receive an authorization response message including a response code indicating the reason for rejecting the interaction. In response to receiving an authorization response message (e.g., a first authorization response message) from the server computer, the token requester computer 302 may generate a second cryptographic request message including a token identifier associated with the token, the response code, and an authorization flag indicating that the interaction was rejected. The token identifier can be any suitable unique identifier capable of identifying the token. For example, the token identifier can be an alphanumeric value. The authorization flag can indicate whether the interaction is authorized or not. For example, the authorization flag can be a Boolean value set by the token requester computer 302 based on an indication retrieved from the authorization response message indicating whether the interaction is authorized.

[0078] At step 352, the token requester computer 302 may send a second ciphertext request to the token provider computer 304 to request a second ciphertext (e.g., a second one following the previously used token and ciphertext). The second ciphertext may differ from the first ciphertext, but may use some of the same data elements as input (e.g., the token). Data elements that may be included in the second ciphertext but may not exist in the previously described first ciphertext may include authorization flags (e.g., a contingency plan indicator). In some embodiments, the second ciphertext request may be referred to as a contingency plan ciphertext request.

[0079] At step 354, after receiving the second ciphertext request, the token provider computer 304 can verify that the previous ciphertext was generated within a predefined time period. For example, the token provider computer 304 can determine the length of time between providing the token and ciphertext to the token requester computer 302 and receiving the second ciphertext request. The token provider computer 304 then compares the determined time length with the predefined time period to determine whether to generate a new ciphertext to send to the token requester computer 302. For example, the predefined time period could be 10 minutes, 1 hour, 6 hours, 1 day, etc.

[0080] In some embodiments, the token provider computer 304 may determine whether to provide new ciphertext to the token requester computer 302 based on a response code. The token provider computer 304 may store a table indicating response codes for which new ciphertext can be generated. For example, a response code indicating a fraudulent transaction attempt (e.g., response code "F1") may be stored in the table with an instruction not to provide new ciphertext. This prevents potential and known fraudulent transactions from being retried with new ciphertext. Another response code may indicate that the first authorization request message is incorrectly formatted (e.g., response code "998"). This response code may be stored in the table with an instruction to provide new ciphertext.

[0081] At step 356, if the determined time length is less than a predefined time period (e.g., less than 5 or 10 minutes), the token provider computer 304 generates a new ciphertext (e.g., a second ciphertext). The token provider computer 304 may generate the second ciphertext based on an authorization flag (e.g., indicating that the interaction is unauthorized) and a second credential. The second ciphertext generated by encrypting the input data may be referred to as the second ciphertext generated based on the input data. The second credential may be associated with the token but may be a different credential from the first credential. For example, the first credential may be a PAN, while the second credential may be a dCVV.

[0082] As an illustrative example, token provider computer 304 can generate a second ciphertext by encrypting input data with a cryptographic key, such as a symmetric encryption key. The symmetric encryption key can be obtained from the token provider computer 304 and the network processing computer 310. Figure 3 The steps described herein are stored prior and can be periodically updated with new symmetric encryption keys. In some embodiments, the second ciphertext can be formed by encrypting the input data with other types of cryptographic keys, including unique derived keys, public / private key pairs, etc.

[0083] The input to the second ciphertext may differ from the input to the first ciphertext. For example, in addition to or in lieu of the input used to generate the first ciphertext, the input to the second ciphertext may include a second credential and an authorization flag. However, it should be understood that other data may be included as input, such as a counter or the time of day, to prevent replay attempts (e.g., in cases where a resource provider or token requester attempts to reuse the ciphertext for additional interaction).

[0084] As an additional example, token provider computer 304 can encrypt input data including a response code, a second credential, and a counter. Including the response code in the second ciphertext links the second ciphertext to the reason for rejecting the interaction. Including the second credential in the second ciphertext links the second ciphertext to the user associated with the second credential. Including the counter in the second ciphertext links the second ciphertext to the current interaction, since each interaction performed may cause the counter to increment (or other suitable amount). By including the counter, the second ciphertext cannot be used by the token requester in additional interactions. The counter can be a counter associated with token requester computer 302, and token requester computer 302 can increment it each time an interaction is performed.

[0085] At step 358, after generating the second ciphertext, the token provider computer 304 provides the second ciphertext to the token requester computer 302 via a second ciphertext response message. In some embodiments, the token provider computer 304 may further send the first credential together with the second ciphertext to the token requester computer 302.

[0086] At step 360, after receiving the second ciphertext and the first credential, the token requester computer 302 generates a second authorization request message containing the second ciphertext and the first credential. The second authorization request message may also include any combination of the following: authorization flags, response codes, and / or interaction data. In some embodiments, such interaction data may include, for example, a transaction channel indicator (e.g., an e-commerce transaction channel or a physical point-of-sale transaction channel), an amount, a resource provider identifier, a date, a time, etc. In some embodiments, at step 362, the token requester computer 302 may send the second ciphertext and the first credential to the resource provider computer 306. After receiving the first credential and the second ciphertext, the resource provider computer 306 may then generate a second authorization request message including the first credential and the second ciphertext.

[0087] At step 364, the token requester computer 302 or the resource provider computer 306 may then send the second authorization request message to the server computer (e.g., the authorization entity computer 312) via at least the transmitting computer 308.

[0088] In step 366, after receiving the second authorization request message, the transmission computer 308 then sends the second authorization request message to the network processing computer 310.

[0089] At step 368, after receiving the second authorization request message, the network processing computer 310 can verify the second ciphertext. For example, the network processing computer 310 can generate a verification ciphertext based on the same data used to generate the second ciphertext (e.g., based on the second credential, authorization flag, response code, etc.). The network processing computer 310 can compare the verification ciphertext with the received second ciphertext. If the verification ciphertext matches the second ciphertext, the second ciphertext is valid. In some embodiments, if the second authorization request message does not currently include an authorization flag, the network processing computer 310 can insert an authorization flag indicating that the first authorization request message used for interaction was rejected.

[0090] As an illustrative example, network processing computer 310 can generate a verification ciphertext by encrypting input data with an encryption key, such as a symmetric encryption key. The symmetric encryption key may be the same symmetric encryption key used by token provider computer 304 to form a second ciphertext.

[0091] The network processing computer 310 can retrieve and / or generate input data for generating a verification ciphertext. For example, the input data may include a second credential and an authorization flag. The network processing computer 310 can determine that the second authorization request is a contingency plan authorization request after the first authorization request is rejected. The network processing computer 310 can generate an authorization flag to indicate that the interaction was rejected (e.g., as indicated in the first authorization response message). For example, the network processing computer 310 can generate an authorization flag with the value "1", which may indicate that the first authorization request message was rejected.

[0092] The network processing computer 310 can also obtain second credentials from a database maintained by the network processing computer 310. For example, the network processing computer 310 can access multiple second credentials (e.g., dCVV). The network processing computer 310 can determine which stored second credential is associated with the first credential and / or the user.

[0093] In some embodiments, the second credential may be stored and maintained in a database by the token provider computer 304. At step 369, the network processing computer 310 may request a second credential from the token provider computer 304 in a second credential request message. The second credential request may include a credential, a second ciphertext, and / or a transaction channel indicator. Upon receiving the second credential request message, the token provider computer 304 may determine the second credential in response to the message. The token provider computer 304 may also determine, based on the transaction channel indicator, whether the second ciphertext was previously issued and associated with the correct transaction channel. The token provider computer 304 is then able to send a second credential response message to the network processing computer 310. The second credential response message may include the second credential, the second ciphertext, and an indication of using the credential (e.g., PAN) in the correct transaction channel. Upon receiving the credential associated with the token, the network processing computer 310 may insert the credential, along with optional ciphertext and an indication of using the token in the correct transaction channel, into an authorization request message. For example, the authorization request message may then include both the token and the credential associated with it.

[0094] After receiving the input data for the verification ciphertext, the network processing computer 310 can generate the verification ciphertext by encrypting the authorization flag and the second credential with a symmetric encryption key (for example, the same symmetric encryption key used by the token provider computer 304 to form the second ciphertext).

[0095] In some embodiments, network processing computer 310 may determine a counter or time to be included in the input data of the verification ciphertext. By including the counter or time, network processing computer 310 may capture replay attempts of the second ciphertext. Both network processing computer 310 and token provider computer 304 may include the counter as input data to the verification ciphertext and the second ciphertext, respectively.

[0096] After generating the verification ciphertext, the network processing computer 310 can compare the verification ciphertext with the second ciphertext. If the second ciphertext matches the verification ciphertext, then the second ciphertext was genuinely created and is not a reused ciphertext (e.g., in a replay attempt). For example, a fraudulent token requester might attempt to perform a fraudulent interaction using a first credential (e.g., PAN) and the ciphertext. However, the ciphertext will expire (e.g., due to a counter included in the ciphertext creation, the time included in the ciphertext creation, etc.), and therefore, the verification ciphertext generated by the network processing computer 310 with the correct counter or time will not match the received ciphertext. By having the network processing computer 310 verify the second ciphertext, fraudulent attempts to exploit credentials can be stopped if this occurs.

[0097] At step 370, after verifying the second ciphertext, the network processing computer 310 may send a second authorization request message to the authorization entity computer 312. In some embodiments, before sending the second authorization request message, the network processing computer 310 may insert a second credential and (optionally) an indication of using the first credential in the correct transaction channel into the second authorization request message. For example, the authorization request message may then include a first credential and a second credential associated with the token included in the first authorization request message.

[0098] At step 372, after receiving the second authorization request message, the authorization entity computer 312 determines whether to authorize the interaction. For example, the authorization entity computer 312 may determine whether to authorize the interaction based on the interaction data, the second ciphertext, the first credential, the authorization flag, and / or any other data included in or stored by the authorization entity computer 312 in the second authorization request message. For example, the authorization entity computer 312 may retrieve a previously determined and stored response code indicating the reason for the interaction being rejected. The authorization entity computer 312 then generates a second authorization response message. The second authorization response message may include an indication of whether the interaction is authorized. The second authorization response message may also include the second ciphertext, the first credential, and the interaction data.

[0099] In some embodiments, the authorizing entity computer 312 may authorize an interaction (e.g., a transaction) using a first credential (e.g., a PAN). For example, the authorizing entity computer 312 may maintain one or more accounts associated with a user. The first credential may correspond to at least one account. The authorizing entity computer 312 may authorize the transaction based on the amount in the account (e.g., the account's funds). For example, if the account associated with the PAN has more funds than requested in the interaction data of the second authorization request message, the authorizing entity computer 312 may authorize the transaction.

[0100] In some embodiments, the authorizing entity computer 312 may evaluate the account identified using the first credential in any suitable manner to detect fraud. For example, the account user may have notified the authorizing entity computer 312 that the user's mobile device has been stolen and that any transactions performed by the user's mobile device are fraudulent. In some embodiments, the authorizing entity computer 312 may evaluate the user's account history and habits to determine whether the current authorization request is a fraudulent authorization request.

[0101] At step 374, after generating the second authorization response message, the server computer (e.g., authorization entity computer 312) sends the second authorization response to the token requester computer 302. The second authorization response can be... Figure 3 Any other suitable computer shown sends a token requester computer 302 from the server computer. For example, the authorizing entity computer 312 may provide a second authorization response message to the network processing computer 310.

[0102] At step 376, after receiving the second authorization response message, the network processing computer 310 may provide the second authorization response message to the transmitting computer 308. In some embodiments, even if the authorizing entity computer 312 has authorized the interaction, the network processing computer 310 may refuse the interaction, for example, based on the value of the fraud risk score.

[0103] At step 378, the transmitting computer 308 may send the second authorization response message to the resource provider computer 306. In some embodiments, after receiving the second authorization response message, the resource provider computer 306 may then send the second authorization response message to the user. For example, the resource provider may provide a webpage or other indication of the second authorization response message as a virtual receipt. The receipt may include interactive data for interaction.

[0104] In some embodiments, at step 380, the resource provider computer 306 may send a second authorization response message to the token requester computer 302. In this way, the token requester computer 302 can receive a second authorization response message from the server computer in response to the second authorization request message. The token requester computer 302 can then erase (e.g., delete) the first credential from its memory.

[0105] In some embodiments, at the end of the day, the normal clearing and settlement process can be performed by the network processing computer 310, the resource provider computer 306, and the authorizing entity computer 312. The clearing process is the exchange of financial details between the acquiring party and the authorizing entity to facilitate posting to the user's payment account and verifying the user's settlement position.

[0106] At step 382, ​​network processing computer 310 can monitor subsequent authorization request messages for the first credential. For example, network processing computer 310 can determine whether a subsequently received authorization request message includes the first credential and whether it originates from token requester computer 302. For example, a fraudulent token requester might attempt to perform a fraudulent interaction using the first credential and ciphertext. However, the ciphertext will expire (e.g., due to a counter included in the ciphertext creation, the time included in the ciphertext creation, etc.). By having network processing computer 310 monitor the first credential, future fraudulent attempts to utilize the first credential can be stopped if this occurs. Thus, providing the first credential and the second ciphertext to token requester computer 302 at step 358 is secure because token requester computer 302 cannot fraudulently reuse or abuse the first credential.

[0107] Embodiments of the present invention are not limited to financial transactions, but can also be used for access transactions. For example, Figure 4 A flowchart illustrating a secure location access process according to an embodiment is shown. Figure 4 The method illustrated is described in the context of a user requesting access to a secure location (e.g., a locked building). However, it should be understood that the invention can be applied to other situations where the ability to authorize access to resources can be granted (e.g., a user can request access to a transportation location, office, data, secure webpage, file cabinet, etc.). Figure 4 Location access computer 412 can be an authorized entity computer.

[0108] Prior to step 420, the user may interact with a resource provider (e.g., a location access provider) using their user device. This interaction could be an access interaction allowing the user to access a secure building. The user may use their user device, for example, electronically in an online interaction, to instruct the resource provider on interaction data. In some cases, the user device may send a request to a token requester computer 402 to request a token for the interaction.

[0109] At step 420, the token requester component 402A of the token requester computer 402 can request a token from the token provider computer 404. The token requester component 402A can request a token associated with a user, which may indicate that the user is allowed access to a specific location. In some embodiments, the token requester component 402A can receive credentials, a user identifier, or any other user identification information, such as user biometric data, from a user device, which can be provided to the token provider computer 404. The token provider computer 404 can determine the appropriate token based on the user identification information.

[0110] At step 422, the token provider computer 404 may determine the token associated with the user, and then at step 424, send the token to the token requester component 402A. In some embodiments, the token provider computer 404 may send the ciphertext associated with the token along with the token to the token requester component 402A. In other embodiments, the token provider computer 404 may also send a token identifier to the token requester component 402A of the token requester computer 402. The token identifier may be a unique identifier for the token.

[0111] At step 426, after receiving the token from token provider computer 404, token requester component 402A may send the token to resource provider component 402B. In some embodiments, when resource provider component 402B and token requester component 402A are integrated into a single computer (e.g., token requester computer 402), token requester computer 402 may generate an authorization request message. For example, to authorize access interaction, an authorization request message is generated by either token requester component 402A or resource provider component 402B and then forwarded to location access computer 412 in step 428. The authorization request message may include a token and a ciphertext. The authorization request message may also include any interaction data associated with the interaction, such as building number, address number, amount, resource provider identifier, user identifier, date, time, etc.

[0112] At step 429, location access computer 412 may send a credential request to token provider computer 404 to obtain credentials associated with the token. The credential request may include the token, ciphertext, and (in some embodiments) a channel indicator. The channel indicator may indicate a specific channel in which the token can be used (e.g., from an interaction originating from a key card, mobile phone, computer, etc.). Upon receiving the credential request, token provider computer 404 may determine the credentials associated with the token and also determine whether the ciphertext was previously issued and associated with the correct channel. Token provider computer 404 may then send a credential response to network processing computer 410. The credential response may include the credentials, ciphertext, and an indication that the token was used in the correct channel.

[0113] At step 430, after receiving an authorization request message requesting authorization for a user to access a secure building, location access computer 412 can determine whether to authorize the interaction. For example, location access computer 412 can determine that the ciphertext has expired, and therefore the interaction cannot be authorized. Location access computer 412 can generate a response code, for example, "DC11," indicating that the interaction is denied due to the expired ciphertext.

[0114] In some embodiments, location access computer 412 may request credentials associated with a token from token provider computer 404, which communicates with both the token provider computer 404 and the location access computer 412. Upon receiving the credentials associated with the token, location access computer 412 determines whether the credentials are sufficient for a user to access a secure location.

[0115] Then, location access computer 412 creates an authorization response message that includes interactive data, cryptographic text, and a response code. At step 432, location access computer 412 provides the authorization response message to token requester computer 402.

[0116] At step 434, resource provider component 402B may evaluate the authorization response message to determine whether location access computer 412 authorizes the interaction. In this example, the authorization response message includes at least an indication that the interaction is denied and a response code. If the interaction is denied, resource provider component 402B may send an authorization response message to token requester component 402A at step 436.

[0117] At step 438, the token requester component 402A may receive an authorization response message including a response code indicating the reason for rejecting the interaction. The token requester component 402A may generate a second cryptographic request message including a token identifier associated with the token, the response code, and an authorization flag indicating that the interaction was rejected. The token identifier may be retrieved from memory after being stored, following step 424. The authorization flag may indicate whether the interaction was authorized or not. For example, the authorization flag may be a Boolean value set by the token requester component 402A based on an indication from the authorization response message indicating whether the interaction was authorized.

[0118] At step 440, the token requester component 402A may send a second ciphertext request to the token provider computer 404 to request a second ciphertext (e.g., a second one following the previously used token and ciphertext). In some embodiments, the second ciphertext request may be referred to as a contingency plan ciphertext request. The token requester component 402A may also send the ciphertext in the second ciphertext request.

[0119] At step 442, after receiving the second ciphertext request, the token provider computer 404 can verify that the previous ciphertext was generated within a predefined time period. For example, the token provider computer 404 can determine the length of time between providing the token and ciphertext to the token requester computer 402 and receiving the second ciphertext request. The token provider computer 404 then compares the determined time length with the predefined time period to determine whether to generate a new ciphertext to send to the token requester computer 402. For example, the predefined time period could be 10 minutes, 1 hour, 6 hours, 1 day, etc.

[0120] In some embodiments, the received second ciphertext request includes the ciphertext. The token provider computer 404 can verify the ciphertext, for example, by determining at step 424 that the received ciphertext is the same as the provided ciphertext. Furthermore, the token provider computer 404 can perform ciphertext verification in any suitable manner.

[0121] At step 444, if the determined time length is less than a predefined time period, the token provider computer 404 generates a new ciphertext (e.g., a second ciphertext). The token provider computer 404 may generate the second ciphertext based on an authorization flag (e.g., indicating that the interaction is unauthorized) and a second credential. The second credential may be associated with the token, but may be a different credential from the first credential. For example, the first credential may be a user identifier (e.g., an employee identifier, a user transportation identifier, etc.), while the second credential may be a user postal code, telephone number, address, etc., that may be associated with the user identifier.

[0122] As an illustrative example, token provider computer 404 can generate a second ciphertext by encrypting input data with a cryptographic key, such as a symmetric encryption key. The symmetric encryption key can be used by token provider computer 404 and location access computer 412. Figure 4 The steps described herein are stored prior and can be periodically updated with a new symmetric encryption key. The token provider computer 404 can generate a second ciphertext by encrypting the second credential, authorization flag, and counter or the time of day, as described herein.

[0123] At step 446, after generating the second ciphertext, the token provider computer 404 provides the second ciphertext to the token requester component 402A via a second ciphertext response message. In some embodiments, the token provider computer 404 may further send the first credential together with the second ciphertext to the token requester component 402A.

[0124] At step 448, after receiving the second ciphertext and the first credential, the token requester component 402A generates a second authorization request message including the second ciphertext and the first credential. The second authorization request message may also include interactive data. In some embodiments, at step 450, the token requester component 402A may send the second ciphertext and the first credential to the resource provider component 402B. Then, the resource provider component 402B may generate the second authorization request message.

[0125] At step 452, in some embodiments, the token requester component 402A or the resource provider component 402B of the token requester computer 402 may send a second authorization request message to the location access computer 412.

[0126] At step 454, location access computer 412 can verify the second ciphertext. Location access computer 412 can generate the verification ciphertext by encrypting the input data with an encryption key, such as a symmetric encryption key. The symmetric encryption key can be the same symmetric encryption key used by token provider computer 404 to form the second ciphertext.

[0127] Location access computer 412 can retrieve and / or generate input data to generate a verification ciphertext. For example, the input data may include a second credential, an authorization flag, and a counter. Location access computer 412 can determine that a second authorization request is a contingency plan authorization request after a first authorization request has been rejected. Location access computer 412 can generate an authorization flag to indicate that the interaction has been rejected (e.g., as indicated in the first authorization response message). For example, location access computer 412 can generate an authorization flag with the value "1," which may indicate that the first authorization request message has been rejected.

[0128] Location access computer 412 can also determine a counter or time to be used as input data for generating the verification ciphertext. By including the counter or time, location access computer 412 can detect replay attempts of the second ciphertext. Both location access computer 412 and token provider computer 404 can include the counter as input data into the verification ciphertext and the second ciphertext, respectively.

[0129] Location access computer 412 can obtain a second credential from a database maintained by token provider computer 404. At step 456, location access computer 412 can request a second credential from token provider computer 404 in a second credential request message. The second credential request may include a credential, a second ciphertext, and / or a transaction channel indicator. Upon receiving the second credential request message, token provider computer 404 can determine the second credential in response to the message. Token provider computer 404 can also determine, based on the channel indicator, whether the second ciphertext was previously issued and associated with the correct channel. Token provider computer 404 can then send a second credential response message to location access computer 412. The second credential response message may include the second credential, the second ciphertext, and an indication to use the credential (e.g., PAN) in the correct transaction channel.

[0130] After obtaining the input data for the verification ciphertext, the location access computer 412 can generate the verification ciphertext by encrypting the authorization flag, the second credential, and the counter using a symmetric encryption key (for example, the same symmetric encryption key used by the token provider computer 404 to form the second ciphertext).

[0131] After generating the verification ciphertext, the location access computer 412 can compare the verification ciphertext with the second ciphertext. If the second ciphertext matches the verification ciphertext, then the second ciphertext was genuinely created and is not a reused ciphertext (e.g., in a replay attempt). For example, a fraudulent token requester might attempt to perform a fraudulent interaction using a first credential (e.g., user biometric data) and the ciphertext. However, the ciphertext will expire (e.g., due to a counter included in the ciphertext creation, the time included in the ciphertext creation, etc.), so the verification ciphertext generated by the location access computer 412 with the correct counter or time will not match the received ciphertext. By having the location access computer 412 verify the second ciphertext, fraudulent attempts to exploit credentials can be stopped if they occur.

[0132] At step 458, after receiving the second authorization request message, the location access computer 412 determines whether to authorize the interaction. For example, the location access computer 412 may determine to authorize the interaction based on any suitable data including, for example, the first credential and the second ciphertext. However, it should be understood that the location access computer 412 may determine whether to authorize the location access request based on any suitable data presented to or determined by the location access computer.

[0133] At step 460, the location access computer 412 may then generate a second authorization response message. The second authorization response message may include an indication of whether the interaction is authorized. The second authorization response message may also include a second ciphertext, a first credential, and interaction data.

[0134] At step 462, after generating the second authorization response message, the location access computer 412 may provide the second authorization response message to the token requester computer 402.

[0135] At step 464, location access computer 412 may unlock the secure building or otherwise allow user access to the secure building after authorized user access has been granted. For example, user access to a secure location may be granted.

[0136] In some embodiments, location access computer 412 may monitor subsequent authorization request messages for the first credential. For example, location access computer 412 may determine whether a subsequently received authorization request message includes the first credential and whether it originates from token requester computer 402.

[0137] Implementation examples may include various methods. For example, a method may include: sending a first authorization request message from a token requester computer to an authorization entity computer, comprising a token and a first ciphertext for an interaction between an authorized user and a resource provider, wherein the token is associated with a credential, wherein the authorization entity computer determines that the interaction is rejected after at least evaluating the token and the first ciphertext, and generates an authorization response message including a response code; receiving the authorization response message from the authorization entity computer by the token requester computer; generating a ciphertext request message from the token requester computer, comprising a token or a token identifier associated with the token and a response code; sending the ciphertext request message from the token requester computer to a token provider computer, wherein the token provider computer generates a second ciphertext and provides the second ciphertext and the credential to the token requester computer; receiving the second ciphertext and the credential from the token provider computer by the token requester computer; generating a second authorization request message from the token requester computer, comprising the second ciphertext and the credential; and sending the second authorization request message from the token requester computer to a network processing computer, wherein the network processing computer determines that the second ciphertext is valid, and then sends an authorization request message comprising a credential to the authorization entity computer, wherein the authorization entity computer determines whether to authorize the interaction based at least on the credential.

[0138] The embodiments of this disclosure have many advantages. For example, embodiments of the invention can allow legitimate interactions to proceed, even if they might initially be rejected for reasons that may not warrant rejection. Thus, embodiments of the invention are more efficient and useful than conventional systems that simply disallow legitimate but mechanically flawed interactions. Furthermore, because tokens are used in embodiments of the invention, they are protected when genuine credentials pass through the interaction system.

[0139] To further enhance the aforementioned security, the network processing computer can monitor the token requester's computer and / or the resource provider's computer for the use of new ciphertext or credentials. In this way, if the token requester's computer and / or the resource provider's computer attempt to use the new ciphertext or credentials in future interactions, the ciphertext will be determined to be invalid by the network processing computer, thus terminating the fraudulent interaction attempt.

[0140] The embodiments offer additional advantages. For example, various embodiments reduce complexity and security hardware requirements through the resource provider computer. For instance, the resource provider computer does not need to include security hardware to store credentials that could allow the resource provider computer to retry rejected interactions.

[0141] Although the steps in the flowcharts and process flows described above are shown or described in a specific order, it should be understood that embodiments of the invention may include methods with steps in a different order. Furthermore, steps may be omitted or added, and they may still be present in embodiments of the invention.

[0142] Any software component or function described in this application may be implemented as software code executed by a processor using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python, employing techniques such as conventional or object-oriented methods. This software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission. Suitable media include random access memory (RAM), read-only memory (ROM), magnetic media (e.g., hard disk drives or floppy disks), or optical media (e.g., optical discs (CDs) or digital versatile optical discs (DVDs)), flash memory, and so on. The computer-readable medium may be any combination of such storage devices or transmission means.

[0143] Such programs can also be encoded and transmitted using carrier signals suitable for transmission over wired, optical, and / or wireless networks conforming to various protocols, including the Internet. Therefore, a computer-readable medium according to an embodiment of the invention can be created using data signals encoded with such programs. Computer-readable media encoded with program code can be packaged with a compatible device or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or within a single computer product (e.g., a hard disk drive, CD, or an entire computer system) and can exist on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing a user with any of the results mentioned herein.

[0144] The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art after reading this disclosure. Therefore, the scope of the invention should not be determined by reference to the foregoing description, but rather by reference to the pending claims together with their full scope or equivalents.

[0145] Without departing from the scope of the invention, one or more features from any embodiment may be combined with one or more features from any other embodiment.

[0146] As used herein, unless explicitly indicated otherwise, the terms “a,” “an,” or “the” are intended to mean “at least one / a kind.”

Claims

1. A method for performing an interaction, the method comprising: A first authorization request message is sent from a token requester computer to a server computer, comprising a token for authorizing interaction between the user and the resource provider and a first ciphertext, wherein the token is associated with a credential. The token requester computer receives a first authorization response message, including a response code, from the server computer; In response to receiving the first authorization response message, the token requester computer generates a cryptographic request message including the token or a token identifier associated with the token and the response code; The token requester computer sends the ciphertext request message to the token provider computer, wherein the token provider computer generates a second ciphertext and provides the second ciphertext and the credential to the token requester computer; The token requester computer receives the second ciphertext and the credential from the token provider computer; The token requester's computer generates a second authorization request message including the second ciphertext and the credential; The token requester computer sends the second authorization request message to the server computer for the interaction; and In response to the second authorization request message, a second authorization response message is received from the server computer, the second authorization response message indicating whether the interaction is authorized.

2. The method according to claim 1, wherein, The server computer is an authorized entity computer, wherein, after sending the first authorization request message, the authorized entity computer determines that the interaction is rejected after at least evaluating the token and the first ciphertext, and generates an authorization response message including the response code, wherein the authorization response message is received from the authorized entity computer, and wherein sending the second authorization request message to the server computer for the interaction includes: The token requester computer sends the second authorization request message to the network processing computer, which determines that the second ciphertext is valid, and then sends the second authorization request message including the credential to the authorizing entity computer, wherein the authorizing entity computer determines whether to authorize the interaction based at least on the credential.

3. The method according to claim 2, wherein, After the network processing computer provides the second authorization request message to the authorized entity computer, the network processing computer monitors subsequent interactions for the second ciphertext, wherein if a subsequent authorization request includes the second ciphertext, the network processing computer rejects the subsequent authorization request.

4. The method according to claim 2, wherein, The token requester's computer is integrated with the resource provider's computer.

5. The method according to claim 2, wherein, The ciphertext request message includes an authorization flag indicating that the interaction is rejected.

6. The method according to claim 5, wherein, The credential is a first credential, and wherein the token provider computer generates the second ciphertext based on the authorization flag indicating that the interaction is rejected and a second credential, wherein the first credential is associated with the second credential.

7. The method according to claim 1, wherein, The response code indicates the reason for rejecting the interaction.

8. The method according to claim 1, further comprising: Before sending the first authorization request message, the token requester computer requests the token from the token provider computer; as well as The token requester computer receives the token and the first ciphertext from the token provider computer.

9. The method according to claim 8, further comprising: Upon receiving the token and the first ciphertext, the token requester's computer generates the first authorization request message, which includes the token and the first ciphertext.

10. A token requester computer, comprising: processor; and A computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to perform a method comprising: Send a first authorization request message to the server computer, which includes a token for authorized interaction between the user and the resource provider and a first ciphertext, wherein the token is associated with a credential; Receive a first authorization response message including a response code from the server computer; In response to receiving the first authorization response message, the token requester computer generates a cryptographic request message including the token or a token identifier associated with the token and the response code; Send the ciphertext request message to the token provider computer, wherein the token provider computer generates a second ciphertext and provides the second ciphertext and the credential to the token requester computer; Receive the second ciphertext and the credential from the token provider's computer; Generate a second authorization request message including the second ciphertext and the credential; Send the second authorization request message to the server computer for the interaction; and In response to the second authorization request message, a second authorization response message is received from the server computer, the second authorization response message indicating whether the interaction is authorized.

11. The token requester computer of claim 10, wherein, The server computer is an authorized entity computer, wherein, after sending the first authorization request message, the authorized entity computer determines that the interaction is rejected after at least evaluating the token and the first ciphertext, and generates an authorization response message including the response code, wherein the authorization response message is received from the authorized entity computer, and wherein sending the second authorization request message to the server computer for the interaction includes: The second authorization request message is sent to the network processing computer, which determines that the second ciphertext is valid, and then sends the second authorization request message including the credential to the authorizing entity computer, wherein the authorizing entity computer determines whether to authorize the interaction based at least on the credential.

12. The token requester computer of claim 10, wherein, The server computer is a location access computer, the credential is a user identifier or user biometric data, the interaction is a location access interaction for accessing a secure location, and the resource provider is a location access provider, wherein the user is permitted to access the secure location if the second authorization response message indicates that the location access interaction is authorized.

13. The token requester computer of claim 10, wherein, The response code indicates that the interaction was rejected because of an incorrect password, an incorrect token, or a missing data field.

14. The token requester computer of claim 10, wherein, The method further includes: After sending the second authorization request message, the credential is removed from the memory.

15. The token requester computer of claim 10, wherein, The credential is a first credential, wherein the cryptographic request message includes an authorization flag indicating that the interaction is rejected, and wherein the token provider computer generates the second cryptographic message based on the authorization flag and the second credential, wherein the first credential is associated with the second credential.

16. The token requester computer of claim 15, wherein, The first credential is the main account, and the second credential is the verification value.

17. A method for performing an interaction, the method comprising: The token provider computer receives a cryptographic request message from the token requester computer, which includes a token or a token identifier associated with the token and a response code. The token provider computer determines whether to provide the ciphertext to the token requester computer based on the response code; The ciphertext is generated by the token provider's computer; The token provider's computer generates a cryptographic response message that includes the cryptographic message and the credential; as well as The token provider computer provides the ciphertext response message to the token requester computer, wherein the token provider computer sends an authorization request message including the ciphertext and the credential to the server computer for interaction, and receives an authorization response message from the server computer in response to the authorization request message, the authorization response message indicating whether the interaction is authorized.

18. The method according to claim 17, wherein, The ciphertext request message further includes an authorization flag, wherein the ciphertext is generated based on the authorization flag, and wherein the response code indicates a reason for rejecting the interaction, the method comprising: The token provider's computer retrieves credentials associated with the token identified by the token identifier from the database.

19. The method according to claim 17, wherein, The ciphertext is a second ciphertext, wherein the authorization request message is a second authorization request message, wherein the authorization response message is a second authorization response message, and the method further includes: The token provider computer receives a request for a token from the token requester computer; and The token provider computer provides the token and a first ciphertext associated with the token to the token requester computer, wherein the token requester computer provides the server computer with a first authorization request message including the token, the first ciphertext, and interaction data, wherein the server computer rejects the interaction and provides the token requester computer with a first authorization response message including the token, the response code, and the interaction data.

20. The method of claim 19, further comprising: Before generating the second ciphertext, the token provider computer verifies that the time between providing the token and the first ciphertext and receiving the second ciphertext request message is less than a predefined time period.

Images