Message flow for remote interaction using secure data

Abstract

A method is disclosed. The method includes receiving encrypted data from a user device operated by a user via a secure kernel on a communication device after the user interacts with a resource provider computer in an interaction. The method further includes decrypting the encrypted data to recover access data and a password, and then transmitting an interaction identifier and the access data or a derivative of the access data to the resource provider computer. The resource provider computer transmits an authorization request message including the access data or a derivative thereof to an authorization entity computer. And the processing cloud computer transmits the password to the authorized entity computer. The authorization entity computer receives the authorization request message and the password, and authorizes or rejects the interaction based on data in the authorization request message and the password.

Description

[0001] Cross-reference to related applications

[0002] This application is a PCT application, which claims priority to U.S. Provisional Application No. 63 / 413,851 filed on October 6, 2022, the entire text of which is incorporated herein by reference. Background Art

[0003] In a typical transaction to obtain access to a resource (e.g., a good or service, secure data, etc.) via a remotely located resource provider computer (e.g., via the Internet), a user will typically provide credentials (e.g., a password, an account number, etc.) to the resource provider computer to authenticate themselves to the resource provider computer.

[0004] However, using credentials as the only means of gaining access to resources via a remotely located computer is problematic. Such credentials may be stolen through hacking or social engineering means.

[0005] In some cases, a user may interact with a user device, such as a card, with a client terminal to access resources via a remote computer. In this case, the user device typically has additional security information on it (e.g., a shared secret, password, etc.), which can make remote transactions more secure. Any unauthorized person will need to possess the user device in order to successfully impersonate an authorized user in a transaction.

[0006] However, not all systems can accommodate the use of user devices in this manner. For example, conventional e-commerce infrastructures that utilize user-entered data displayed on a card (e.g., a credit card) use transaction messages that cannot accommodate additional security information that may be stored on the card. Such additional security information may be useful to downstream authorization entity computers that authorize or deny e-commerce transactions.

[0007] Embodiments of the present invention address these and other problems. Summary of the invention

[0008] Embodiments of the present invention relate to token provisioning systems and methods.

[0009] One embodiment includes a method, comprising: after a user interacts with a resource provider computer in an interaction, receiving encrypted data from a user device operated by the user via a security kernel on a communication device by a processing cloud computer; decrypting the encrypted data by the processing cloud computer to recover access data and a password; transmitting an interaction identifier and access data or a derivative of the access data by the processing cloud computer to a resource provider computer, wherein the resource provider computer subsequently transmits an authorization request message including the access data or a derivative thereof to an authorization entity computer; and transmitting the password by the processing cloud computer to the authorization entity computer, wherein the authorization entity computer receives the authorization request message and the password, and authorizes or denies the interaction based on the data in the authorization request message and the password.

[0010] Another embodiment of the present invention includes a processing cloud computer, comprising: a processor; and a computer-readable medium. The computer-readable medium includes code executable by the processor to perform operations, the operations including: receiving encrypted data from a user device operated by the user via a security kernel on a communication device after a user interacts with a resource provider computer in an interaction; decrypting the encrypted data to recover access data and a password; transmitting an interaction identifier and access data or a derivative of the access data to a resource provider computer, wherein the resource provider computer then transmits an authorization request message including the access data or a derivative thereof to an authorization entity computer; transmitting the password to the authorization entity computer, wherein the authorization entity computer receives the authorization request message and the password, and authorizes or denies the interaction based on the data in the authorization request message and the password.

[0011] Another embodiment includes a method, comprising: receiving, by an authorization entity computer, an authorization request message from a processing network computer; receiving, by the authorization entity computer, a password from a processing cloud computer in communication, wherein the password is obtained from a user device operated by a user via a security kernel on a communication device; confirming the password by the authorization entity computer; authorizing, by the authorization entity computer, the authorization request message based in part on the confirmation of the password; and transmitting, by the authorization entity computer, an authorization response message to the processing network computer in response to the authorization.

[0012] Another embodiment of the present invention includes an authorization entity computer, comprising: a processor; and a computer-readable medium. The computer-readable medium includes code executable by the processor to perform a method, the method comprising: receiving an authorization request message from a processing network computer; receiving a password from a processing cloud computer in communication, wherein the password is obtained from a user device operated by a user via a security kernel on a communication device; validating the password; authorizing the authorization request message based in part on the validation of the password; and transmitting an authorization response message to the processing network computer in response to the authorization.

[0013] These and other embodiments of the invention are described in further detail below. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 A system diagram and a process flow according to an embodiment of the present invention are presented.

[0015] Figure 2 An architecture for processing a cloud computer according to some embodiments is shown.

[0016] Figure 3 The architecture of a communication device according to an embodiment is shown.

[0017] Figure 4 Display card-based user equipment.

[0018] Figure 5 An example of a message exchange process showing a communication device capturing access data and a password from a user device. DETAILED DESCRIPTION

[0019] Before discussing embodiments of the present invention, some description of some terminology may be helpful.

[0020] A "communication device" may include any suitable electronic device that can be operated by a user, which may also provide remote communication capabilities with a network. A "mobile communication device" may be an example of a "communication device" that can be easily transported. Examples of remote communication capabilities include the use of a mobile phone (wireless) network, a wireless data network (e.g., 3G, 4G or similar network), Wi-Fi, Wi-Max, or any other communication medium that can provide access to a network such as the Internet or a private network. Examples of mobile communication devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, netbooks, laptop computers, personal music players, handheld dedicated readers, etc. Other examples of mobile communication devices include wearable devices such as smart watches, fitness bracelets, anklets, rings, earrings, etc., and cars with remote communication capabilities. In some embodiments, the mobile communication device can act as a payment device (e.g., the mobile communication device can store and be able to send payment credentials for transactions).

[0021] A "user device" may include a device used by a user. In some cases, a user device may be a payment device. A payment device may be a physical object. A payment device may include a substrate such as a paper or plastic card, and information printed, embossed, encoded, or otherwise included at or near the surface of the object. A payment device may be associated with a value such as a monetary value, a discount, or store credit, and a payment device may be associated with an entity such as a bank, a merchant, a payment processing network, or an individual. Suitable payment devices may be handheld and compact so that they can fit into a user's wallet and / or pocket (e.g., pocket-sized). Exemplary payment devices may include smart cards, magnetic stripe cards, key chain devices (e.g., Speedpass available from Exxon-Mobil Corporation), and other payment devices. TM ) etc. Other examples of payment devices include payment cards, smart media, transponders, etc. If the payment device is in the form of a debit card, credit card or smart card, the payment device may also optionally have features such as a magnetic stripe. Such devices may operate in contact or contactless mode.

[0022] "Access data" may include any suitable data that can be used to access resources or create data that can access resources. In some embodiments, access data may be account information for a payment account. Account information may include credentials such as PAN, payment tokens, expiration dates, verification values ​​(e.g., CVV, CVV2, dCVV, dCVV2), etc. In other embodiments, access data may be data that can be used to activate account data. For example, in some cases, account information may be stored on a mobile device, but may not be activated until the mobile device receives specific information. In other embodiments, access data may include data that can be used to access a location. Such access data may be ticket information for an event, data for accessing a building, transportation ticket information, etc. In other embodiments, access data may include data for obtaining access to sensitive data. Examples of access data may include codes or other data required for a server computer to grant access to sensitive data.

[0023] A "credential" can be any suitable information that serves as reliable evidence of value, ownership, identity, or authority. A credential can be a string of numbers, letters, or any other suitable characters, as well as any object or document that can be used as a confirmation. Examples of credentials include value certificates, identification cards, authentication documents, access cards, passwords, and other login information.

[0024] "Payment credentials" may include any suitable information associated with an account (e.g., a payment account and / or payment device associated with the account). Such information may be directly related to the account, or may be derived from information associated with the account. Examples of payment credentials may include a PAN (primary account number or "account number"), a user's name, an expiration date, and a verification value, such as a CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification value, etc. An example of a PAN is a 16-digit number, such as "4147 0900 0000 1234". In some embodiments, a payment credential may include additional information that may be used to authorize a transaction. For example, a payment credential may include a password associated with a transaction.

[0025] An "encryption key" may include any data value or other information suitable for encrypting data with a cipher. A "decryption key" may include any data value or other information suitable for decrypting encrypted data. In some cases, the encryption key and the decryption key may be the same (i.e., a "symmetric key").

[0026] A "password" may include encrypted information. For example, a password may be a set of text that is encrypted with an encryption key.

[0027] The "secure kernel" is a software component of the operating system that manages the interaction between the system's hardware and software. It can be specifically designed to securely store and manage sensitive data. The secure kernel can also handle the computer's hardware, timing, peripherals, memory, disks, and user access. The code that manages the secure kernel resides in a protected area of ​​memory, separate from programs such as browsers, word processors, or other applications. This separation of user and kernel data can prevent undesirable behavior, such as modifications by offending user programs.

[0028] A "token" may be a substitute value for a credential. A token may be a string of numbers, letters, or any other suitable characters. Examples of tokens include payment tokens, access tokens, personal identification tokens, etc.

[0029] A “payment token” may include an identifier for a payment account that is a substitute for an account identifier such as a primary account number (PAN). For example, a payment token may include a series of alphanumeric characters that can be used as a substitute for an original account identifier. For example, the token “4900 0000 0000 0001” can be used in place of the PAN “4147 0900 0000 1234”. In some embodiments, a payment token may be “format-retained” and may have a digital format that conforms to account identifiers used in existing transaction processing networks (e.g., the ISO 8583 financial transaction message format). In some embodiments, a payment token may be used in place of a PAN to initiate, authorize, settle, or resolve a payment transaction, or to represent an original credential in other systems where an original credential would typically be provided. In some embodiments, a payment token may be generated so that recovery of the original PAN or other account identifier from the token value may not be derived computationally. In addition, in some embodiments, the token format may be configured to allow an entity receiving the token to identify it as a token and to recognize the entity that issued the token.

[0030] "Tokenization" is the process of replacing data with substitute data. For example, a payment account identifier (e.g., a primary account number (PAN)) can be tokenized by replacing the primary account identifier with a substitute symbol (e.g., a token) that can be associated with the payment account identifier. In addition, tokenization can be applied to any other information that can be replaced with a substitute value (i.e., a token). Tokenization improves transaction efficiency and security.

[0031] A "token domain" may indicate an area and / or environment in which a token may be used. Examples of token domains may include, but are not limited to, various payment channels (e.g., e-commerce, physical point of sale, etc.), POS input modes (e.g., contactless, magnetic stripe, etc.), and merchant identifiers that uniquely identify where a token may be used. A set of parameters (i.e., token domain restriction controls) may be established by a token service provider as part of token issuance that may allow for enforcement of appropriate use of tokens in payment transactions. For example, a token domain restriction control may restrict the use of a token in a particular presentation mode, e.g., a contactless or e-commerce presentation mode. In some embodiments, a token domain restriction control may restrict the use of a token at a particular merchant that can be uniquely identified. An exemplary token domain restriction control may require verification of the presence of a token password that is unique to a given transaction. In some embodiments, a token domain may be associated with a token requestor.

[0032] "Token expiration date" may refer to the expiration date / time of a token. The token expiration date may be communicated between entities in the tokenization ecosystem during transaction processing to ensure interoperability. The token expiration date may be a numeric value (e.g., a 4-digit numeric value). In some embodiments, the token expiration date may be expressed as a duration as measured from the time of issuance.

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

[0034] A "resource provider" may be an entity that can provide resources such as goods, services, information, and / or access. Examples of resource providers include merchants, data providers, transportation agencies, government entities, venue and residential operators, and the like.

[0035] A "merchant" may generally be an entity that participates in a transaction and that may sell goods or services or provide access to goods or services.

[0036] An "acquirer" may generally be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities may perform the functions of both an issuer and an acquirer. Some embodiments may encompass such a single entity, issuer-acquirer. An acquirer may operate an acquirer computer, which may also be generally referred to as a "transmitting computer."

[0037] An "authorized entity" may be an entity that authorizes a request. Examples of authorized entities may be an issuer, a government agency, a document repository, an access administrator, and the like.

[0038] An "issuer" may generally refer to a commercial entity (e.g., a bank) that maintains a user's account. An issuer may also issue a payment credential to a consumer that is stored on a user's device (e.g., a cell phone, smart card, tablet, or laptop).

[0039] An "authorization request message" may be an electronic message requesting authorization for a transaction. In some embodiments, the authorization request message is sent to a transaction processing computer and / or the issuer of a payment card to request authorization for a transaction. The authorization request message according to some embodiments may comply with ISO8583, which is a standard for systems for exchanging electronic transaction information 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 may be associated with a 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, CVV (card verification value), dCVV (dynamic card verification value), PAN (primary account number or "account number"), payment token, user name, expiration date, etc. The authorization request message may also include "transaction information", such as any information associated with the current transaction, such as transaction amount, merchant identifier, merchant location, acquirer bank identification number (BIN), card acceptor ID, information identifying the items purchased, etc., as well as any other information that may be used to determine whether to identify and / or authorize the transaction.

[0040] An "authorization response message" may be a message in response to an authorization request. In some cases, the authorization response message may be an electronic message reply to the authorization request message generated by the issuing financial institution or a transaction processing computer. By way of example only, the authorization response message may include one or more of the following status indicators: approved - the transaction was approved; rejected - the transaction was not approved; or call center - more information is pending in the response, the merchant must call a toll-free authorization phone number. The authorization response message may also include an authorization code, which may be a code that the credit card issuing bank returns to the merchant's access device (e.g., POS equipment) in response to the authorization request message in an electronic message (directly or through a transaction processing computer) indicating approval of the transaction. The code may serve as evidence of authorization.

[0041] A "server computer" may include a powerful computer or cluster of computers. For example, a server computer may be a large mainframe, a cluster of small computers, or a group of servers that work as a unit. In one example, a server computer may be a database server coupled to a web server. A server computer may include one or more computing devices and may use any of a variety of computing structures, arrangements, and assemblies to service requests from one or more client computers.

[0042] One embodiment of the present invention includes a method. The method includes receiving, by a processing cloud computer, encrypted data from a user device operated by the user via a security kernel on a communication device after the user interacts with the resource provider computer in an interaction. The method also includes decrypting, by the processing cloud computer, the encrypted data to recover access data and a password. The processing cloud computer then transmits an interaction identifier and the access data or a derivative of the access data to the resource provider computer. The resource provider computer then transmits an authorization request message including the access data or a derivative thereof to the authorization entity computer via a first communication path.

[0043] The resource provider computer may not be able to incorporate the password from the user device into the authorization request message because the authorization request message it typically generates may be used for e-commerce type transactions that will not include a password generated by the user device (e.g., card generated). Therefore, in an embodiment of the present invention, the processing cloud computer transmits the password to the authorization entity computer via a second communication path different from the first communication path. The authorization entity computer receives the authorization request message and the password, and authorizes or denies the interaction based on the data in the authorization request message and the password.

[0044] Embodiments of the present invention have several technical advantages. In the above process, the password generated by the user device (and optionally other security data) can be delivered to the authorization entity computer, but the authorization request message sent by the resource provider computer to the authorization entity computer is not formatted to carry the password generated by the user device. Therefore, embodiments of the present invention provide the authorization entity computer with additional information that can be used to determine whether to authorize a transaction. In a conventional e-commerce transaction system, this information would not be available to the authorization entity computer. In addition, the user does not need to pre-register with the transaction system in order to obtain the additional security provided by embodiments of the present invention.

[0045] Figure 1 A block diagram of a transaction flow and messaging system 100 according to an embodiment is shown. The system 100 includes a user device 102, a communication device 104, a resource provider computer 106, a transmission computer 110, a processing network computer 112, a processing cloud computer 114, an authentication server computer 116, and an authorization entity computer 118. The communication device 104 may include a security kernel 104A programmed to interact with the user device 102 and the processing cloud computer 114. The communication device 104 may also include an application 104B programmed to interact with the resource provider computer 106. Each of these systems and computers may be in operative communication with each other. To simplify the description, the following description is provided in detail. Figure 1 Specific numbers of components are shown in the drawings. However, it should be understood that embodiments of the present invention may include more than one of each component. In addition, some embodiments of the present invention may include more than one of each component. Figure 1 All components shown in the figure are less or more than the components. In addition, Figure 1 The components in may communicate using any suitable communications protocol over any suitable communications medium, including the Internet.

[0046] Resource provider computer 106 may be operated by or on behalf of a resource provider (e.g., a merchant), and transmitting computer 110 may be operated by an acquirer (e.g., a financial institution) responsible for managing accounts associated with the resource provider. Authorizing entity computer 118 may be operated by an issuer (e.g., another financial institution).

[0047] The processing network computer 112 may be in a processing network such as a payment processing network. The payment processing network is configured to provide authorization services and clearing and settlement services for payment transactions. The processing network computer 112 may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception file services, and clearing and settlement services. Exemplary payment processing networks may include VisaNet TM For example, VisaNet TMPayment processing networks such as VisaNet can process credit card transactions, debit card transactions and other types of commercial transactions. TM Specifically, it includes the Visa Integrated Payments (VIP) system that processes authorization requests and the Base II system that performs clearing and settlement services.

[0048] Can be compared to Figure 1 A method according to an embodiment of the invention is described.

[0049] In step S2, the user interacts with a host site operated by a resource provider and initiates a remote e-commerce transaction using the communication device 104. Remote e-commerce transactions can sometimes be characterized as "card not present" transactions. The user can shop and check out on a host site (e.g., a website) on a resource provider computer 106 via an application 104B on the communication device 104. The application 104B can be a browser, or it can be a dedicated application. If it is a dedicated resource provider application, the host site on the resource provider computer 106 can support the dedicated resource provider application.

[0050] In step S4, if the communication device 104 is equipped with near field communication capabilities, the host site operating on the resource provider computer 106 may cause the communication device 104 to present a checkout page / frame that requests the user to interact their user device 102 with the communication device 104 (e.g., click their user device) to complete the checkout process.

[0051] In step S6, the checkout page / frame presented on the host site triggers the secure kernel 104A on the communication device 104 to begin communicating with the user device 102 in proximity to the communication device 104. The host site may provide the secure kernel 104A and / or application 104B in the communication device 104 with the value of the interaction (e.g., the transaction amount) and other data related to the interaction (e.g., a resource provider identifier such as a merchant identifier, a timestamp, etc.).

[0052] In step S8, the security kernel 104A transmits the value and other data used for the interaction to the user device 102. The user device 102 can then generate a password by encrypting at least the data from the resource provider computer 108 (e.g., value, resource provider identifier, etc.) and the data stored in the user device 102 (e.g., access data, such as PAN and expiration date) using a cryptographic key shared with the authorization entity computer 118. In some embodiments, the password can be formed by concatenating the data from the resource provider computer 108 (e.g., value, resource provider identifier, etc.) and the data stored in the user device 102 (e.g., access data, such as PAN and expiration date), hashing the concatenated data, and signing the hashed data (using an HMAC algorithm). The authorization entity associated with the authorization entity computer 118 may have provided the cryptographic key (e.g., symmetric key) to the user before providing it to the user. The authorization entity computer 118 can store or export the corresponding cryptographic key. If it is exported, the authorization entity computer 118 is connected to an HSM (hardware security module) that stores the master key. The corresponding cryptographic key is derived from the master key using the credential (eg, PAN).

[0053] In the interaction between the security kernel 104A and the user device 102, the security kernel 104A ultimately receives access data (e.g., PAN and expiration date) and a password (e.g., an EMV application password) from the user device 102. Because the access data is provided by the user device 102, the user does not need to enter the data into a host site on the resource provider computer 106. This makes the interaction process more convenient and efficient for the user because the user needs to take fewer steps to complete the interaction.

[0054] Prior to step S10, the security kernel 104A establishes a first set of zone encryption keys with the processing cloud computer 114. The security kernel 104A and the processing cloud computer 114 may share the first set of cryptographic keys using any suitable process including a Diffie-Hellman key exchange process. In a similar manner, the processing cloud computer 114 and the resource provider computer 106 may establish a second set of zone encryption keys. The resource provider computer 106 and the processing cloud computer 114 may share the first set of cryptographic keys using any suitable process including a Diffie-Hellman key exchange process.

[0055] In step S10, the security kernel 104A uses the first cryptographic zone key to encrypt the access data and password received from the user device 102. In step S10, the communication device 104 transmits the encrypted data and the resource provider computer identifier or address (e.g., URL) to the processing cloud computer 114, and the processing cloud computer 114 receives the encrypted data and the resource provider computer identifier or address.

[0056] In step S11, the processing cloud computer 114 decrypts the encrypted data using the second cryptographic area key corresponding to the first cryptographic area key and recovers at least the access data and the password.

[0057] In step S12, after obtaining the access data and the password, the processing cloud computer 114 can generate a unique interaction identifier for the transaction. The processing cloud computer 114 can then encrypt the unique interaction identifier (e.g., transaction reference) and the access data or a derivative thereof with the second password zone key. The processing cloud computer 114 can then transmit the encrypted data to the resource provider computer 106. In some embodiments, the access data can be a credential, such as a primary account number or a PAN. In other embodiments, the access data can be a derivative of a credential, such as a token. The token can be a substitute for the PAN. In some embodiments, the processing cloud computer 114 can receive the PAN and can tokenize the PAN to form a payment token, and the payment token can be transmitted to the resource provider computer 106.

[0058] After the resource provider computer 106 receives the encrypted access data or its derivative and the interaction identifier, the resource provider computer 106 can decrypt the encrypted data using the corresponding second zone encryption key. Once decrypted, the resource provider computer 106 can extract the access data or its derivative and the interaction identifier. The resource provider computer 106 can then initiate a transaction authorization process using the access data or its derivative.

[0059] In some embodiments, the processing cloud computer 114 may also transmit other information such as the user's name, shipping information, and contact information to the resource provider computer 106. The resource provider computer 106 may use this information to populate the checkout page to make the checkout process more efficient. In this case, the user does not need to manually fill in information during checkout on the host site on the resource provider computer 106, making the process more efficient for the user.

[0060] In step S14, the resource provider computer 106 sends an authorization request message to the authorization entity computer 118 via the transmission computer 110 and the processing network computer 112. The authorization request message may include the transaction amount, the interaction identifier, the merchant identifier, and the access data or its derivatives, but does not include the password generated by the user device 102. The authorization request message may be in the form of an ISO 8583 message, and may include a card not present transaction or an e-commerce indicator therein. Existing protocols and messages for e-commerce transactions cannot carry passwords. It will be apparent from the following description that embodiments may use existing e-commerce payment infrastructure while still providing a password to the authorization entity computer 118.

[0061] In some embodiments, the authorization request message may include a token instead of a credential. If so, the processing network computer 112 may detokenize the token to obtain the credential. The processing network computer 112 may determine whether the token is being used in the correct domain. If so, the processing network computer 112 may transmit the authorization request message with the credential to the authorization entity computer 118.

[0062] In step S15, once authorization entity computer 118 receives the authorization request message transmitted by resource provider computer 106 via transmitting computer 110 and processing network computer 112, authorization entity computer 118 can use the password generated by the user device to verify the transaction. Authorization entity computer 118 can transmit the authentication request to authentication service computer 116.

[0063] In conventional systems, when the authorization entity computer 118 receives an authorization request message in a card not present type transaction, the authorization entity computer 118 may request a step-by-step authentication of the user (e.g., requesting an OTP from the user). An embodiment introduces a new message transmission mechanism to replace the existing step-by-step authentication method. A password generated by a user device can be transmitted to the authorization entity computer 118 so that the authorization entity computer 118 has additional evidence that the transaction is authentic. Advantageously, the user does not need to provide additional authentication information after the transaction has been initiated. This is a technical advantage because the number of messages in embodiments of the present invention can be less than the number of messages in conventional systems.

[0064] In step S16, the processing cloud computer 114 may extract (e.g., decrypt) the password from the encrypted data packet received from the security kernel using the zone key shared with the security kernel 104A before or after the resource provider computer 106 transmits the authorization request message to the authorization entity computer 118. The processing cloud computer 114 may then transmit the password and the interaction identifier to the authentication service computer 116.

[0065] In step S18, the authentication service computer 116 may then send the password and the interaction identifier to the authorization entity computer 118. This may be done automatically or may be done at the request of the authorization entity computer 118.

[0066] In step S19, once the password is transmitted to the authorization entity computer 118, the authorization entity computer 118 can use the password generated by the user device to verify or confirm the transaction. In some embodiments, the authorization entity computer 118 can decrypt the password using a cryptographic key shared with the user device 102 to recover the input of the password. The input may include data such as an amount and access data. The authorization entity computer 118 can then identify the authorization request message corresponding to the current transaction by matching the interaction identifier from the authentication service computer and the interaction identifier in the authorization request message. The authorization entity computer 118 can then determine whether the data elements (such as the amount and access data) obtained from the password match the corresponding data elements in the authorization request message. If they match, the authorization entity computer 118 can determine that the transaction is valid.

[0067] In other embodiments, as described above, the input is obtained using a cryptographic key (e.g., using an HMAC algorithm), hashed, and then signed. Therefore, in this case, it is impossible for the authorized entity computer 118 to decrypt the input. However, the authorized entity computer 118 can verify the input (e.g., the amount) by verifying the password (signed hash) using the cryptographic key. For example, the input can be hashed and signed with the cryptographic key. The output can be compared to the password to confirm it.

[0068] The authorization entity computer 118 can authorize or deny the authorization request message for the transaction. In addition to verifying the password, it can also determine whether the account corresponding to the access data has sufficient funds or credit to pay for the current transaction. It can also determine whether the existing interaction may be fraudulent.

[0069] It should be noted that variations of the process steps described above may be within embodiments of the present invention. For example, in other embodiments, the password may have been provided to the resource provider computer 106 along with the access data. In this case, the resource provider computer 106, rather than the processing cloud computer 114, may send the password to the authentication service computer 116. In other embodiments, the password may have been provided to the resource provider computer 106 before the resource provider computer 106 receives the access data (e.g., using CNP or card not present messaging).

[0070] After confirmation and approval by the authorization entity computer 118 , in step S20 , the authorization entity computer 118 may generate an authorization response message approving the transaction and send the authorization response message back to the resource provider computer 106 via the processing network computer 112 and the transmitting computer 110 .

[0071] At the end of the day or at any other suitable time period, a clearing and settlement process between the transmitting computer 110, the processing network computer 112, and the authorized entity computer 118 may be performed.

[0072] Other embodiments are possible. In an alternative embodiment, the processing cloud computer 114 may tokenize the captured access data and then replace the access data with the token (an example of a derivative of the access data).

[0073] In another embodiment, the password generated by the user device may be verified by the processing network computer 112 on behalf of the authorization entity computer 118 .

[0074] Although the present invention has been described in the context of card not present transactions with e-commerce merchants, embodiments of the present invention may be applied to other contexts. For example, embodiments of the present invention may be used for person-to-person push payment transactions.

[0075] Figure 2 A block diagram of a processing cloud computer 200 is shown according to an embodiment. The processing cloud computer 200 may include a processor 202, which may be coupled to a computer readable medium 204, a data storage device 206, and a network interface 208.

[0076] The computer-readable medium 204 may include several software modules, including a cryptographic module 204A, a tokenization module 204B, and a communication module 204C.

[0077] In an embodiment of the present invention, the cryptographic module 204A may include any suitable encryption / decryption algorithm for encrypting data. Suitable data encryption / decryption algorithms may include DES, triple DES, AES, etc. The encryption / decryption module may also store encryption keys that may be used with such encryption / decryption algorithms. The cryptographic module 204A may utilize symmetric or asymmetric encryption techniques to encrypt and / or verify data. The keys that may be used by the cryptographic module 204A may be securely stored in the data storage device 606.

[0078] The tokenization module 204B may include code that causes the processor 202 to provide an access token. For example, the tokenization module 204B may contain logic that causes the processor 202 to generate a payment token and / or associate a payment token or a password with a set of user credentials. The tokenization module 204B may include code that causes the processor 202 to validate a token request before providing a payment token. A token record may then be stored in a token record database indicating that the token is associated with a certain user or set of credentials.

[0079] The communication module 204C may include code that causes the processor 202 to generate messages, forward messages, reformat messages, and / or otherwise communicate with other entities.

[0080] Another module that may reside in the computer-readable medium 204 may include a unique interaction identifier module for generating a unique identifier for an interaction.

[0081] The computer-readable medium 204 may include code that can be executed by the processor 202 to perform operations, the operations including: receiving encrypted data from a user device operated by the user via a security kernel on a communication device after the user interacts with the resource provider computer in an interaction; decrypting the encrypted data to recover access data and a password; transmitting an interaction identifier and access data or a derivative of the access data to the resource provider computer, wherein the resource provider computer subsequently transmits an authorization request message including the access data or a derivative thereof to the authorization entity computer; transmitting the password to the authorization entity computer, wherein the authorization entity computer receives the authorization request message and the password, and authorizes or denies the interaction based on the data in the authorization request message and the password.

[0082] The data storage device 206 may store the token and its associated credentials in a database. It may also store addresses associated with the authentication server computer, the authorization entity computer, and the resource provider computer. The data storage device 206 may store the data in, for example, an Oracle database. TM Databases and other databases.

[0083] Figure 3 A communication device 300 is shown in accordance with an embodiment. The communication device 300 may include device hardware 304 coupled to a system memory 302 .

[0084] Device hardware 304 may include a processor 306, a short-range antenna 314, a long-range antenna 316, an input element 310, a user interface 308, and an output element 312 (which may be part of the user interface 308). Examples of input elements may include a microphone, a keypad, a touch screen, a sensor, etc. Examples of output elements may include a speaker, a display screen, and a tactile device. Processor 306 may be implemented as one or more integrated circuits (e.g., one or more single-core or multi-core microprocessors and / or microcontrollers) and is used to control the operation of communication device 300. Processor 306 may execute various programs in response to program code or computer-readable code stored in system memory 302, and may maintain multiple concurrently executed programs or processes.

[0085] The long-range antenna 316 may include one or more RF transceivers and / or connectors that can be used by the communication device 300 to communicate with other devices and / or connect to an external network. The user interface 308 may include any combination of input and output elements to allow a user to interact with the communication device 300 and invoke the functionality of the communication device. The short-range antenna 314 may be configured to communicate with external entities via a short-range communication medium (e.g., using Bluetooth, Wi-Fi, infrared, NFC, etc.). The long-range antenna 316 may be configured to communicate over the air with a remote base station and a remote cellular or data network.

[0086] The system memory 302 may be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g., DRAM, SRAM), or any other non-transitory storage media or combinations of media. The system memory 302 may store computer code that may be executed by the processor 306 for performing any of the functions described herein.

[0087] System memory 302 may also store application 302A, secure kernel module 302B, authentication module 302C, credentials / token 302D, and operating system 302E. Application 302A may include instructions or codes for initiating and conducting transactions with external devices (e.g., resource provider computers). Secure kernel module 302B may include code that can be executed by processor 306 to capture access data and passwords from user devices and encrypt them. It may also include code that can be executed by processor 306 to transmit encrypted data. It may also include code that can be executed by processor 306 to enable communication device 300 to receive data from external user devices. Authentication module 302C may include code that can be executed by processor 306 to authenticate users. This may be performed using user secrets (e.g., passwords) or user biometrics.

[0088] The system memory 302 may also store credentials and / or tokens 302D. The credentials may also include information identifying the communication device 300 and / or a user of the communication device 300.

[0089] Figure 4 A user device 400 in the form of a display card. The user device 400 includes a substrate 400A, such as a plastic substrate. A contactless element 400B for interfacing with a data access or data transfer device can be on the user device substrate 400A or embedded in the user device substrate. The contactless element 400B may include a chip and may include the ability to transmit and transfer data using near field communication (NFC) technology or other short-range communication technologies. The user device 400 may be assigned to a user by an authorized entity such as an issuer bank.

[0090] User equipment 400 can also include memory 400C, which can store user information such as account number, expiration date and user name. In some cases, memory 400C can include security element, and / or can also store information such as access data. The information in memory 400C can be transferred to another device by user equipment 400 using contactless element interface 400B. Information can also be printed or imprinted on substrate 400A. Magnetic stripe 400D can also be provided on substrate 400A.

[0091] Figure 5 A message exchange process 500 is shown between a user device 502 and a communication device 503. The process may be performed in, for example, Figure 1 is used in step S8.

[0092] Prior to performing the message exchange process, the authorized entity (e.g., issuer, user's bank, etc.) may initialize the user device 502 with several data fields (e.g., as part of the personalization process of the user device 502). The user device 502 may be configured with one or more applications. In some embodiments, the issuer may assign priorities to these applications. For example, an application on the user device 502 (e.g., a U.S. payment or access application) may be associated with a specific transaction processing protocol, and a high priority may be assigned to the application. The user device 502 may store additional sensitive user device data, such as PAN (primary account number), CVV, expiration date, and any other suitable information.

[0093] At step S504, the user may then use the user device 502 to initiate a transaction with the communication device 503. The user may hold the user device 502 near the communication device 503 so that the two devices can detect each other. The user may present (e.g., tap, hold nearby, etc.) the user device 502 to the communication device 503 to exchange data with the communication device 503.

[0094] At step S506, during a process for exchanging data between the user equipment 502 and the communication device 503, the user equipment 502 may provide a list of available applications including at least a first application and a second application to the communication device 503. In the interaction, the communication device 503 may send an available application request message to the user equipment 502. The available application request message may request information about which applications (e.g., a list of application identifiers (AIDs)) are available on the user equipment 502. In some embodiments, the available application request message may be in the form of a SELECT PPSE command.

[0095] At step S508, the user device 502 then identifies available applications including at least the first application and the second application from the memory of the user device 502. The user device 502 then provides (e.g., transmits) an initial or first available application response message to the communication device 503. The available application response message includes a list of applications (e.g., a list of AIDs) available at the user device 502 in a SELECT PPSE response in response to receiving the SELECT PPSE command. The available application response message may include an application list, the application list including at least the first application and the second application. The application list may be sorted according to the first priority and the second priority to indicate a preference of the communication device 503 to use the first application rather than the second application to process the interaction.

[0096] As shown at step S510, the communication device 503 selects an application from the received application list and then transmits the selection of the application to the user device 502 in a Select AID message (step S512). In some embodiments, the communication device 503 selects the highest application in the list (e.g., the application associated with the highest priority, in this case, the first application). If the interaction is a payment transaction, this process for application selection can comply with payment standards such as EMV 1.0 and / or EMV 2.0.

[0097] At step S516 , the user device 502 may transmit a request for terminal transaction data (eg, a PDOL request).

[0098] At step S518, in response to the request for terminal transaction data, the communication device 503 may send the transaction data to the user device 502. In some embodiments, the communication device 503 may send such data in a Processing Option Data Object List (PDOL) message to the user device 502. The selected application (e.g., the first application or the international application) may receive the data via the PDOL message.

[0099] At step S534, after receiving the application selection message at step S518, the user device 502 may send a terminal transaction data request to request transaction data from the communication device 503. In some embodiments, the terminal transaction data request may be in the form of a "select AID response" and may include an application identifier (AID) and file control information (FCI) associated with the selected AID as a dedicated file name. The terminal transaction data request may include a list of transaction data identifiers to request appropriate data from the communication device 503. The list of transaction data identifiers may be in the form of a processing option data object list (PDOL).

[0100] The transaction data requested by the user device 502 for the transaction may include terminal processing options (TPO), amount, and other information. In addition, the transaction data may include one or more dynamic data elements (eg, random numbers).

[0101] At step S536, after receiving the terminal transaction data request from the user device 502, the communication device 503 may send the terminal transaction data to the user device 502. In some embodiments, the terminal transaction data may be sent in the form of a Get Processing Options (GPO) command and may include the terminal transaction data requested in a Processing Options Data Object List (PDOL). The terminal transaction data (e.g., Transaction Processing Options (TPO)) may include a TPO indicator, which indicates which transaction data types the communication device 503 supports.

[0102] Once the user device 502 receives the terminal transaction data, the user device 502 may obtain the relevant credentials (e.g., card credentials) and may send a set of transaction processing information to the communication device 503 ( Figure 5 In some embodiments, the transaction processing information may be sent in the form of a Get Processing Options (GPO) response. In some embodiments, the transaction processing information may include one or more application file locators (AFLs) that may be used by the communication device 503 as a file address to read account data stored on the user device 502, and an application exchange profile (AIP) that may be used to indicate the capabilities of the payment application.

[0103] The transaction processing information may include any transaction credentials, including a cryptogram generated using the transaction information, Track-2 equivalent data (e.g., PAN, expiration date), and / or additional data. For example, a cryptogram may be generated using transaction information, which may include a dynamic data element (e.g., a random number), a user device 502 identifier (e.g., PAN), and optionally other information, such as a session identifier, a value such as a zero dollar amount, and a transaction counter. The transaction processing information may also include issuer application data (IAD), a form factor indicator (FFI), a card transaction qualifier (CTQ), cryptographic information data (CID), and / or an application PAN sequence number (PAN). In some embodiments, the issuer application data (IAD) may include a length indicator indicating the length of the IAD, a cryptographic version number (CVN) indicating the version of the transaction cryptogram, a derived key indicator (DKI) that may be used to identify a master key (e.g., a master key associated with the issuer), and / or a card verification result (CVR).

[0104] In some embodiments, after the communication device 503 receives the transaction processing information, in step S538, the communication device 503 may send an account data request to the user device 502 to read additional account data that may be stored on the user device 502. In some embodiments, the account data request may be in the form of a "read record" command and may include an application file locator (AFL) indicating the location of the account data that the communication device 503 is attempting to read. The AFL included in the account data request may correspond to the AFL in the transaction processing information provided from the user device 502 to the communication device 503.

[0105] In response to receiving the account data request from the communication device 503, in step S540, the user device 502 may send the account data stored at the location indicated by the AFL to the communication device 503. In some embodiments, the account data may be sent in the form of a "read record" response. The account data may include, for example, application usage controls indicating the issuer's restrictions on the use and services allowed by the application, the cardholder's name, customer-specific data, the issuer country code, and / or other account-related data accessible at the AFL location and stored in the user device 502. The communication device 503 may then use the account data, transaction processing information, and other data received by the communication device 503 in the previous steps to complete the payment transaction.

[0106] At some point, the user may remove the user device 502 from the communication device 503, or otherwise disengage the user device 502 from the communication device 503. After removal or disengagement, the user device 502 may be powered off, which also powers off the volatile memory of the user device 502, thereby clearing the flag previously set on the user device 502.

[0107] Any software component or function described in this application can be implemented as a software code executed by a processor using any suitable computer language, such as Java, C++ or Perl using conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer-readable medium such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium (such as a hard drive or floppy disk), or an optical medium (such as a CD-ROM). Any such computer-readable medium can reside on or within a single computing device, and can exist on or within different computing devices within a system or network.

[0108] The above description is illustrative and not restrictive. Many variations of the present invention may become apparent to those skilled in the art after consulting this disclosure. Therefore, the scope of the present invention may be determined not with reference to the above description, but with reference to the pending claims and their full scope or equivalents.

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

[0110] Unless specifically indicated to the contrary, the term "a," "an," or "the" is intended to mean "one or more."

[0111] All patents, patent applications, publications, and descriptions mentioned above are incorporated by reference in their entirety for all purposes. No admission is made that they are prior art.

Claims

1. A method comprising: receiving, by the processing cloud computer, encrypted data from a user device operated by the user via a security kernel on a communication device after the user interacts with the resource provider computer in an interaction; decrypting the encrypted data by the processing cloud computer to recover access data and password; transmitting, by the processing cloud computer, an interaction identifier and the access data or a derivative of the access data to the resource provider computer, wherein the resource provider computer subsequently transmits an authorization request message including the access data or a derivative thereof to an authorization entity computer; as well as The password is transmitted from the processing cloud computer to the authorization entity computer, The authorization entity computer receives the authorization request message and the password, and authorizes or denies the interaction based on data in the authorization request message and the password. 2 . The method of claim 1 , wherein the access data or the derivative of the access data is the access data. The method of claim 2 , wherein the access data comprises a primary account identifier.

4. The method of claim 1, wherein the resource provider computer operates a host site and the user interacts with the host site in the interaction.

5. The method of claim 4, wherein the host site provides a value for the interaction, and wherein the password is based on at least the access data and the value.

6. The method of claim 1, wherein the security kernel and the processing cloud computer share a first set of zone encryption keys, and the resource provider computer and the processing cloud computer share a second set of zone encryption keys.

7. The method of claim 1, wherein the communication device further comprises an application, wherein the communication device interacts with the resource provider computer via the application. The method of claim 7 , wherein the application is a web browser.

9. The method of claim 7, wherein the application is a resource provider application and the resource provider computer is an application server computer supporting the resource provider application.

10. The method of claim 1, wherein the password is transmitted to the authorization entity computer in communication via an authentication server computer. The method of claim 10 , wherein the communication further comprises the access data.

12. The method of claim 11, wherein the authentication server computer, the processing cloud computer, or the authorization entity computer authenticates the user or the communication device after receiving the password.

13. The method of claim 1, wherein the authorization entity computer validates the password prior to authorizing the interaction.

14. A method according to claim 13, wherein the authorization entity computer verifies the password by generating another password by encrypting the access data or a derivative thereof and a value in the authorization request message, and comparing the password with the other password to determine whether there is a match.

15. A processing cloud computer, comprising: processor; as well as A computer readable medium comprising code executable by the processor to perform operations comprising: receiving, via a security kernel on a communications device, encrypted data from a user device operated by the user after the user interacts with the resource provider computer in an interaction; decrypting the encrypted data to recover the access data and password; transmitting an interaction identifier and the access data or a derivative of the access data to the resource provider computer, wherein the resource provider computer subsequently transmits an authorization request message including the access data or a derivative thereof to an authorization entity computer; and transmitting said password to said authorization entity computer, The authorization entity computer receives the authorization request message and the password, and authorizes or denies the interaction based on data in the authorization request message and the password.

16. A method comprising: Receiving, by the authorization entity computer, an authorization request message from the processing network computer; receiving, by the authorization entity computer, a password from a processing cloud computer in communication, wherein the password is obtained from a user device operated by a user via a security kernel on a communication device; Verifying the password by the authorization entity computer; authorizing, by the authorization entity computer, the authorization request message based in part on the validation of the password; as well as In response to the authorization, an authorization response message is transmitted by the authorization entity computer to the processing network computer.

17. The method of claim 16, wherein the password is received from the processing cloud computer via an authentication service computer.

18. The method according to claim 16, further comprising: The authorization request message is matched to the communication using a unique interaction identifier.

19. The method of claim 16, wherein the user device is a card and the communication device is a tablet, a mobile phone or a laptop.

20. The method of claim 16, wherein the authorization entity computer is an issuer computer.

Images