Secure remote payment transaction processing including consumer authentication

Abstract

The present disclosure relates to secure remote payment transaction processing including consumer authentication. Embodiments relate to methods, devices, computer-readable media, and systems for securely processing remote transactions. One embodiment relates to a method of processing a remote transaction initiated by a communication device, including a server computer receiving a payment request including encrypted payment information encrypted using a first key. The encrypted payment information includes security information. The method further includes decrypting the encrypted payment information using a second key, obtaining an authentication response value for the remote transaction from an authentication computer associated with an issuer, updating the decrypted payment information to include the authentication response value, re-encrypting the decrypted payment information using a third key, and sending a payment response including the re-encrypted payment information to a transaction processor. The transaction processor decrypts the re-encrypted payment information using a fourth key and initiates a payment transaction using the decrypted payment information.

Description

[0001] This application is a divisional application of Chinese patent application number 201480063714.5, entitled "Secure Remote Payment Transaction Processing Including Consumer Authentication".

[0002] Cross-reference to related applications

[0003] This application relates to and claims priority to U.S. Provisional Application No. 61 / 880,802, filed September 20, 2013, which is incorporated herein by reference in its entirety for all purposes. This application also relates to U.S. Non-Provisional Application No. 14 / 332,245, filed July 15, 2014, and U.S. Non-Provisional Application No. 14 / 461,227, filed August 15, 2014, which are incorporated herein by reference in their entirety for all purposes. Technical Field

[0004] This disclosure relates to payment transaction processing, and more particularly to secure remote payment transaction processing. Background Technology

[0005] Traditional remote transactions have limited security features and a high risk of fraud because consumers are typically not at the merchant's or service provider's location to verify that payment credentials have not been stolen, intercepted, or misused by malicious third parties. Accordingly, there is a need to improve the security of remote transactions initiated from communication devices.

[0006] Furthermore, using untrusted merchant applications on communication devices (e.g., mobile devices) to perform remote payments can lead to serious data security issues because it is difficult to determine whether the application is malware or otherwise attempting to steal sensitive information. Accordingly, there is a need for a secure remote transaction processing system that efficiently and securely authenticates the device and the user associated with it during remote transactions so that sensitive information can be protected from malicious or untrusted applications.

[0007] Furthermore, while systems enabling remote payment transactions based on secure elements can provide device authentication and verification, these systems cannot authenticate the consumer or user associated with the communication device initiating the payment transaction during the authentication process. Consequently, stolen and / or hacked devices could still be used to execute fraudulent transactions, and system resources could be used to process fraudulent transactions and perform multiple separate authentication processes for users, devices, etc. Therefore, there is a need for an authentication process that provides user and device authentication in a highly efficient manner.

[0008] Furthermore, traditional e-commerce transaction systems that allow user authentication via username and password or challenge-response authentication fail to provide account issuers or service providers with direct control over the authentication or authorization processes for remote transactions. Therefore, the issuer associated with the account used in a remote transaction may not be given the level of control and risk analysis that account issuers and other service providers might expect. Thus, a system is needed that allows the issuer associated with the remote transaction to have direct control over the authentication process.

[0009] The various embodiments of the present invention individually and collectively address these and other problems. Summary of the Invention

[0010] Various embodiments of the present invention relate to methods, apparatus, computer-readable media, and systems for securely processing remote transactions, including consumer authentication, using communication devices. For example, embodiments of the present invention allow consumers to initiate and process remote payment transactions initiated through merchant websites or merchant applications using mobile devices that include secure and sensitive payment credentials. Instead of requiring consumers to provide account numbers and expiration dates using a keypad or retrieving this information from insecure storage, the merchant website or merchant application can utilize a secure element-based mobile payment application to obtain payment credentials (e.g., account number and expiration date) from the communication device. Therefore, the embodiments provide a secure process for transmitting sensitive payment information and authenticating users and payment applications while protecting sensitive information from untrusted, insecure, and / or potentially malicious mobile applications (e.g., merchant applications).

[0011] Furthermore, the embodiments include the use of security information for remote transactions initiated via a payment application on a communication device, including chip-based security values ​​(e.g., passwords) for authenticating the device and user authentication data (e.g., personal identification number (PIN), password, passcode, etc.) for authenticating the user. Therefore, the embodiments provide additional security for traditional e-commerce or remote payment transactions. Thus, the embodiments provide a more secure and robust remote payment transaction system. In this way, the embodiments enhance the security level of "cardless" transactions by providing verifiable security information in transactions that typically do not have the capability to include such security features.

[0012] One embodiment of the present invention relates to a method for processing a remote transaction initiated by a mobile device. The method includes a server computer receiving a payment request including encrypted payment information. The encrypted payment information includes security information and is encrypted using a first encryption key. The method further includes using a second encryption key to decrypt the encrypted payment information and obtaining an authentication response value for the remote transaction from an authentication computer associated with an account issuer. The authentication computer verifies the security information before providing the authentication response value to the server computer. The method further includes the server computer updating the decrypted payment information to include the authentication response value, reencrypting the decrypted payment information using a third encryption key, and sending a payment response including the reencrypted payment information to a transaction processor associated with a communication device. The transaction processor uses a fourth encryption key to decrypt the reencrypted payment information and uses the decrypted payment information to initiate a payment transaction.

[0013] Another embodiment of the invention relates to a server computer comprising a processor and a computer-readable medium coupled to the processor. The computer-readable medium includes code executable by the processor for performing a method of processing a remote transaction. The method of processing a remote transaction includes the server computer receiving a payment request including encrypted payment information. The encrypted payment information includes security information and is encrypted using a first encryption key. The method further includes using a second encryption key to decrypt the encrypted payment information and obtaining an authentication response value for the remote transaction from an authentication computer associated with an account issuer. The authentication computer verifies the security information before providing the authentication response value to the server computer. The method further includes the server computer updating the decrypted payment information to include the authentication response value, reencrypting the decrypted payment information using a third encryption key, and sending a payment response including the reencrypted payment information to a transaction processor associated with a communication device. The transaction processor uses a fourth encryption key to decrypt the reencrypted payment information and uses the decrypted payment information to initiate a payment transaction.

[0014] Another embodiment of the invention relates to a system for processing remote transactions. The system includes a communication device configured to send a payment request including encrypted payment information to a server computer. The encrypted payment information includes security information and is encrypted using a first encryption key. The system further includes a server computer configured to receive a payment request including the encrypted payment information. The server computer is further configured to decrypt the encrypted payment information using a second encryption key and to obtain an authentication response value for the remote transaction from an authentication computer associated with an account issuer. The server computer is further configured to update the decrypted payment information to include the authentication response value, reencrypt the decrypted payment information using a third encryption key, and send a payment response including the reencrypted payment information to a transaction processor associated with the communication device. The transaction processor is configured to decrypt the reencrypted payment information using a fourth encryption key and to initiate a payment transaction using the decrypted payment information. The system further includes an authentication computer configured to receive an authentication request including security information from the server computer, verify the security information, generate an authentication response including the authentication response value, and send the authentication response to the server computer.

[0015] These and other embodiments of the invention are described in more detail below. Attached Figure Description

[0016] Figure 1 A block diagram of an exemplary system for performing remote transactions using a merchant application associated with a payment processing network and a mobile device, according to some embodiments of the present invention, is shown.

[0017] Figure 2 A block diagram of an exemplary mobile device that can be used with some embodiments of the present invention is shown.

[0018] Figure 3 A block diagram of an exemplary remote key manager configured to manage two-factor authentication for remote transactions is shown according to some embodiments of the present invention.

[0019] Figure 4 A block diagram of certain components of an exemplary payment processing network configured to manage authentication requests and responses for remote transactions and to process secure remote transactions, according to some embodiments of the present invention, is shown.

[0020] Figure 5 A flowchart illustrating an exemplary method for using a certificate authority to provide merchant public / private key pairs and merchant application certificates, according to some embodiments of the present invention, is shown.

[0021] Figure 6A flowchart illustrating an exemplary method for processing remote transactions using a remote key manager, a payment processing network, and a merchant application on a mobile device, according to some embodiments of the present invention, is shown.

[0022] Figure 7 A block diagram of an exemplary computer device is shown. Detailed Implementation

[0023] Various embodiments of the present invention relate to systems and methods for securely processing remote transactions initiated by an untrusted merchant application on a communication device. The untrusted application may be a legitimate application, but due to the insecure or potentially insecure environment in which it operates, it may not be trusted by a secure application or a trusted execution environment that stores or controls access to sensitive information used for the transaction (or multiple transactions). Various embodiments provide a secure system that protects sensitive payment information stored in the secure memory of a mobile device, verifies the merchant application before providing the sensitive information, securely and efficiently authenticates both the user and the device associated with the remote transaction, and allows the sensitive payment information to be securely transmitted for the execution of remote payment transactions using the communication device.

[0024] When conducting remote e-commerce transactions (i.e., e-commerce) on a communication device, consumers provide payment credentials and other sensitive information to the merchant's website or web server so that the merchant can identify and initiate payment for the transaction. Typically, consumers can type or otherwise enter their Primary Account Number (PAN), expiry date, and card confirmation value (e.g., CVV2) into their mobile device, which then sends this information to the merchant's server. However, this method is insecure and can lead to fraudulent transactions. For example, without proper authorization, the merchant has no way of knowing whether the consumer is trustworthy, possesses the underlying payment device, or has obtained the PAN, expiry date, and card confirmation value.

[0025] Various embodiments of the present invention provide an end-to-end secure authentication process between a communication device (e.g., a mobile device) and an authentication server through a single interface system for processing remote transactions. An authentication computer associated with the account issuer can directly receive authentication data from the communication device, verify the authentication data, and authorize the requested transaction (or other operation) associated with the remote transaction through a secure and efficient communication architecture. Furthermore, the authentication data can be two-factor authenticated by including both device (e.g., a secure value generated using a shared secret) and user authentication data (e.g., a personal identification number, password, etc.) in a single communication and authentication process.

[0026] Therefore, before initiating a remote transaction, each embodiment allows authentication of security values ​​associated with the device and user authentication data associated with the user, as well as the submission of other payment data to the payment processing network and / or account issuer for confirmation. Before initiating a remote transaction through the payment processing network, an authentication response can be provided by the authentication computer, and the authentication response value can be embedded in the payment data for transaction processing. Therefore, during transaction processing, the authentication response value can be verified by the payment processor and / or issuer as an additional security measure for remote transaction processing.

[0027] According to embodiments of the present invention, a merchant web server computer or merchant application can securely obtain account information from a mobile payment application of a communication device that securely stores account information. Furthermore, because transactions are processed using a payment application that can be configured to provide security information along with payment credentials, remote transactions can include highly secure dynamic chip-based security data (e.g., dynamic passwords) during the remote transaction process. Correspondingly, during e-commerce transactions where merchants typically cannot receive highly secure chip-based security data due to consumers entering account information and / or lack of access to the security chip embedded in a smart card or mobile device, embodiments of the present invention provide dynamic authentication information and other chip data for verification during transaction processing.

[0028] Furthermore, the embodiments allow the merchant computer to securely receive account credentials, user authentication data, and device security information from the payment application during remote payment transactions. Accordingly, the remote merchant server computer can receive sufficient data to construct a "card presence" chip transaction authorization request message, which provides a higher level of security than typical remote transactions.

[0029] The embodiments of the present invention offer several advantages. For example, they improve the security of payment transactions using untrusted or unknown merchant applications on mobile devices. In some embodiments, a remote key manager, mobile gateway, payment processing network, mobile wallet provider, or any other third-party system can be used to verify the merchant application associated with the merchant certificate, determine the merchant key associated with the verified merchant application, decrypt payment information, and re-encrypt the payment information using the trusted merchant's public key. This prevents unauthorized applications or devices from accessing sensitive data, as payment information is unreadable without a trusted transaction processor encryption key (e.g., merchant private key, merchant application private key, acquirer private key, etc.).

[0030] Furthermore, each embodiment further improves the security of remote payment transactions initiated in insecure communication device environments by performing two-factor authentication on the user and device (e.g., payment application) during and before initiating the remote transaction.

[0031] Furthermore, due to the multiple key exchanges involved in remote transaction processing, sensitive information can be protected at all times while being transmitted or delivered to the destination entity. Accordingly, various embodiments provide secure communication processes for transmitting sensitive information related to remote transactions to allow for the protection of sensitive information, which may be static and reusable in future transactions (e.g., static account identifiers, expiration dates, etc.).

[0032] Furthermore, the embodiments provide a more efficient method for performing both user and device authentication than systems that include separate authentication processes. For example, conventional remote transaction authentication systems that allow users to be authenticated by account issuers or payment processors require users to verify their identity through separate or parallel processes during e-commerce transactions. For instance, a consumer might log into an online account and submit a password along with their payment credentials. This is inefficient for the authentication system and cumbersome for the consumer. In contrast, the embodiments of the present invention allow for user and device authentication in an easy and efficient manner.

[0033] Furthermore, the embodiments require less integration between the communication device and the issuing system because they provide a single point of contact for the communication device, rather than requiring the communication device to be redirected to each access control server or authentication server associated with different account issuers, as previous systems might have done. Accordingly, the embodiments of the invention offer the advantage of a single secure integration point with a remote key manager, which can then use an authentication computer to authenticate remote transactions and return the authentication results directly to the communication device.

[0034] Therefore, the system avoids using redirection schemes that direct communication devices to authentication computers for each issuer or service provider. Redirection to multiple authentication computers raises numerous integration problems, as each specific authentication computer associated with different issuers or other service providers has different communication protocols, security permutations, interface command sets, etc. Therefore, in various embodiments of the invention, the mobile payment application and / or remote transaction application of the communication device can implement a single set of APIs or other commands to initiate the authentication process. Consequently, the integration of the communication device with the remote key manager is easier to manage and requires fewer updates, changes, and modifications to the remote transaction application.

[0035] Therefore, embodiments of the present invention provide a secure remote transaction processing system that allows (1) verification of untrusted or unknown merchant applications before providing sensitive information, and (2) a secure communication scheme for transmitting information to a single integration point to verify and authenticate (i) the consumer and (ii) the device before initiating a transaction through a payment processing network. Thus, embodiments provide a more efficient, secure, and easily implemented method for performing secure remote payment transactions, including authenticating the consumer through a single authentication process.

[0036] Furthermore, the embodiments also provide a more secure payment system by allowing the use of highly secure and non-reproducible information during transactions. For example, a dynamic password or dynamic value provided during a transaction allows merchants to have a higher level of confidence that the consumer is indeed authorized to use the account to execute the transaction. As a result, payment processing networks, issuers, and merchants will handle fewer fraudulent transactions and payment refusal issues.

[0037] Finally, the embodiments are more convenient for consumers and users because the system allows consumers to initiate and process transactions using payment information already present on the mobile device (e.g., account information). Previous remote transactions required consumers to manually enter payment information or use information not stored in secure storage. Therefore, the embodiments provide consumers with a safer and more convenient method to initiate transactions from their mobile devices.

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

[0039] "Remote transactions" can include any transaction in which one party is physically separated from the other by a distance and / or by devices. For example, remote transactions can include "cardless transactions," e-commerce, or other online transactions performed via communication between two or more devices. For example, remote transactions can include multiple devices in different locations or where both parties (e.g., the merchant and the consumer) do not use the same devices to complete the transaction. Additionally, remote transactions can include in-store transactions completed without using the merchant's point-of-sale equipment (i.e., access devices), but rather by the consumer using their mobile device to communicate with a remote (or local) merchant server computer configured to process remote transactions. Traditionally, remote transactions have a higher risk of fraud because they do not allow the payee the opportunity to identify the payer or otherwise ensure the legitimacy of the payment they are receiving, since the parties are not in the same location during the transaction (such as in "card-present" or in-store transactions). Local, card-present, face-to-face, or in-store transactions can include a transaction in which two or more parties are in the same location, using the same transaction device, or by instructing an existing individual or entity to authenticate the payer and / or payee.

[0040] Additionally, remote transactions can include any type of transaction. For example, remote transactions can include payment transactions (e.g., transactions associated with the exchange of goods or services for monetary value), non-payment transactions (e.g., authentication transactions, account provisioning transactions, or any other transactions that do not involve the exchange of monetary value for goods or services), and / or any other type of transaction associated with communication devices, mobile applications, payment applications, payment processing networks, issuers, and / or any other entity within the transaction processing system.

[0041] A "payment request" may include a message containing a request to process or initiate a payment. For example, a payment request may be sent from a mobile device associated with a consumer regarding a purchase transaction related to goods or services offered by a merchant. The payment request may include any information related to the transaction, including payment information (e.g., account identifier, personal information, etc.), transaction information (e.g., merchant information, goods being purchased, etc.), device information (e.g., mobile device phone number, secure element identifier, etc.), routing information (e.g., destination computer's Internet Protocol (IP) address, destination computer identifier, bank identification number (BIN), etc.), and any other information related to the payment transaction. For example, a payment request may include encrypted payment information for the transaction and may be sent to a third-party computer configured to authenticate the payment request, verify a public key certificate, decrypt the encrypted payment information, extract the public key from the verified certificate, reencrypt the decrypted payment information, and send the reencrypted payment information to a transaction processor to initiate the payment transaction. Accordingly, the payment request may include any information related to the secure process for transmitting sensitive data to a merchant server used to process remote transactions.

[0042] "Payment information" may include any relevant information used to execute a payment. For example, payment information may include any sensitive account information and / or personal information that can be used to identify and / or authenticate a consumer account at the issuing party. Further, in some embodiments, payment information may also include merchant information, consumer information, mobile device information, routing information, or any other relevant information that can be used to control, manage, and transmit payment transactions. Thus, payment information may include both sensitive and non-sensitive information. Additionally, payment information may also include a portion of account information, personal information, etc., that can be used to execute a transaction. For example, payment information may include sensitive information associated with a transaction or account and may be sent along with other non-sensitive information that may not be considered payment information (e.g., transaction amount, etc.).

[0043] A "payment credential" may include any information that allows the processor to identify, confirm, and / or process payment transactions using a consumer's account. For example, a payment credential may include an account identifier (e.g., a primary account number (PAN)), a token (e.g., an account identifier substitute), an expiration date, a card confirmation value (e.g., CVV, CVV2, dCVV, etc.), a dynamic password or dynamic value (e.g., dynamic authentication data), personal information associated with the account (e.g., an address, etc.), an account alias, or any other relevant information.

[0044] In some embodiments, payment credentials may be stored in a secure memory on a mobile device. The secure memory on the mobile device may be configured such that data stored in the secure memory is not directly accessible to external applications, and that a mobile payment application associated with the secure memory can access the payment credentials stored in the secure memory. Accordingly, a merchant application may connect to the mobile payment application or to a remote transaction application or other applications to connect with the mobile payment application to access the payment credentials stored in the secure memory. In some embodiments, a software development kit (SDK), application programming interface (API), or other third-party programming code or modules may be accessed to request payment credentials from the mobile payment application. Further, in some embodiments, the secure memory may be configured such that payment credentials or any other payment information can be provided in encrypted form using a session-derived key based on a shared master derived key (MDK) associated with the issuer of the payment credentials stored in the secure memory on the mobile device. Additionally, a valid digital or public key certificate may be present for applications, SDKs, or APIs to access the secure memory (e.g., a secure element).

[0045] "Transaction information" may include any data associated with a transaction. For example, transaction information may include the transaction amount, transaction time, transaction date, merchant information (e.g., registered merchant identifier, address, merchant computer IP address, etc.), and product information (e.g., serial number, product name, or other identifiers, etc.). Transaction information may be provided by the merchant server computer to a communication device (e.g., a mobile device) before or after a consumer initiates a payment transaction through a merchant application. In some embodiments, transaction information may be used to identify a specific merchant associated with a transaction using the merchant information included within the transaction information.

[0046] "Merchant information" may include any information associated with a merchant, payee, service provider, producer, or other dependent party in a transaction. For example, merchant information may include a merchant identifier determined during registration with a remote payment service, remote key manager, payment processing network, or other transaction processing entity associated with a remote transaction processing system. In some embodiments, the merchant identifier may be used to identify the registered merchant computer public key, merchant application public key, and / or acquirer public key associated with the transaction.

[0047] "Encrypted payment information" can include any payment information that is difficult for a single party to understand, thus preventing unauthorized access to the payment information. For example, encrypted payment information cannot be read by a recipient who does not have a shared secret or a designated encryption key. In this way, encrypted payment information can be made difficult to understand through a reversible and repeatable process, allowing two entities to share information using a shared secret or encryption key, while unauthorized entities cannot understand or access sensitive payment information or sensitive payment credentials within the payment information (unless they have access to the shared secret or encryption key).

[0048] Additionally, in some embodiments, encrypted payment information may include any combination of encrypted sensitive information and unencrypted, less sensitive or insecure information. For example, in some embodiments, encrypted payment information may include encrypted payment credentials (e.g., sensitive account identifiers and expiration dates) and unencrypted transaction information (e.g., transaction amount, product identifier, etc.). In other embodiments, encrypted payment information may include all related encrypted transaction information. For example, in some embodiments, encrypted payment information may include both encrypted payment credentials and encrypted transaction information.

[0049] In some embodiments, encrypted payment information may be generated by a mobile payment application on a mobile device, such that the mobile payment application may have an encryption key (e.g., a third-party public key) for encrypting stored or received payment credentials and / or other payment information used for transactions. For example, the mobile payment application may store a third-party public key. This third-party public key may be paired with a third-party private encryption key that may be securely stored on a remote key manager, mobile gateway, payment processing network, mobile wallet provider, or any other third party configured to process remote payment transactions. The third-party private key can be used to decrypt the encrypted payment information and allow the third party to further encrypt secure payment information using the public key of a designated transaction processor. Accordingly, the encrypted payment information can be used to allow secure remote transaction processing. Additionally, the third-party encryption key may include a symmetric encryption key, and the key is not limited to a public / private key pair.

[0050] "Decrypted payment information" can include payment information that has been transformed from an incomprehensible state to an incomprehensible state. For example, decrypted payment information can include the result of applying an appropriate encryption key to encrypted payment information to obtain the original payment information. For example, a third party's private key can be applied to encrypted payment information encrypted using a third party's public key to decrypt the encrypted payment information and obtain the underlying payment information. Furthermore, in cases where the encrypted payment information includes both encrypted and unencrypted information, the decrypted payment information can be obtained by decrypting the encrypted portion without decrypting the unencrypted portion.

[0051] "Re-encrypted payment information" can include any payment information that has been decrypted at least once and then rendered incomprehensible to prevent unauthorized access. For example, re-encrypted payment information may be encrypted using a different encryption key or algorithm than the originally encrypted payment information, or otherwise rendered incomprehensible to unauthorized entities. For instance, decrypted payment information, encrypted and decrypted using a third party's public and private keys (or a third party's symmetric encryption key), can be re-encrypted using the transaction processor's public key (e.g., merchant public key, merchant application public key, acquirer public key, etc.) and sent to the transaction processor. Thus, the same information (e.g., payment information) can be encrypted using two different keys that allow two different entities to securely access the underlying information while preventing access to the information by any other entity.

[0052] A "payment response" may include a message that responds to a request to process or initiate a payment. For example, a payment response may be sent from a server computer in response to a shopping request associated with a remote transaction request (which is related to goods or services offered by a merchant). The payment response may include any information related to the transaction, including payment information (e.g., account identifier, personal information, etc.), transaction information (e.g., goods being purchased, merchant information, etc.), device information (e.g., mobile device phone number, secure element identifier, etc.), routing information (e.g., the destination computer's Internet Protocol (IP) address, the destination computer's identifier, bank identification number (BIN), etc.), and any other information related to the payment transaction. For example, the payment response may include re-encrypted payment information encrypted using the transaction processor's public key and may be sent to the transaction processor for further processing. For example, the transaction processor may use its private key to decrypt the re-encrypted payment information and may use the decrypted payment information to initiate a payment transaction. Further, in some embodiments, the payment response may include authentication response information identifying whether the transaction, account, consumer, and / or other entities involved in the transaction have been authenticated.

[0053] A "mobile gateway" can be a server computer or series of server computers configured to communicate with communication devices. For example, a mobile gateway can communicate with mobile devices using over-the-air (OTA) messages or any other communication network and protocol. For example, a mobile gateway can be configured to provide a channel (i.e., a secure channel) for secure communication with mobile devices, through which information can be securely transmitted to and from mobile devices using mobile communication networks, the Internet, and / or any other relevant communication networks.

[0054] A “transaction processor” can include any entity associated with processing a transaction. For example, a merchant, a communication device (e.g., a mobile device, a desktop computer, etc.), a merchant application or other mobile applications on the communication device (e.g., an acquiring application or a payment service provider application), an acquiring computer, a payment processing network, and any other entity in the transaction processing ecosystem can be a transaction processor. In some embodiments, a transaction processor may be associated with specific public keys (e.g., a merchant public key, a merchant application public key, an acquiring public key, etc.) and private keys (e.g., a merchant private key, a merchant application private key, an acquiring private key, etc.) that can be used to encrypt and decrypt payment information during the processing of remote payment transactions.

[0055] Thus, in some embodiments, a transaction processor may include any entity configured to decrypt encrypted (or re-encrypted) payment information and initiate a payment transaction. A payment transaction can be initiated by any suitable means, including transmitting decrypted payment information to another party, or by generating decrypted payment information and / or mapping it to an authorization request message. For example, in some embodiments, a transaction processor may initiate a payment transaction by mapping decrypted payment information to an authorization request message configured to be processed by a payment processing network.

[0056] "Security information" may include any data that can be used to authenticate or verify a party or device. For example, security information may include user authentication data to authenticate the user of a device, account holder, or consumer associated with an account or transaction. Additionally, security information may include security values ​​associated with a device, account, or account issuer.

[0057] "User authentication data" may include any information that can be used to verify a user's identity or permissions. For example, user authentication data may include a personal identification number (PIN), password, password, username, or any other confidential information shared between trusted parties to verify the identity of one or more parties. For example, in some embodiments, user authentication data may include one or more of a personal identification number (PIN), password, password, biometric identifier, or any other unique user information that can be shared and verified by another party. Additionally, user authentication data may also include indications of previously authenticated users (e.g., the results of a user's biometric verification).

[0058] Additionally, security information may include security values ​​that can be used to authenticate devices. A "security value" can include any information that can be used to authenticate a device, account, or payment application as reliable. Security values ​​can be static or dynamic. Furthermore, security values ​​can be generated using shared secrets or other algorithms, and these security values ​​can be verified by another entity or system. For example, security values ​​can include dynamic values ​​that can change over time (e.g., periodically), with each use (e.g., per transaction), and / or based on received information (e.g., input information to the algorithm), and can be verified by a system that also has access to shared algorithms and input data to recreate and verify the security value. For example, whenever a transaction is initiated, the security value can change and be generated using a secret algorithm or other shared information shared between two entities, allowing one entity to verify that the other entity is reliable by accessing the shared secret. This can also be referred to as "authentication data."

[0059] In some embodiments, the security value may include a password. For example, a password may be generated for each transaction based on a consumer device and / or issuer account-specific derivative algorithm, and this password may be verified for each transaction at the payment processor or the issuer of the account. Such dynamic values ​​may be referred to as dynamic card verification values ​​(e.g., dCVV, dCVV2), unique authentication verification values ​​(UAVV), token authentication verification values ​​(TAVV), etc., and may be distinguished based on input data and the algorithm used to generate the verifiable dynamic value. For example, a token authentication verification value may use a token (or other account substitute) as input to the verification algorithm, while a dynamic card verification value may use the primary account number (PAN) as input to the same or different verification algorithms.

[0060] In other embodiments, the secret algorithm used to generate the security value can be known to a single entity. For example, in some embodiments, remote transactions can be authenticated before an authorization request message is generated, and the issuer or payment processing network can use the secret algorithm to generate an authentication response value. When the transaction is initiated and an authorization request message is generated, the authentication response value can be included in the authorization request message, and the payment processing network or account issuer can use the same secret algorithm and input data to verify the authentication response value, thereby verifying the transaction. Accordingly, the security value may include a password generated using a shared key (e.g., a dynamic confirmation value, token authentication data, etc.) or a secret key (e.g., the authentication response value).

[0061] In some embodiments, the payment processing network and / or the issuing computer 170 may authenticate security information before receiving an authorization request message for a payment transaction. In such embodiments, the payment processing network and / or the issuing computer may return an authentication response, including an authentication response value indicating whether the authentication information has been authenticated and / or verified. Accordingly, a remote transaction processor (e.g., a payment processing network computer, a mobile gateway, a remote key manager computer, etc.) may replace the authentication information with the authentication response value in the payment information before re-encrypting the payment information and sending it to the transaction processor to initiate the payment transaction. The authentication response value can then be returned to the payment processing network to notify the transaction entity that the payment transaction has been pre-authenticated. Such a system improves the security of the transaction processing system and minimizes the probability of a fraudulent transaction because multiple authentication processes occur at various times during the transaction processing. Furthermore, such a system can efficiently authenticate users and payment devices before submitting transactions through the payment processing network and via a single authentication process.

[0062] An "authentication response value" can include any data that notifies an entity, entity, or process that it has been authenticated. For example, an authentication response value can be generated similarly to the security value described above; however, it can also be generated using different shared secrets or algorithms so that another entity within the transaction processing ecosystem with access to the shared secret can determine that the message, account, or other information included in the message has been authenticated by the entity. For instance, specific static data elements associated with a transaction (account identifier, expiry date, transaction time, date, etc.) can be used as input to generate the authentication response value during the authentication process and can be recalculated (using the same data elements) during the payment phase after receiving an authorization request message to verify that the authentication response value is correct and associated with the same transaction information.

[0063] A "payment application" or "mobile payment application" can include any application configured to facilitate payment transactions from a communication device (e.g., a mobile device or any other electronic communication device). For example, a mobile payment application may securely store sensitive payment information and / or payment credentials of a consumer's account to protect the payment information, account information, payment credentials, personal information, or any other relevant information from unauthorized access. A payment application may be configured to provide sensitive information to an authorized software application or module on a communication device, a contactless component, or any other software or hardware configured and authorized to communicate with the payment application. For example, a mobile payment application may be configured to connect to other mobile applications or merchant applications on a mobile device to provide payment information for a transaction. For example, a mobile payment application may provide a software development kit (SDK) or application programming interface (API) that a merchant application and / or other mobile application can use to connect to the mobile payment application. A mobile payment application may be configured to provide sensitive information in encrypted form using a key stored on secure storage.

[0064] Furthermore, in some embodiments, the mobile payment application may include any API, service, application, applet, or other executable code suitable for retrieving information from a secure element, generating payment information for a transaction (e.g., passwords or other security values, encrypted payment credentials, etc.), and communicating securely with a server computer (e.g., a remote key manager, mobile gateway, payment processing network, third-party service provider, etc.) to communicate with a remote transaction application, merchant application, and / or any other application. The mobile payment application may include or be configured to access stored information, including payment processing network public keys, payment credentials, third-party keys, mobile gateway credentials, and / or any other relevant information, and may be able to communicate with a mobile gateway or other remote server computer to obtain any issuer updates to relevant information.

[0065] A “merchant application” or “mobile application” can include any application associated with a party to a transaction. For example, a merchant application may be associated with a specific merchant or with many different merchants, and may be able to identify the specific merchant (or multiple merchants) that are parties to the transaction. For instance, a merchant application may store information identifying a specific merchant server computer configured to provide a sales environment in which the merchant server computer is capable of processing remote transactions initiated by the merchant application. Furthermore, a merchant application may also include a general-purpose browser or other software designed to interact with multiple merchant server computers, provided the browser is configured to identify the merchant server computers and process remote transactions. Merchant applications can be installed on the general-purpose storage of mobile devices, thus potentially making them vulnerable to malicious attacks, crashes, etc. Accordingly, merchant applications may be considered untrusted or unknown applications by security systems within mobile devices and remote payment transaction processing systems.

[0066] In some embodiments, the merchant application can initiate a payment transaction by sending decrypted payment information to the merchant server computer, which can then use the decrypted payment information to generate an authorization request message for the payment transaction. In other embodiments, the merchant application can be configured to generate an authorization request message and send it to the merchant server for processing.

[0067] Additionally, in some embodiments, the merchant application may be operated by or associated with an acquiring party, a payment service provider, or a back-end processor that operates and / or processes remote transactions for one or more merchants on their behalf. For example, the merchant application may include a payment service provider configured to process remote transactions on behalf of a merchant's computer. Alternatively, the acquiring party may process transactions on behalf of a merchant's computer and may provide an acquiring party application that performs similar functions to the merchant application by allowing consumers to initiate remote payments through the acquiring party application.

[0068] A "public / private key pair" may comprise a pair of related cryptographic keys generated by an entity. The public key can be used for public functions (such as encrypting messages to be sent to the entity) or for verifying digital signatures claimed by the entity. The private key, on the other hand, can be used for private functions, such as decrypting received messages or applying digital signatures. The public key is typically authorized by a subject known as a Certificate Authority (CA), which stores the public key in a database and distributes it to any other entity that requests it. The private key is typically kept in a secure storage medium and is usually known to the entity or trusted parties. However, the cryptographic system described herein may have a key recovery mechanism for recovering lost keys and preventing data loss.

[0069] A "public key" can include any encryption key that can be publicly shared. A public key can be designed to be shared and can be configured such that any information encrypted using the public key can only be decrypted using the private key associated with the public key (i.e., a public key / private key pair).

[0070] A "private key" can include any cryptographic key that can be protected and secure. For example, a private key can be securely stored on the entity that generated the public / private key pair and can be used to decrypt any information encrypted using the associated public key of the public / private key pair.

[0071] A "digital signature" can refer to the result of applying an algorithm that allows the signer to claim and the verifier to verify the reliability and integrity of a document. For example, with a public / private key pair, the signer can operate using the private key, while the verifier can operate using the public key. Due to the principle of non-repudiation—that what is signed cannot be denied—this process can prove the reliability of the sender and the integrity of the signed document. A certificate or other data containing the signer's digital signature is referred to as "signed" by the signee.

[0072] A certificate may include an electronic document or data file that identifies and / or verifies the identity of an entity. For example, a certificate may use a digital signature to bind a public key to data associated with the identity. A certificate may include one or more data fields, such as the legal name of the identity, the certificate's serial number, the certificate's expiration date, the permissions associated with the certificate, or any other relevant information identifying and / or authenticating the entity or the certificate itself. For example, a certificate may include a "validity start date" indicating the first date the certificate is valid, and a "validity end date" indicating the last date the certificate is valid. Furthermore, a certificate may also include a hash of the data in the certificate, containing the data fields. Additionally, each certificate may be signed by a Certificate Authority.

[0073] A "Certificate Authority" can include any entity configured to issue certificates. A Certificate Authority can prove its identity using a Certificate Authority Certificate that includes the Certificate Authority's public key. A Certificate Authority Certificate can be signed with the private key of another Certificate Authority, or it can be signed with the private key of the same Certificate Authority. The latter is called a self-signed certificate. Certificate Authorities typically also maintain a database of all certificates issued by that Certificate Authority.

[0074] In a typical certificate issuance process, a Certificate Authority (CA) receives an unsigned certificate from an entity whose identity is known. The unsigned certificate includes a public key, one or more data fields, and a hash of the data in the certificate. The CA can then sign the certificate using a private key corresponding to the public key included on the certificate. The CA can then store the signed certificate in a database and issue signed certificates to entities. Subsequently, entities can use the certificate as a means of proving their authenticity and identity.

[0075] In some embodiments, a Certificate Authority (CA) may include any entity from the transaction processing ecosystem. For example, a payment processing network, a remote key manager, an issuer, an acquirer, or any other entity within the transaction system may be responsible for issuing and certifying certificates. For instance, a merchant, a merchant application, or an acquirer computer configured to process remote transactions may register with a remote key manager, payment processing network, mobile wallet provider, or any other third party to obtain a public key certificate signed by the appropriate entity, allowing that entity to verify the certificate and ensure its validity for any given transaction. In some embodiments, entities within a remote payment transaction processing system may contact the CA to determine whether a certificate has been updated, is still valid, has been revoked, etc. Accordingly, the CA may be configured to provide status information about the certificates it issues.

[0076] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a cluster of microcomputers, or a group of servers acting as a single unit. In one example, a server computer can be a database server coupled to a web server. A server computer can be coupled to a database and can include any combination of the preceding hardware, software, other logic, or components used to serve requests from one or more client computers. A server computer can include one or more computing devices and can use various computing architectures, layouts, and compilations for serving requests from one or more client computers.

[0077] As those skilled in the art will recognize, the various embodiments of the invention described herein include multiple different embodiments that can be combined in any suitable manner. For example, in the embodiments described below, various different parties, merchant applications, mobile payment applications, and transaction processors are described, and specific flowcharts are provided as examples. These examples are provided to illustrate the concepts of the invention and are not limiting. Accordingly, features from the various embodiments can be combined in any suitable manner, including using registered public keys and public key certificates in configurations different from those explicitly provided in each illustrative system described herein. Accordingly, this is merely one example of the various combinations available according to some embodiments of the invention that can be described in more detail below. Further, additional information regarding the various configuration options that may be available can be found in U.S. Non-Provisional Application No. 14 / 332,245, filed July 15, 2014, which is incorporated herein by reference in its entirety for various purposes.

[0078] I. Exemplary System

[0079] Figure 1 A block diagram of an exemplary system 100 for performing remote transactions using a merchant application 121 with a remote key manager 140 and a mobile device 120, according to some embodiments of the present invention, is shown. System 100 includes a user (e.g., a consumer 110), a communication device (e.g., a mobile device 120) including a merchant application 121, a secure element 122, a remote transaction application 124, and a mobile payment application 123, a remote key manager 140, a certificate authority 180, a merchant computer 130, an acquiring computer 150, a payment processing network 160, a directory server 190, an authentication computer 191, and an issuing computer 170. Various entities can be configured to communicate with each other via any suitable wireless or wired communication network and using any suitable communication protocol (including open or proprietary communication protocols).

[0080] "Issuer" can typically refer to a business entity (e.g., a bank) that maintains a user's financial account and often issues portable consumer devices such as credit cards or debit cards to users. An issuer may also issue or supply account information to mobile device 120 to allow mobile payments initiated by the mobile device. "Merchant" is typically an entity that participates in transactions and can sell goods or services. "Acquiring party" is typically a business entity that has a business relationship with a particular merchant or other entity (e.g., a commercial bank). Some entities can perform both issuer and acquiring party functions. Some embodiments may cover such a single entity as issuer-acquiring party. Each of these entities may include one or more computer devices (e.g., merchant computer 130, acquiring party computer 150, payment processing network 160, and issuer computer 170) to enable communication or perform one or more of the functions described herein.

[0081] Payment processing network 160 may include data processing subsystems, networks, and operations for supporting and delivering certificate authority services, authorization services, exception handling services, transaction scoring services, and clearing and settlement services. An exemplary payment processing network 160 may include VisaNet. TM Such as VisaNet TM Payment processing networks like VisaNet can handle credit card transactions, debit card transactions, and other types of commercial transactions. TM This includes the VIP system (a payment system integrated with Visa) that processes authorization requests, and the Base II system that performs clearing and settlement services.

[0082] Payment processing network 160 may include one or more server computers 161. Server computers are typically powerful computers or computer clusters. For example, a server computer may be a mainframe, a cluster of microcomputers, or a group of servers acting as a unit. In one example, a server computer may be a database server coupled to a web server. Payment processing network 160 may use any suitable wired or wireless network, including the Internet.

[0083] In certain "card present" or in-store payment transactions, a user uses mobile device 120 to purchase goods or services at a merchant. For example, the user's mobile device 120 can interact with an access device (not shown) at the merchant's location, which is associated with a merchant computer 130. For instance, the user can tap mobile device 120 against a near-field communication (NFC) reader in the access device. Alternatively, in remote or "card not present" transactions, the user can electronically point payment details to the merchant computer 130, as in online transactions.

[0084] The authorization request message can be generated by the mobile device 120 or the merchant computer 130 and then forwarded to the acquiring computer 150. Upon receiving the authorization request message, it is then sent to the payment processing network 160. The payment processing network 160 then forwards the authorization request message to the corresponding issuing computer 170 associated with the issuer associated with the user.

[0085] An "authorization request message" can be an electronic message sent to the payment processing network 160 and / or the issuer of the payment card to request authorization for a transaction. According to some embodiments, the authorization request message may conform to ISO 8583, a standard for systems exchanging information about electronic transactions associated with payments made by a user using a payment device or spending account. The authorization request message may include an issuer account identifier that may 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, CVV (card verification value), dCVV (dynamic card verification value), expiration date, etc. The authorization request message may also include "transaction information," such as any information associated with the current transaction, such as transaction volume, merchant identifier, merchant location, etc., and any other information that may be used to determine whether to identify and / or authorize the transaction. The authorization request message may also include other information, such as information identifying the access device that generated the authorization request message, information about the location of the access device, etc.

[0086] After receiving the authorization request message, the issuing computer 170 sends an authorization response message back to the payment processing network 160 to indicate whether the current transaction is authorized (or not authorized). The payment processing network 160 then forwards the authorization response message back to the acquiring computer 150. In some embodiments, such as based on a fraud risk score, the payment processing network 160 may reject the transaction even if the issuing computer 170 has authorized it. The acquiring computer 150 then sends a response message back to the merchant computer 130.

[0087] An "authorization response message" may be an electronic message response to an authorization request message generated by the issuing financial institution 170 or the payment processing network 160. By way of example only, an authorization response message may include one or more of the following status indicators: "Approved" – the transaction is approved; "Rejected" – the transaction is not approved; or "Call Center" – the response is pending due to the need for more information, and the merchant must call a toll-free authorization phone number. An authorization response message may also include an authorization code, which may be a code indicating transaction approval returned by the credit card issuing bank to the merchant's computer 130 in response to the authorization request message in the electronic message (directly or via the payment processing network 160). This code can serve as proof of authorization. As noted above, in some embodiments, the payment processing network 160 may generate an authorization response message or forward it to the merchant.

[0088] After receiving the authorization response message, the merchant computer 130 can provide the authorization response message to the user. The response message can be displayed by the mobile device 120 or printed on a physical receipt. Alternatively, if the transaction is an online transaction, the merchant can provide a webpage or other instructions in the authorization response message as a virtual receipt. The receipt may include transaction data for the transaction.

[0089] At the end of the day, the normal clearing and settlement process can be carried out by the payment processing network 160. The clearing process is the exchange of financial details between the acquirer and the issuer to facilitate the posting of payments to the consumer's payment account and the verification of the user's settlement position.

[0090] exist Figure 1 In the remote transaction processing system, mobile device 120 is configured to use remote key manager 140 to initiate and process remote transactions with merchant computer 130 to provide a secure remote payment transaction environment, even when using unknown merchant application 121 or other mobile applications installed on communication devices (e.g., mobile device 120).

[0091] A user (e.g., consumer 110) can operate a communication device (e.g., mobile device 120) to perform any number of functions that mobile device 120 is configured to perform. For example, consumer 110 can use mobile device 120 to execute remote payment transactions by communicating with remote key manager 140 and merchant computer 130. Merchant computer 130 can provide available products and services to merchant application 121 that consumer 110 can use to initiate remote transactions, whether located at the merchant's location or far away from the merchant.

[0092] A communication device (e.g., mobile device 120) can be configured to communicate with a remote key manager 140 configured to facilitate and / or process remote transactions. The remote key manager 140 is configured to perform numerous functions related to the remote transaction, including receiving encrypted payment information, verifying public key certificates associated with the remote transaction, decrypting encrypted payment information using a remote key manager key, verifying security information through any number of authentication processes, and re-encrypting payment information using a public key associated with the transaction processor used for the transaction (e.g., merchant, merchant processor, acquirer, etc.). Figure 3 The various modules of the remote key manager 140 are described in more detail.

[0093] "Communication device" can include any electronic computing device. For example, "communication device" can include mobile device 120, which can include mobile phones, tablets, netbooks, laptops, or any other suitable mobile computing device. Mobile device 120 can include merchant application 121, remote transaction application 124, and mobile payment application 123. Mobile payment application 123 and remote transaction application 124 can be stored in secure memory (e.g., secure element 122).

[0094] Merchant application 121 may include any mobile application, software, or other suitable executable code adapted to perform payment transactions. In some embodiments, merchant application 121 may be a merchant-specific application. In other embodiments, merchant application 121 may be a general-purpose application, such as a web browser. Furthermore, merchant application 121 may be associated with parties that are not merchants but process payments on behalf of merchants or other service providers (e.g., payment service providers, acquirers, etc.).

[0095] Secure element 122 can be any hardware or software component operable to securely store any information and / or secure applications. For example, secure element 122 can be operable to store payment information. Secure element 122 is an example of a Trusted Execution Environment (TEE). A Trusted Execution Environment can be implemented using software or hardware components and can reside on a communication device or a remote server computer (e.g., a cloud-based TEE). Furthermore, a mobile payment application 123 can be provided and stored on secure element 122 to securely access personalized sensitive information associated with a consumer's financial account (e.g., payment credentials, tokens, account identifiers, etc.). For example, in some embodiments, secure element 122 may include a secure cryptographic processor or contactless integrated circuit to protect information stored on secure element 122. Secure element 122 may have a separate processor on which information stored can be encrypted using a secret key held only by a trusted service manager or other designated entity, and secure element 122 may contain any other hardware so that secure element 122 can be a secure area where important information (e.g., payment credentials, encryption keys, and any other sensitive information) can be stored. Furthermore, special secret keys that can be managed by certain trusted service managers can be used to access the secure data elements of secure element 122.

[0096] Additionally, in some embodiments, a trusted execution environment can be provided by a remote server computer, allowing sensitive information to be transmitted to a mobile payment application via a process similar to that described herein, without using a secure element or other trusted execution environment on the communication device. For example, transmitting sensitive information valid for a limited time period to the communication device prior to a transaction allows a process similar to that described herein to be executed without requiring a trusted execution environment implemented by a secure element or other hardware to be present on the communication device.

[0097] Merchant application 121 may include a remote transaction SDK (not shown) or a third-party service layer, which may include any API, application, applet, or other executable code suitable for connecting to remote transaction application 124 and / or third-party server system interface applications (e.g., mobile wallet providers, mobile gateways, remote key managers 140, etc.). For example, the remote transaction SDK may be embedded in merchant application 121 and may be used by merchant application 121 to retrieve payment information from remote transaction application 124 on secure element 122 for connection to mobile payment application 123 provided on secure element 122. Additionally, although the remote transaction SDK is described as part of merchant application 121, the remote transaction SDK may also be a standalone application or may be embedded in the operating system of mobile device 120.

[0098] The remote transaction application 124 includes a secure application supplied to the secure element 122 of the mobile device 120. The remote transaction application 124 provides a secure area for storing public key certificates and / or other cryptographic keys from third-party computer systems (e.g., remote key manager 140, mobile wallet provider, mobile gateway, etc.). The remote transaction application 124 (also referred to as a remote transaction applet) can be configured to work with the mobile payment application 123 (e.g., Visa). TM Paywave TM The remote transaction application 124 can communicate with the remote key manager 140 or other third-party systems configured to securely facilitate the initiation and authentication of remote payment transactions.

[0099] Therefore, when consumer 110 provides security credentials or is otherwise authenticated, remote transaction application 124 can provide access control confirmation of mobile payment application 123 (e.g., provide security features of mobile payment application 123) by allowing access to mobile payment application 123. For example, if the signature associated with the merchant certificate cannot be verified or if the certificate does not match the certificate authority 180, remote transaction application 124 can reject the request for a remote transaction from merchant application 121, and transaction processing can be terminated (and consumer 110 can be prompted to try a different payment method or try again). Alternatively, if the certificate is valid, remote transaction application 124 can forward a request for payment information to mobile payment application 123.

[0100] Mobile payment application 123 may include any application programming interface (API), service, application, applet, or other executable code suitable for retrieving payment information from a secure storage module or secure element 122 and communicating with merchant application 121. In some embodiments, mobile payment application 123 may be securely protected. For example, mobile payment application 123 may be protected within secure element 122 (such as...). Figure 2 It can run as a kernel service in a trusted environment (as shown) or other environments, or at a higher privilege level than the merchant application 121.

[0101] Mobile payment application 123 may include a certificate associated with remote key manager 140, which can be used to encrypt payment information and other communications using the public key (or other encryption key) associated with remote key manager 140. In some embodiments, mobile payment application 123 may be operable to generate a security value (e.g., a password) associated with payment information. For example, mobile payment application 123 may be operable to generate a security value including a dynamic card verification value (dCVV2) associated with a payment account. In other embodiments, mobile payment application 123 may be able to generate specific dynamic authentication requests or other dynamic values ​​that can be verified by a payment processing network 160 that shares secrets with the personalized mobile payment application 123.

[0102] Figure 2 A block diagram of an exemplary communication device (e.g., mobile device 120) according to some embodiments of the present invention is shown. Mobile device 120 may include circuitry for implementing certain device functions (such as a telephone). Functional elements responsible for implementing these functions may include a processor 120(A) programmed to execute instructions that implement the functions and operations of the device. The processor 120(A) may access data storage 120(E) (or another suitable memory area or element) to retrieve instructions or data for executing instructions, such as a merchant application, a remote transaction application 124, or other mobile applications. Data input / output elements 120(C), such as a keyboard or touchscreen, may be used to enable a user to operate mobile device 120 and input data (e.g., user authentication data). Data input / output elements may also be configured to output data (e.g., via a speaker). A display 120(B) may also be used to output data to a user. Communication elements 120(D) may be used to enable data transmission between mobile device 120 and wired or wireless networks (e.g., via antenna 120(H)) to facilitate connection to the Internet or other communication networks and to implement data transmission functionality.

[0103] Mobile device 120 may also include a contactless element interface or secure memory interface 120(F) to enable data transmission between contactless element 120(G) and other components of the device, wherein contactless element 120(G) may include secure memory (e.g., secure element 122) and near-field communication data transmission elements (or another form of short-range or contactless communication technology). As noted, cellular phones or similar devices are examples of communication devices (e.g., mobile device 120) that can be used according to various embodiments of the invention. However, other forms or types of devices may be used without departing from the underlying concepts of the invention. Furthermore, the device may not require the ability to communicate using a cellular network for suitability for use with embodiments of the invention.

[0104] Figure 3 A block diagram of an exemplary remote key manager 140 according to some embodiments of the present invention is shown. The remote key manager 140 may include a server computer 141, a private key database 141(G), and a certificate authority root public key database 141(H). The server computer 141 may include a certificate verification module 141(A), a public key extraction module 141(B), a transaction processing module 141(C), a security information verification module 141(D), a communication device interface 141(E), and a payment processing network interface 141(F). The server computer 141 may further include a processor (not shown) and a computer-readable medium (not shown) coupled to the processor, the computer-readable medium including code executable by the processor for performing the methods described in the embodiments herein.

[0105] The certificate verification module 141(A) may include any software module that can be configured to verify that a merchant certificate (or other transaction processor certificate) is associated with a specific merchant, is authentic, and / or valid. The certificate verification module 141(A) may perform any number of steps to achieve this functionality. For example, the certificate verification module 141(A) may communicate with the certificate authority 180 to ensure that the public certificate is currently valid and within its validity period (e.g., not reported as corrupt or revoked via a Certificate Revocation List (CRL) or Online Certificate Status Protocol Response (CSPR), etc.). Additionally, the certificate verification module 141(A) may use the certificate authority root public key stored in the certificate authority public root key database 141(H) to verify that the public key certificate is legitimate and signed by the appropriate certificate authority 180.

[0106] Return to Figure 1Certificate Authority 180 can be associated with remote key manager 140 to allow verification of certificate status. Additionally, the Certificate Authority can also be associated with merchant computer 130 and can issue a public key certificate to merchant computer 130. This public key certificate can be used during remote payment transaction processing to establish trust between a third-party server computer (e.g., remote key manager 140) and merchant computer 130, confirming that merchant computer 130 is reliable and authorized to access sensitive payment credentials within encrypted payment information. (See below...) Figure 5 The document describes in detail the process by which a Certificate Authority (CA) can issue merchant certificates. Some non-restrictive examples of certificate issuance methods can be found in ANSI X9.24 Part 2 Retail Financial Services Symmetric Key Management Part 2: Using Asymmetric Techniques for the Distribution of Symmetric Keys and ISO 11568 Part 4 Banking—Key management (retail)—Part 4: Asymmetric cryptosystems—Key management and life cycle.

[0107] The public key extraction module 141(B) can be configured to extract the public key used for processing remote transactions from a received or stored public key certificate. Any suitable process can be used to extract the public key. In some embodiments, the public key can be extracted before or after the verification and / or confirmation of the public key certificate.

[0108] Transaction processing module 141(C) can be configured to process payment requests and provide payment responses as a reply to payment requests, assuming that the received or stored public key certificate is valid and positive for the transaction. For example, transaction processing module 141(C) can use a remote key manager private key stored in private key database 141(G) to decrypt a received encrypted message and re-encrypt the decrypted message or information from the message using a transaction processor public key extracted from a transaction processor certificate (e.g., a merchant certificate) for secure transmission to a transaction processor (e.g., merchant computer 130). Transaction processing module 141(C) can also further pass the re-encrypted message (e.g., a payment response) to a communication device (e.g., a mobile device 120) for delivery to the appropriate transaction processor (e.g., merchant computer 130).

[0109] The security information verification module 141(D) may include any software module configured to initiate authentication communication with the payment processing network 160 to initiate an authentication process. For example, the security information verification module 141(D) may be configured to use the payment processing network interface 141(F) to send an authentication request including security information to the payment processing network server computer 161 associated with the decrypted payment information. The payment processing network server computer 161 may determine the authentication computer 191 associated with the decrypted payment information and forward the authentication request to the authentication computer 191. The authentication computer 191 may then verify the security information and generate an authentication response including an authentication response value. The security information verification module 141(D) may then receive the authentication response including the authentication response value from the payment processing network computer 161 via the payment processing network interface 141(F).

[0110] In some embodiments, where a remote key manager computer 141 may be associated with a payment processing network 160, the remote key manager 140 may be configured to determine the authentication computer 191 associated with a remote payment transaction by incorporating directory server functionality into the remote key manager 140. Accordingly, the security information verification module 141(D) of the remote key manager computer may determine the authentication computer 191 associated with the decrypted payment information and may send an authentication request including the security information to the authentication computer 191. The authentication computer 191 may verify the security information and return an authentication response including an authentication response value indicating the verification of the security information.

[0111] The communication device interface 141(E) can be configured to communicate with a communication device (e.g., mobile device 120). For example, the communication device interface 141(E) can include any suitable communication protocol or network interface for communicating with the mobile device 120. The mobile device interface 141(D) can receive messages (e.g., payment requests) from the mobile device 120 and can be configured to parse the message to determine relevant information included in the message.

[0112] The payment processing network interface 141(F) may include hardware and / or software interfaces configured to pass requests to the payment processing network 160. The payment processing network interface 141(F) may include a secure channel that allows secure exchange of information with the payment processing network 160. For example, a hardware security interface or session-based keys may be exchanged to ensure a highly secure connection with the payment processing network server computer 161.

[0113] The private key database 141(G) may include the private key of the remote key manager 140 (also referred to as the remote key manager private key). The private key can be generated by any suitable means and can be securely stored to prevent unauthorized entities from accessing it. In some embodiments, the private key may be stored in local storage or in a remote secure database. In some embodiments, the private key may be one of a private / public key pair associated with the remote key manager 140, and the public key may be provided to merchant application 121, mobile payment application 123, mobile device 120, remote transaction application (not shown), and any other transaction entity configured to encrypt payment information for processing by the remote key manager 140. Additionally, in some embodiments, the private key database 141(G) may include a symmetric encryption key, which can be used when data is encrypted using a symmetric encryption key instead of a public / private encryption key pair.

[0114] The root public key database 141(H) may include the root public key of the certificate authority 180 associated with the public key certificate. In some embodiments, a single certificate authority root public key may be stored in a remote key manager 140 associated with the single certificate authority 180 (and may be stored locally on the remote key manager computer), while in other embodiments, multiple certificate authority root keys may be stored in a database or stored locally on the remote key manager computer. The certificate authority root public key can be used in the signature verification process to ensure that the public key certificate and the issuing certificate authority are valid and active.

[0115] Figure 4A block diagram of some components of an exemplary payment processing network 160 according to some embodiments of the present invention is shown. The payment processing network 160 may include a server computer 161, an issuer authentication configuration database 161(E), and an issuer-shared secret database 161(F). The server computer 161 may include a security information verification module 161(A), a transaction processing module 161(B), a directory server interface module 161(C), and a remote key manager interface module 161(D). The server computer 161 may further include a processor (not shown) and a computer-readable medium (not shown) coupled to the processor, the computer-readable medium including code executable by the processor for performing the methods described in the embodiments herein.

[0116] The security information verification module 161(A) may include any software module configured to verify security information associated with the payment request (e.g., user authentication data, security values, or any other authentication information). For example, the security information verification module 161(A) may be configured to determine the authentication computer 191 associated with the authentication request and forward the authentication request to the relevant authentication computer 191. The security information verification module 161(A) may use a directory server accessible through the directory server interface module 161(C) to determine the authentication computer 191.

[0117] Return to Figure 1 In some embodiments, the directory server computer 190 may be used to determine an authentication computer 191 configured to verify security information for a given remote transaction. The directory server 190 may include any computer, device, and / or system configured to receive authentication requests, determine the authentication computer 191 associated with the authentication request, and forward the authentication request to the authentication computer 191. For example, the directory server may include an issuer authentication configuration database 161(E) that includes an issuer identifier associated with a payment account and a corresponding authentication computer specified for each issuer identifier. For example, the directory server may include bank identification numbers (BINs) associated with the payment processing network 160 (e.g., VisaNet). TM The list of BINs and the corresponding authentication computer address associated with each BIN. For example, the authentication computer address may include an IP address, an HTTP address, an internal directory address, or any other information that allows the directory server to determine and provide the appropriate location to which the authentication request should be forwarded to ensure that the correct authentication computer 191 receives and verifies the security information.

[0118] The authentication computer 191 may include any computer, system, device, or combination of devices configured to receive authentication requests including security information associated with remote payment transactions, verify the security information, and provide an authentication response value indicating that the security information has been verified and / or authenticated. The authentication computer may include an authentication database containing personal information, usernames, passwords, PINs, passphrases, shared confidential information, and any other relevant information that allows the system to authenticate users as having authorization or authority to perform transactions.

[0119] The authentication computer 191 may be associated with and / or operated by the payment processing network 160, the issuer, or a third party. For example, the account issuer may provide the payment processing network 160 or other third-party computer systems with issuer profile information (e.g., authentication rules, risk rules, etc.) and shared confidential information associated with the account holder, device, and any other relevant information to allow the payment processing network or other entity to perform authentication of the security information. Such a system can be considered a “representative” authentication system, where the issuer provides authentication information to a third party to allow authentication functions to be performed by a third party acting on behalf of the issuer. The authentication computer 191 associated with or managed by the account issuer can be considered an Access Control Server (ACS).

[0120] In some embodiments, the authentication computer 191 may also include the issuer computer 170 associated with the authorization decision process. Therefore, in some embodiments, the payment processing network 161 may send authentication requests to the issuer computer 170 in a manner similar to payment transaction processing (e.g., using ISO messages or other pre-configured interfaces with the issuer computer).

[0121] Furthermore, in some embodiments, more than one authentication computer 191 can be used during the remote transaction authentication process. For example, the payment processing network 160 can perform device authentication on behalf of the account issuer by sharing a shared secret associated with the account with a "representative" authentication computer operated by the payment processing network 160. However, instead of using the payment processing network 160 to provide consumer profile information and corresponding user authentication data, the account issuer can transmit the user authentication data to the issuer's authentication computer 191, an access control server (ACS), or other computers configured to authenticate consumer information. Therefore, the payment processing network 160 can verify device authentication information in parallel or in conjunction with the issuer's access control server (ACS) that verifies the user authentication data.

[0122] Additionally, in some embodiments, the payment processing network authentication computer can pass the authentication result to the account issuer access control server computer (i.e., the authentication computer associated with the issuer). For example, the security information passed to authentication computer 191 may include an indication that security values ​​(e.g., passwords) and / or user authentication data (e.g., passphrases) have been pre-authenticated by the payment processing network 160 representing account issuer 170. Accordingly, in some embodiments, the authentication computer 191 associated with account issuer 170 may participate in the generation of authentication response values ​​or other indications for authentication of consumers and / or devices without performing direct verification of the security information. Furthermore, in some embodiments, the role of the authentication computer associated with payment processing network 160 in generating authentication response values ​​may be reversed based on the verification of security information by the authentication computer 191 associated with account issuer 170.

[0123] The authentication computer 191 can use shared secrets or shared algorithms to verify security values ​​that are repeatedly calculated using repeatable input data and to compare dynamic security values ​​(e.g., passwords) of transactions. For example, the security value (e.g., password) can be generated by the mobile payment application 123 using an account identifier, expiration date, transaction time, transaction amount, or any other suitable transaction information available to both the mobile payment application 123 and the authentication computer 191 associated with the account issuer computer 170 and / or the payment processing network 160 (or any other processing entity). For example, algorithms can be shared between the mobile payment application 123 and the authentication computer 191 associated with the payment processing network 160 or the account issuer computer 170 or other processing entities to allow for the verification of security information.

[0124] Accordingly, return to Figure 4 In some embodiments, the security information verification module 161(A) may use the directory server interface module 161(C) to forward the authentication request received from the remote key manager 140 via the remote key manager interface module 161(D) to the directory server computer 190 associated with the payment request.

[0125] Directory server interface module 161(C) may include hardware and / or software interfaces configured to pass authentication requests and responses to directory server computer 190 or a system. Directory server interface module 161(C) may include a secure channel that allows secure exchange of information with directory server computer 190. For example, hardware security interfaces or session-based keys may be exchanged to ensure a highly secure connection with directory server computer 190.

[0126] However, in other embodiments, the functionality of the directory server may be incorporated into the payment processing network 160 (and / or the remote key manager 140) so that the payment processing network 160 (or the remote key manager computer) can determine the appropriate authentication computer 191 based on information included in the authentication request. For example, the payment processing network computer can determine the authentication computer 191 associated with the authentication request by parsing account credentials (e.g., primary account number, token, or account substitute, etc.) from the authentication request and determining the issuer associated with the account credentials. For example, in some embodiments, the authentication request may include a primary account number (PAN) associated with a remote payment transaction, and the PAN may include a bank identifier (e.g., BIN) associated with the issuer of the account. Accordingly, the security information verification module 161(A) may compare the BIN with the issuer authentication configuration database 161(E) to determine the authentication computer 191 associated with the issuer's account. Further, the issuer may have certain accounts authenticated by different authentication computers, so in some embodiments, the directory server may determine the authentication computer 191 associated with an account range or the account number associated with the issuer.

[0127] The issuer authentication configuration database 161(E) may include any information related to determining the authentication computer 191 associated with the account and / or the account issuer. The issuer authentication configuration database 161(E) may also include authentication preferences associated with the issuer, as well as profile information associated with the account issuer for risk assessment, transaction processing, authorization decisions, etc. Further, depending on the system's configuration options, the issuer authentication configuration database 161(E) may be located on the payment processing network 160 or on a directory server.

[0128] The shared secret database 161(F) may include any information that allows entities to verify security information and / or other authentication information associated with the issuer's account. For example, in some embodiments, the shared secret database may include a shared secret algorithm for repeatedly generating security values ​​associated with the account, or may include a searchable database of relevant consumer authentication and device authentication information.

[0129] Furthermore, the security information verification module 161(A) can be configured to generate an authentication response value using a secret algorithm securely stored in the payment processing network 160. This secret algorithm may not be shared with any other entity in the remote transaction processing system. Accordingly, the security information verification module 161(A) can verify a dynamic password (e.g., a security value) generated by the mobile payment application 123 and can return another dynamic password (e.g., an authentication response value) that can be returned to the mobile device 120 and submitted along with any authorization request message generated for the transaction. Accordingly, the payment processing network 160 can obtain the authentication response value during transaction processing of the authorization request message and can verify that the authentication response value matches the authentication response message initially generated by the payment processing network 160 during the initial processing of the remote payment transaction. Accordingly, it can be assured to the payment processing network 160 that the transaction has not been altered and that the transaction data is identical to the transaction initially authenticated by the payment processing network computer 161.

[0130] Transaction processing module 161(B) may include any software module configured to receive authorization request messages and process authorization request messages for transactions. Further details regarding the processing of authorization request messages have been described above.

[0131] The remote key manager interface module 161(D) may include software and / or hardware interfaces configured to allow the payment processing network 160 to connect to the remote key manager 140. The remote key manager interface module 161(D) may include a secure channel that allows secure exchange of information with the remote key manager computer. For example, a hardware security interface or session-based keys may be exchanged to ensure a highly secure connection with the remote key manager server computer 141. The payment processing network 160 may receive authentication requests from the remote key manager 140 through the remote key manager interface module 161(D) and, through the remote key manager interface module 161(D), send authentication responses to the remote key manager 190 (or, depending on the configuration, other entities, such as a mobile gateway).

[0132] A. Merchant Certificate Issuance / Supply Methods

[0133] Figure 5 A flowchart illustrating an exemplary method 500 for supplying a public / private key pair and a merchant application certificate to a merchant using a Certificate Authority 180, according to certain embodiments of the present invention, is shown. In some embodiments, method 500 may be performed to provide a certificate to a merchant computer 130 indicating the merchant's trustworthiness or reliability. The received merchant certificate may then be included in a merchant application installed on or provided to a mobile device.

[0134] In step 501, the merchant computer 130 generates a merchant public-private key pair. The merchant public-private key pair can be generated in any suitable format, such as RSA or Elliptic Curve Cryptography (ECC). In some embodiments, the merchant private key can be securely stored on the merchant computer 130.

[0135] In step 502, the merchant computer 130 sends the merchant's public key, representing the public-private key pair, to the certificate authority 180. The certificate authority 180 may include any suitable entity configured to issue and verify certificates. For example, in some embodiments, the certificate authority 180 may include a payment processing network 160, a remote key manager 140, a mobile wallet provider, an entity not included in a typical payment transaction processing system, or any other entity.

[0136] In step 503, the Certificate Authority 180 uses any suitable means to verify the authenticity of the merchant. For example, the merchant computer 130 may provide the Certificate Authority 180 with information that identifies the merchant computer 130 being operated by the merchant. In one example, the merchant computer 130 may provide documents signed by an authorized signatory of the merchant (e.g., the president of the merchant organization).

[0137] In step 504, Certificate Authority 180 uses the received Merchant Certificate Signing Request, which includes the Merchant's public key, to generate a signed Merchant Certificate. Typically, the Merchant Certificate can be signed with the Certificate Authority's root private key. Certificate Authority signing allows entities to verify the reliability of the Merchant Certificate using the Certificate Authority's root public key.

[0138] In step 505, the certificate authority 180 sends the signed merchant certificate to the merchant computer 130.

[0139] In step 506, the merchant computer 130 uses the merchant's private key to generate a signed merchant application certificate. This establishes a chain of trust from the merchant application certificate to the merchant certificate, and then to the certificate authority root certificate. In some embodiments, the signed merchant application certificate may be associated with an instance or version of the merchant application 121. For example, the merchant application certificate may be used to verify that the merchant application 121 originates from the merchant.

[0140] In step 507, the merchant computer 130 stores the merchant application certificate in the merchant application 121. This allows the reliability of the merchant application 121 to be verified when it is loaded onto the mobile device 120. Additionally, the merchant computer 130 can locally store the merchant application private key associated with the merchant application certificate to allow for the decryption of information encrypted using the merchant application public key.

[0141] It should be understood that Figure 5 This is descriptive and not restrictive. For example, in some embodiments of the invention, the merchant's public-private key pair may be generated by a certificate authority 180, for instance, by securely providing the merchant's private key to the merchant computer 130 using a Public Key Cryptography Standard (PKCS) #12 message. Furthermore, in some embodiments, similar techniques may be used to generate merchant certificates associated with other entities within the merchant server computer or secure transaction processing system.

[0142] B. Exemplary Methods

[0143] Figure 6 A flowchart illustrating an exemplary method 600 for processing remote transactions using a merchant application 121 with a remote key manager 140 and a mobile device 120, according to some embodiments of the present invention, is shown. In some embodiments, this can be performed after providing a merchant application certificate (e.g., according to method 500) and storing it in the merchant application 121, either together with or without the merchant application private key. Figure 6 The method. Then, it can be executed. Figure 6 This method enables the execution of remote payment transactions for goods or services.

[0144] As described above, the embodiments allow connectivity to the payment processing network 160, which provides several advantages, including additional authentication capabilities, such as verification of authentication values ​​before submitting a transaction to the payment processing network 160 via the authorization request message. Accordingly, the payment processing network 160 can perform additional authentication processes (e.g., risk management, speed checks, etc.) on the payment request (and associated consumer account) before initiating payment. This allows the payment processing network 160 to notify the merchant system whether the transaction is reliable before initiating the payment transaction via the authorization request message. Subsequently, the merchant can modify the risk assessment, authentication process, and any other transaction procedures based on the authentication results provided by the payment processing network 160.

[0145] Additionally, by connecting to the payment processing network 160, the payment processing network 160 can allow an additional layer of transaction authentication by generating an authorization response value, which can be verified by the payment processing network 160 before the transaction is authorized. Furthermore, by connecting to the payment processing network 160, the remote key manager 140 can act as a single interface point for the authentication system, allowing efficient authentication of the user and device associated with the remote transaction. Due to the remote nature of the transaction and the lack of capability for merchants or other in-person service providers to authenticate the consumer 110, dual authentication is particularly important for remote payment transactions.

[0146] In step 601, consumer 110 concludes their shopping experience via a merchant application 121 on a communication device that communicates with merchant computer 130 or other computers controlling the online or e-commerce store. Consumer 110 can initiate the payment process via the merchant application 121 on the communication device (e.g., mobile device 120). Merchant application 121 can offer the option of remote payment transactions using remote transaction application 124, which consumer 110 can select as the payment option. Accordingly, consumer 110 initiates a remote payment transaction using merchant application 121, and merchant application 121 sends a message indicating that consumer 110 is willing to initiate a remote transaction to merchant computer 130.

[0147] In some embodiments, merchant application 121 may offer the option to select a payment card or account for payment via remote transaction application 124. Therefore, in some embodiments, remote transaction application 124 may have pre-determined available cards or accounts for remote payment transactions and may pass the available account information to merchant application 121. Alternatively or additionally, merchant application 121 may request an available account when payment is ready or at any other suitable time. Accordingly, in some embodiments, consumer 110 may select an account when initiating a remote payment via merchant application 121. In other embodiments, a default account may be used, or remote transaction application 124 may prompt consumer 110 to select an account at a later time.

[0148] In step 602, the merchant computer 130 receives an instruction to initiate a remote transaction and responds by generating transaction information for the remote payment transaction and sending it to the merchant application 121 on the mobile device 120. The transaction information may include, for example, a merchant identifier, transaction amount, transaction authentication type, transaction identifier, merchant certificate, and any other relevant information used to process the remote transaction.

[0149] Additionally, in some embodiments, transaction information may have been provided to the merchant application 121 beforehand when the payment option is offered to the user. In any case, the merchant application 121 can access the transaction information associated with the remote transaction.

[0150] In step 603, merchant application 121 uses the remote transaction software development kit (SDK), the remote transaction service layer, the remote transaction application application (API) 124, or any other application located on mobile device 120, to send payee information to remote transaction application 124. Payee information may include information suitable for identifying the merchant associated with the remote payment transaction (e.g., merchant certificate, merchant identifier associated with mobile payment application 123, etc.), the user's payment method (e.g., payment credential associated with mobile payment application 123), the transaction type (e.g., remote transaction), and any other information that may be associated with mobile payment application 123 for processing the remote payment transaction.

[0151] For example, payee information may include a merchant certificate associated with merchant application 121 or merchant computer 130. Alternatively or additionally, payee information may include a merchant identifier that can be used to identify the merchant certificate associated with merchant application 121 or merchant computer 130 stored in mobile payment application 123.

[0152] Furthermore, the payee information may include a merchant identifier provided to the merchant application 121 (or the merchant server associated with the merchant application 121) during the registration phase for remote transaction processing services or remote key manager 140. In some embodiments, the payee information may be used to identify the merchant certificate provided therein to the remote key manager 140 (e.g., in embodiments where the mobile payment application 123 passes the merchant certificate to the remote key manager 140).

[0153] Additionally, the payee information may include the type of transaction identifier, notifying the mobile payment application 123 to request association with a remote payment transaction. Accordingly, the mobile payment application 123 may select a suitable encryption key (e.g., a remote key manager key) for encrypting payment information, a suitable destination or routing address for the remote key manager 140, and the correct communication protocol or message format for communicating with the remote key manager 140.

[0154] Finally, the recipient information may also include the user's name and payment method (e.g., Visa). TM MasterCard TM (etc.) The associated payment processing network identifier, and the last four digits of the account number, so that the mobile payment application 123 can identify the payment credentials or account information used for remote payment transactions.

[0155] In some embodiments, some or all of this information may be determined and provided by the merchant application 121 instead of the remote transaction application 124. For example, where the merchant application 121 has an API embedded or other software for interacting with the mobile payment application 123, or may be otherwise configured to interact directly with the mobile payment application 123, the merchant application 121 may pass remote transaction information (e.g., payee information, merchant certificate, transaction details, etc.) to the mobile payment application 123. Alternatively, the remote transaction application 124 may receive transaction details, payee information, and / or the selection of the account used in the remote transaction.

[0156] In step 604, the remote transaction application 124 performs verification controls and otherwise ensures that the received transaction information is eligible for remote transaction processing. For example, the remote transaction application 124 may determine whether the selected account is configured to allow remote transactions or whether the corresponding payment processing network 160 is configured to allow remote transactions. Additionally, the remote transaction application 124 may verify the merchant certificate received from the merchant application 121 and may determine whether the merchant certificate can be verified using the certificate authority root public key. Furthermore, the remote transaction application 124 may ensure that the transaction information matches transaction constraints (e.g., maximum transaction amount, maximum transaction speed or frequency within a specified time period, etc.).

[0157] Furthermore, the remote transaction application 124 may require the user to authenticate and verify their identity before granting access to the mobile payment application 123. For example, the remote transaction application 124 may request user authentication data (e.g., shared secrets, passwords, etc.) associated with the issuer of the remote transaction application 124 and / or the account. If the user does not provide user authentication data or if the user authentication data does not match a specific format or type of information desired by the remote transaction application 124 (e.g., using unauthorized or excessively long symbols, etc.), the remote transaction application 124 may not allow the transaction to proceed. Any additional confirmation controls can be implemented to restrict access to the mobile payment application 123.

[0158] In step 605, if the transaction is eligible for further remote transaction processing, the remote transaction application 124 can pass the payee information to the mobile payment application 123 of the secure element 122. The remote transaction application 124 can use an API or other commands configured to communicate with the mobile payment application 123 to request the mobile payment application 123 (e.g., Visa). TM Paywave TMThe application provides payment credentials (e.g., primary account number (PAN), payment token, fake PAN, spoofed PAN, ghost PAN, expiration date, etc.) that are securely stored on the secure element 122.

[0159] In some embodiments, the remote transaction application 124 may forward transaction information to the mobile payment application 123. However, in other embodiments, the transaction information may be stored or retained in the remote transaction application 124, while the payment credential is retrieved from the mobile payment application 123. Further, in some embodiments, the transaction information may be pre-encrypted by the merchant computer 130 using a payment processing network-specific key. In such embodiments, the merchant application 121, the remote transaction application 124, and the mobile payment application 123 may not alter the transaction information, and the pre-encrypted transaction information, along with the encrypted payment information received from the mobile payment application 123, may be transmitted to the remote key manager 140.

[0160] In other embodiments, the transaction information may not be pre-encrypted and may be transmitted to the mobile payment application 123 to be encrypted and included therein in the encrypted payment information returned from the mobile payment application 123. Further, in some embodiments, the transaction information may not be encrypted and may be included together with the encrypted payment information in an unencrypted form.

[0161] In step 606, the mobile payment application 123 uses the received payee information to retrieve and / or generate payment information from the secure element 122 of the mobile device 120. The "payment information" may include payment credentials (e.g., payment account number (PAN) or token), expiration date, unique transaction identifier (e.g., current value), security values ​​(such as static or dynamic card confirmation values ​​(dCVV or dCVV2), passwords (e.g., ARQC), or other security data associated with a secret shared between the mobile payment application 123 and the payment processing network 160 and / or the account issuer), security level indicators (e.g., ECI5 value), or any other information suitable for executing a remote payment transaction. Accordingly, the mobile payment application 123 may generate security information, including security values ​​generated using a shared algorithm associated with the account issuer. The payment information may also include any transaction information that may be useful for processing the transaction (e.g., amount, merchant identifier, etc.).

[0162] After generating payment information associated with the payment information, the mobile payment application 123 uses a key associated with the remote key manager 140 to encrypt the payment information. For example, the mobile payment application 123 may use a remote key manager key or other encryption keys stored on the mobile payment application 123 to encrypt the payment information. The remote key manager key may be a symmetric key or a public key associated with a remote key manager public / private key pair. In some embodiments, the mobile payment application 123 may use a remote key manager certificate stored on the mobile device 120 to determine the remote key manager public key, may request a certificate from the remote key manager 140, or may obtain the remote key manager public key from the secure element 122 or the general memory of the mobile device 120. If the remote key manager key is a symmetric key, the symmetric key may be securely stored with the mobile payment application 123. Accordingly, the encrypted payment information is generated by the payment application of the communication device by accessing payment credentials stored in the secure memory of the communication device.

[0163] In step 607, the mobile payment application 123 sends payment information (encrypted or unencrypted) to the remote transaction application 124. The remote transaction application 124 receives the encrypted or unencrypted payment information, or encrypts the unencrypted payment information, and generates a payment request that includes the encrypted payment information, the merchant certificate associated with the merchant computer 130, and any other transaction data associated with the payment transaction not included in the encrypted payment information (e.g., transaction amount, merchant identifier, product identifier, etc.).

[0164] If the payment information is not yet encrypted, the remote transaction application 124 uses an encryption key associated with the remote key manager 140 to encrypt the payment information. For example, in some embodiments, the remote transaction application 124 may use one or more keys to establish a secure channel with the remote key manager 140 to securely transmit sensitive information to the remote key manager 140. For example, the remote transaction application 124 may receive a key from the mobile payment application 123 to encrypt the payment information in order to create a secure channel with the remote key manager 140. Additionally, in some embodiments, the remote transaction application 124 may store the remote key manager's encryption key and may use the remote key manager's encryption key to encrypt the payment information and any other information in the payment request.

[0165] In step 608, the remote transaction application 124 can transmit a payment request, including encrypted payment information, merchant certificates, and any transaction details, to the remote key manager 140. The encrypted payment information may include security information such as user authentication data (e.g., PIN, password, etc.) and security values ​​generated by the mobile payment application. Although in Figure 6 Not shown, however, in some embodiments, the remote transaction application 124 may initiate and generate a secure channel with the remote key manager 140, and may use a session key associated with the secure channel to transmit payment requests to the remote key manager 140. In such embodiments, a secure channel may be established using a session-derived key associated with a master-derived key that can be shared between the remote key manager 140 and a secure element of the communication device (e.g., via the remote transaction application 124 or the mobile payment application 123). In such embodiments, the session key may be used to send payment requests and receive payment responses from the remote key manager 140.

[0166] Accordingly, the communication device (e.g., mobile device 120) can send secure communications, including user authentication data (e.g., password, PIN, etc.) for verifying the user associated with the transaction, security values ​​for verifying the device associated with the transaction (e.g., mobile payment application password), and secure payment credentials and / or transaction data for processing remote transactions, to a single entity configured to complete the authentication process associated with both the user and device and the account issuer for remote payment transactions in a single step, and to determine the secure key associated with the merchant for processing the transaction after authentication. This is advantageous because such authentication processes typically require multiple separate processes and redirect to an authentication computer for direct communication between the communication device and the authentication computer or issuer system. Accordingly, the remote key manager provides a simple and efficient integration point for the authentication and secure processing of remote transactions initiated by the communication device.

[0167] In step 609, the transaction processing module 141(C) of the remote key manager 140 receives the payment request and decrypts the encrypted payment information using the corresponding encryption key (e.g., private key, corresponding symmetric key, session key, etc.) stored in the private key database 141(G) of the remote key manager 140. Accordingly, the remote key manager server computer can decrypt the encrypted payment information using a second encryption key (e.g., remote key manager private key) associated with a first encryption key (e.g., remote key manager public key) used for the encrypted payment information on the encrypted communication device. Accordingly, the remote key manager 140 can obtain the decrypted security information, including user authentication data (e.g., PIN, password, etc.) and security values ​​(e.g., passwords) generated by the mobile payment application 123 for the remote transaction, as well as payment credentials, transaction information, etc.

[0168] The remote key manager private key stored in the private key database 141(G) can include any suitable encryption key, including, for example, a symmetric encryption key or a private key of a public / private key pair. In various embodiments using the remote key manager private key, the private key is configured to decrypt information encrypted using the corresponding remote key manager public key. The remote key manager private key is securely stored on the remote key manager 140 so that the remote key manager 140 can decrypt information encrypted using the remote key manager public key. Similarly, the remote key manager symmetric key can be stored in the remote key manager 140 and used to decrypt encrypted payment information.

[0169] The certificate verification module 141(A) of the remote key manager 140 can also verify that the public key certificate (e.g., a merchant certificate) is legitimate and signed by the appropriate certificate authority 180 by applying the certificate authority root public key stored in the certificate authority public root key database 141(H), and verify that the verified merchant certificate received in the payment request is authentic. The certificate verification module 141(A) can extract the merchant public key included in the merchant certificate for further processing of remote transactions.

[0170] Furthermore, in embodiments where the transaction data received in the merchant application 121 is signed by the merchant computer 130, the remote key manager 140 can verify the received payment request by checking to ensure that the correct merchant public key is used to encrypt the transaction information (e.g., the merchant public key is associated with the received merchant certificate), that all aspects of the payment information are correct (e.g., the merchant identifier is associated with the registered merchant), and can perform any other suitable verification that can ensure that the payment request, including the encrypted payment information, is being sent by a legitimate payment application, the merchant computer 130, the merchant application 121, a communication device (e.g., the mobile device 120), etc.

[0171] For example, in some embodiments, the remote key manager 140 can verify a signature on any transaction data (if signed by the merchant computer 130 or the corresponding transaction processor using a received public key certificate). Typically, the signature can be verified by retrieving the merchant computer from the merchant certificate and using the public key included in the merchant certificate. Alternatively, in some embodiments, the public key may be registered and stored in the remote key manager 140 in association with the merchant certificate. If the signature is not verified, the remote key manager 140 indicates to the merchant application 121 that the signature is invalid, and the method ceases. It should be noted that the signing of transaction information by the merchant computer 130 and the verification of the signature by the remote key manager 140 are optional and may not occur at all or may occur periodically, thus avoiding the need to pass the signature from the merchant computer 130.

[0172] In step 610, the remote key manager 140 security information verification module 141(D) can obtain an authentication response value for remote transactions by initiating an authentication process using the authentication computer 191. As described above, the remote key manager 140 security information verification module 141(D) can obtain the authentication response value through different methods. For example, for Figure 6 In the illustrated embodiment, the security information verification module 141(D) of the remote key manager 140 can generate an authentication request and send it to the payment processing network 160. The authentication request may include decrypted security information, including user authentication data (e.g., PIN, password, etc.) and security values ​​(e.g., passwords) generated by the mobile payment application for remote transactions, as well as payment credentials, transaction information, and any other relevant information used to verify the authentication request.

[0173] In some embodiments (not shown), the remote key manager 140 may be associated with or part of the payment processing network 160, and can obtain an authentication response value by identifying the authentication computer 191 associated with the decrypted payment information and sending an authentication request, including security information, directly to the authentication computer. For example, the remote key manager 140 functionality may be embedded in the payment processing network 160, and the remote key manager 140 may access a directory server database without sending the authentication request to the payment processing network 160. However, for... Figure 6 In the illustrated embodiment, the remote key manager 140 can send authentication requests to the payment processing network 160 to authenticate the user and device associated with the remote payment transaction.

[0174] In step 611, the security information verification module 161(D) of the payment processing network 160 receives the authentication request message and determines the authentication computer 191 associated with the authentication request. Depending on the configuration of the payment processing network 160, the security information verification module 161(D) of the payment processing network 160 can determine the authentication computer 191 associated with the authentication request through several different processes. For example, the security information verification module 161(D) can determine the authentication computer 191 directly by using the directory server functionality embedded in the payment processing network 160, by requesting the identity of the authentication computer 191 from the directory server computer 190, or by forwarding the authentication request to the directory server via the directory server interface module 161(C).

[0175] exist Figure 6 In the embodiment shown, the security information verification module 161(D) of the payment processing network server computer 161 can forward an authentication request to the directory server computer 190. The directory server computer 190 can determine the identity of the authentication computer 191 associated with the authentication request and forward the authentication request to the authentication computer 191. Accordingly, in step 611, the payment processing network can forward the authentication request to the directory server computer 190 to identify and authenticate the authentication computer 191 for the authentication request. Accordingly, the payment processing network server computer 161 can send decrypted security information to the directory server computer 190. The decrypted security information includes user authentication data (e.g., PIN, password, etc.) and security values ​​(e.g., passwords) generated by the mobile payment application for remote transactions, as well as payment credentials, transaction information, and any other relevant information used to verify the authentication request.

[0176] However, in other embodiments (not shown), the payment processing network server computer 161 may include the functionality of the directory server computer 190, thus allowing direct identification of the authentication computer 191. Accordingly, the security information verification module 161(D) of the payment processing network 160 can determine the identity of the authentication computer 191 associated with the authentication request, after which the payment processing network computer 161 can forward the authentication request to the authentication computer 191. The security information verification module 161(D) of the payment processing network 160 can determine the identity of the authentication computer 191 by identifying the account issuer associated with the authentication request, searching the issuer authentication configuration database 161(E) to find the authentication computer 191 associated with the account issuer, and then the payment processing network computer 161 can forward the authentication request to the authentication computer 191.

[0177] For example, an authentication request may include decrypted payment information, including an account identifier (e.g., PAN) associated with a remote payment application. The security information verification module 161(D) of the payment processing network 160 may determine the account issuer associated with the account information (e.g., by extracting an issuer identifier (e.g., BIN) from the account identifier (e.g., PAN)) and search the account issuer authentication configuration database 161(E) to find authentication computers 191 configured to process authentication requests associated with the determined issuer and / or with the determined account range associated with the account information (e.g., issuers of different authentication computers associated with different types of accounts or account ranges, etc.).

[0178] Furthermore, in some embodiments, more than one authentication computer 191 may be identified for a single authentication request. For example, a first authentication computer 191 associated with the payment processing network 160 may be identified for "representative" authentication of the security value generated by the mobile payment application 123, while a second authentication computer 191 associated with the account issuer may be identified for verification of the user authentication data. Accordingly, the security information verification module 161(D) may send authentication requests to two authentication computers configured to perform authentication for each specific type of security information.

[0179] Accordingly, the security information verification module 161(D) of the payment processing network 160 can perform security value authentication on behalf of the account issuer by searching the issuer-shared secret database 161(F) to find shared secrets associated with the issuer, account, or mobile payment application 123 used to generate the security value. The shared secrets may include algorithms, lookup tables, or any other information associated with the account, device, and / or mobile payment application 123 provided by the account issuer during the process of providing the account on the secure element 122 of the communication device. Alternatively or additionally, the account issuer may provide a master shared secret key, which can be used to generate derived shared secret keys for each account associated with the issuer. In any case, the security information verification module 161(D) of the payment processing network 160 can retrieve the appropriate shared secret associated with the authentication request, determine the security value for the authentication request, and compare the determined security value with the received security value to verify that the mobile payment application 123 is reliable and authenticated.

[0180] Depending on the type of shared secret associated with the authentication request, a security value can be determined by any suitable method. For example, in the case where the security value is dynamic, the security information verification module 161(D) can retrieve a shared secret algorithm from the issuer's shared secret database 161(F) and apply the input data received from the authentication request to the shared secret algorithm. For example, the last four digits of the PAN, the expiration data, and the nonce (i.e., an unpredictable value received from the mobile payment application 123) can be applied to the determined shared secret algorithm to generate the security value for the authentication request.

[0181] In embodiments where the security value is static, the security information verification module 161(D) can search the issuer-shared secret database 161(F) for statically shared secrets associated with an account, issuer, mobile payment application 123, user, or any other variable associated with the shared secret database. For example, if the shared secret is a static card confirmation value (CVV), the security information verification module can search the issuer-shared secret database 161(F) for entries associated with the PAN and can determine the static CVV associated with the issued card and / or account. Therefore, the payment processing network 160 or authentication computer 191 can use any suitable method to determine and verify the security value.

[0182] However, as Figure 1 As shown, in some embodiments, the payment processing network 160 may forward the authentication request to a directory server, which may determine the relevant authentication computer 191 associated with the authentication request. Alternatively, the payment processing network 160 may request the identity of the authentication computer 191 from the directory server computer 190 and then send the authentication request to the authentication computer 191. The directory server computer 190 may perform a process similar to that described above for identifying the authentication computer 191 associated with the authentication request.

[0183] In step 612, the directory server computer 190 may receive an authentication request that includes decrypted security information. The decrypted security information may include user authentication data (e.g., PIN, password, etc.) and security values ​​(e.g., passwords) generated by the mobile payment application for remote transactions, as well as payment credentials, transaction information, and any other relevant information used to verify the authentication request. The directory server computer 190 may determine the authentication computer associated with the authentication request through the same process described above with reference to the payment processing network 160, including, for example, determining the issuer identifier (e.g., BIN) associated with the payment credentials in the authentication request, and searching an issuer authentication configuration database or any other database that includes the authentication computer address and the account issuer associated with the authentication computer 191 associated with the determined issuer identifier (e.g., BIN).

[0184] Once the directory server computer 190 determines the authentication computer 191 associated with the authentication request, it can forward the authentication request to the determined authentication computer 191. Note that authentication requests received from the payment processing network server computer 161 and forwarded to the authentication computer 191 can be received and sent via an encrypted communication channel, thus protecting the authentication request and included security information and preventing interception by malicious third parties. Any suitable encryption key can be used to encrypt and decrypt each communication between the various entities during the encryption process (e.g., steps 610-616) so that the encryption process at each step is prevented from being intercepted.

[0185] In step 613, the authentication computer 191 may receive an authentication request including security information, and may verify the security information and generate an authentication response including an authentication response value. As described above, the authentication computer 191 may be operated by the account issuer, by the payment processing network 160 representing the account issuer, or by a third-party system.

[0186] The authentication computer 191 can verify the security information in the authentication request by comparing the user authentication data entered by the user with the security verification information stored in the authentication database. This verification can be done by comparing the user authentication data with the security verification information. For example, the authentication database may store shared secrets provided to the mobile payment application 123 for communication devices, as well as user authentication data stored by the account issuer during the registration process or during the verification of other user accounts.

[0187] The authentication computer 191 can verify the security value using the same process described above for verifying the security value for the payment processing network server computer. Therefore, the authentication database can store shared secret algorithms, lookup tables, or any other verifiable information that can be used to determine the security value of an account, and compare the determined security value with the security value received in the authentication request. If the security values ​​match, the authentication request can be verified as originating from a genuine communication device, mobile payment application 123, and / or remote transaction application 124.

[0188] For example, a verification security value (e.g., a password) can be generated by the payment processing network 160 using transaction information and / or payment information received in the authentication request. If the received password matches the generated verification password, the authentication computer 191 can confirm that the payment information was generated by a valid and reliable mobile payment application 123.

[0189] Similar to security value verification, the authentication computer 191 can verify user authentication data (e.g., PIN, password, etc.). Therefore, the authentication database can store user authentication data (e.g., PIN, password, etc.) associated with consumer accounts. This user authentication data can be used to determine the stored user authentication data for an account, and the determined user authentication data can be compared with the user authentication data received in the authentication request. If the authentication data is the same or matches within a reasonable threshold, the authentication request can be verified as associated with, or initiated by, an authorized user or account holder.

[0190] For example, user authentication input (e.g., a password) can be entered by the user during the initiation of a remote payment transaction. The password can be transmitted to a remote key manager 140 within encrypted payment information, which may include user authentication data (e.g., the password) in an authentication request sent via payment processing network 160 to an authentication computer 191 associated with the account issuer of the user's account. The authentication computer 191 can look up stored user authentication data (e.g., the password) in an authentication database associated with the user's account and can compare and verify that the stored user authentication data (e.g., the password) matches the received user authentication data (e.g., the password).

[0191] Alternatively or in combination, the authentication computer 191 can determine whether the mobile payment application 123, the remote transaction application 124, the payment processing network 160, and / or other trusted entities have pre-authenticated the consumer 110, and can use this information to determine whether to perform a consumer authentication process and whether the authentication request has been authenticated. For example, in some embodiments, the issuer may provide shared secret information associated with the consumer account to the personalized mobile payment application 123 or remote transaction application 124 in the secure element 122. Therefore, the mobile payment application 123 or remote transaction application 124 can verify the received user authentication data (e.g., password) against the supplied user authentication data (e.g., password) and determine whether the user is reliable. If the user authentication data matches (thus, the consumer is authenticated), the authentication result (e.g., the authenticated user) can be provided in the payment request generated and sent to the remote key manager 140 and subsequently included in the authentication request forwarded to the authentication computer 191.

[0192] Therefore, the authentication computer 191 can determine whether a user has been pre-authenticated, by which entity or application, and whether additional authentication can be performed. The authentication computer 191 can control the authentication decisions associated with the authentication request. Thus, in some embodiments, security information including a cardholder verification method performed by the mobile payment application 123 or the remote transaction application 124 before initiating a transaction can be transmitted to the payment processing network computer 161, the directory server computer 190, and the authentication computer 191, and used to authenticate remote transactions.

[0193] Additionally, any number of internal or external authentication processes can be used to further authenticate the authentication request. For example, risk-based, stored credential, challenge-response, or any other type of consumer authentication process can be performed. In some embodiments, the remote key manager 140 can request authentication information from the consumer 110 via authentication requests, challenges, password requests, or any other suitable method.

[0194] If the authentication process is successful and the security information is verified, the authentication computer 191 can generate an authentication response value for the transaction (e.g., verifying a password) using a shared secret authentication response algorithm associated with the account issuer computer 170 and / or the payment processing network 160. The authentication response value can be verified by the account issuer computer 170 or the payment processing network 160 during the authorization process to provide an additional level of authentication for the transaction by indicating that the transaction was pre-analyzed and authenticated by the authentication computer 191. Additionally, a security level indicator can be modified or provided in the authentication response, indicating to other entities within the transaction processing ecosystem that the transaction was authenticated using two-factor user and device security information. The security level indicator can allow other entities in the transaction to modify their behavior in any number of different ways and can indicate to other entities which party bears responsibility for the transaction (e.g., the payment processing network, not the merchant, etc.).

[0195] In step 614, the authentication computer 191 may generate an authentication response including an authentication response value, an enhanced security level indicator, and / or a success indication of the authentication processor, and return it to the directory server computer 190 or the payment processing network 160 (depending on the system configuration). Alternatively, if the authentication process is unsuccessful, an error or other rejection may be returned and the transaction may be stopped.

[0196] In step 615, the directory server computer 190 may receive the authentication response and forward it to the payment processing network server computer. The authentication response may include an authentication response value, a security level indicator, and a success indication (as well as any of the following: security information, transaction information, payment credentials, etc.). Note that communication may be encrypted between each entity to ensure security and an end-to-end encryption process.

[0197] In step 616, the payment processing network server computer 161 may receive the authentication response message, identify the remote key manager 140 associated with the authentication response message, and send the authentication response message to the remote key manager 140. The authentication response may include an authentication response value, a security level indicator, and a success indication (as well as any of the following: security information, transaction information, payment credentials, etc.). Note that communication may be encrypted between each entity to ensure security and an end-to-end encryption process.

[0198] In step 617, the remote key manager 140 can receive an authentication response from the payment processing network 160 and determine the result of the authentication process. Therefore, if the authentication process is successful and the remote key manager 140 receives an authentication response including an authentication response value (e.g., a verification password) indicating verification of security information by an authentication computer 191 associated with the account issuer and / or the payment processing network 160, the remote key manager 140 can continue with remote transaction processing.

[0199] Therefore, the remote key manager 140 can update the decrypted payment information to include the authentication response value, security metrics, and any other verification information from the authentication response. In some embodiments, the security information can be replaced by the authentication response value and / or the security metrics. In other embodiments, the authentication response value and security metrics can be appended to or added to the decrypted payment information.

[0200] If the remote key manager 140 has not yet extracted the merchant's public key, its public key extraction module 141(B) can extract the public key from the merchant certificate (or other transaction processor certificate). The transaction processing module 141(C) of the remote key manager 140 can then use the determined merchant public key to re-encrypt the payment information. As described above, the merchant's public key can be included in the merchant application certificate and extracted at any point during the remote transaction processing. The remote key manager 140 can determine the merchant's public key in any suitable manner, including extracting the public key from the merchant certificate, using the merchant's stored public key registered with the remote key manager 140, or by any other suitable method.

[0201] In step 618, the transaction processing module 141(C) of the remote key manager 140 generates a payment response, including the re-encrypted payment information, and sends it to a communication device (e.g., mobile device 120). The payment response can be sent via a secure channel pre-established for receiving payment requests, or the encrypted payment information can be sent to the remote transaction application 124 of the mobile device 120 via an open channel. Therefore, in some embodiments, the re-encrypted payment information can be further encrypted using a session key pre-established for secure communication between the remote key manager 140 and the mobile device 120.

[0202] In step 619, the remote transaction application 124 receives the re-encrypted transaction response and forwards the re-encrypted payment information from the transaction response to the merchant application 121. Any number of different methods can be used to send the re-encrypted payment information to the merchant computer 130. For example, the payment response message may include unencrypted routing information associated with the merchant computer 130 so that the merchant application 121 can automatically route the re-encrypted payment information to the merchant computer 130. Alternatively or additionally, the merchant application 121 may have routing information (e.g., a server computer address) programmed into the merchant application 121 associated with the merchant computer 130, so that when a transaction is initiated, the merchant application 121 knows that any corresponding payment response message can be routed to the merchant computer 130. Furthermore, flags or other data elements in the received message, including the re-encrypted payment information, may indicate to the merchant application 121 where and in which entity the re-encrypted payment information is sent.

[0203] Additionally, in some embodiments, the remote key manager 140 can be configured to send payment responses directly to the merchant computer 130. Therefore, the remote key manager 140 can use address information contained in the merchant certificate, merchant information provided during registration for the remote payment processing service, or merchant information provided in the purchase request to determine the appropriate merchant server computer to which the purchase response should be sent directly.

[0204] In step 620, merchant application 121 sends the re-encrypted payment information to merchant computer 130. Merchant application 121 can determine the appropriate merchant computer 130 for sending the re-encrypted payment information using any suitable method. For example, routing information can be included in the payment response, and when the payment is initiated, merchant application 121 may have the destination merchant computer 130 associated with the remote payment transaction, or merchant application 121 may have a designated merchant computer 130 to send the payment response.

[0205] In step 621, the merchant computer 130 receives the re-encrypted payment information and decrypts it using the merchant's private key stored on the merchant computer 130. Thus, at the first moment of remote transaction processing, the merchant computer 130 can access encrypted payment information (e.g., payment credentials and / or other security information including authentication response values) retrieved by the mobile payment application 123 from the secure storage of the mobile communication device. For example, the merchant server can obtain the account identifier (e.g., Master Account Number (PAN)) and expiry date associated with the spending account, as well as transaction-specific security values ​​and authentication response values. Authentication response values ​​(e.g., Card Authentication Confirmation Value (CAVV)) provide additional authentication and verification opportunities for the payment processor and / or issuer, minimizing the risk of fraud in remote transactions. Therefore, the merchant server computer now possesses secure payment credentials, authentication response values ​​(e.g., CAVV), security level indicators and / or liability indicators, transaction information, and any other relevant information used to initiate the payment transaction.

[0206] Accordingly, merchant computer 130 can use the decrypted payment information to initiate and / or execute payment transactions. For example, merchant computer 130 can generate an authorization request message that includes information typically present in a "card presence" transaction (e.g., payment credentials, security values, etc.), along with an authentication response value indicating that consumer 110 has been pre-authenticated to conduct the transaction. Accordingly, merchant computer 130 can map the decrypted payment information (and other transaction information included in the payment response) to a format associated with the authorization request message of merchant computer 130, acquiring computer 150, payment processing network 160, and issuing computer 170.

[0207] In step 622, merchant computer 130 can initiate a payment transaction by sending an authorization request message to acquiring computer 150 associated with merchant computer 130. The authentication request message may contain decrypted payment information mapped to predetermined fields within the authorization request message, allowing transaction entities within the transaction ecosystem (e.g., acquiring computer 150, payment processing network 160, issuing computer 170, etc.) to identify the payment credentials (e.g., account) and authentication level associated with the transaction and process the transaction.

[0208] In step 623, the acquiring computer 150 may route the authorization request message to the payment processing network 160 associated with the issuer identifier (e.g., BIN) or account identifier (e.g., primary account identifier) ​​provided in the authorization request message.

[0209] In step 624, the payment processing network 160 may receive an authorization request message and may verify the authentication response value in the authorization request message. The payment processing network 160 may parse the authorization request message to determine the authentication response value and may access a secret algorithm or other cryptographic key shared by the authentication response that can be used to verify the authentication response value received in the authentication request message. For example, the secret algorithm shared by the authentication response value may include a remote key manager key, an account issuer key, or a payment processing network key used to generate the authentication response value to generate the authentication value verification. If the authentication value and the authentication response value match, the payment processing network 160 may know that the transaction has been pre-authenticated and determines that the likelihood of the transaction being fraudulent is low. Accordingly, the transaction may be authorized immediately or additional authentication information may be provided to the issuer to notify them that the transaction is likely reliable and should be authorized.

[0210] Alternatively or additionally, through a similar verification process as described above, the issuing computer 170 can authenticate the authentication response value using a secret key shared by the issuing party, which is used by the authentication computer 191 to generate the authentication response value. Therefore, after the initiation of a payment transaction and during its processing, the authentication response value can be verified by the payment processing network 160 or the account issuing computer 170.

[0211] In step 625, the payment processing network 160 forwards the authorization request message to the issuer computer 170 associated with the consumer account.

[0212] In step 626, the issuer computer 170 can perform a risk assessment and authorization decision process, wherein the issuer computer 170 can parse relevant information from an authorization request message, which includes an authentication response value, any verification information from the payment processing network 160 associated with the transaction (e.g., risk score, results of other authentication processes, etc.), and the issuer computer 170 can make a decision about whether the transaction is authorized.

[0213] In step 627, the issuing computer 170 may then generate an authorization response message (including an indication of whether the transaction has been authorized) and return it through the payment network, ultimately (though not shown) to the merchant computer 130 and the consumer 110 (via the mobile device 120) to indicate whether the transaction has been authorized and whether it has been successfully completed.

[0214] It should be understood that Figure 6This is descriptive, not restrictive. For example, any number of different entities can be used to decrypt the re-encrypted payment information (e.g., mobile gateways, mobile wallet providers, payment processing networks, etc.). Additionally, other transaction processing entities (e.g., merchant application 121, acquiring computer 150, payment service providers, etc.) can also be configured to decrypt the re-encrypted payment information and initiate payment transactions.

[0215] II. Additional Examples

[0216] In addition, although Figure 6 The illustration shows a merchant computer 130 initiating a payment transaction by decrypting re-encrypted payment information and mapping the decrypted payment information to an authorization request message. However, additional exemplary methods can be used to complete remote transactions using a merchant application 121 on a remote key manager 140 and a mobile device 120, based on the identity of the transaction processor associated with the remote payment transaction. For example, a transaction processor certificate can be used to identify the transaction processor associated with decrypting the re-encrypted payment information and initiating the remote transaction. For example, the remote key manager 140 can use public keys associated with multiple different transaction processing entities, such as the merchant application 121, the merchant computer 130, the acquiring computer 150, the payment service provider (PSP), etc., to re-encrypt the payment information. Therefore, the transaction processor can vary depending on the certificate passed during transaction processing and system configuration.

[0217] For example, instead of using the merchant's public key to encrypt payment information, a merchant application public key (associated with a private key stored on merchant application 121) or an acquirer's public key (associated with a private key stored on the acquirer's computer) can be used to encrypt the payment information. The re-encrypted payment information can then be delivered to each relevant entity (e.g., the merchant server computer or acquirer computer 150) for decryption and authorization request message generation. Accordingly, depending on the configuration of the remote transaction processing system, in some embodiments, any number of public key certificates (e.g., merchant application public key certificate, merchant public key certificate, acquirer public key certificate, etc.) can be delivered to the remote key manager 140. Once the re-encrypted payment information is returned from the remote key manager 140, the merchant application 121 can determine which public key certificate should be provided and the routing information for the encrypted payment information.

[0218] Accordingly, the identity of the transaction processor certificate can include any of the merchant application 121, merchant computer 130, or acquiring computer 150. Therefore, the remote key manager 140 can use the public key extracted from the received public key certificate to verify the received public key certificate, decrypt the encrypted payment information (e.g., account identifier and password), and re-encrypt the decrypted payment information (e.g., card data and password). As described above, the public key certificate can be associated with any transaction processor, including, for example, merchant computer 130, merchant application 121, or acquiring computer 150. Subsequently, the remote key manager 140 can send the re-encrypted payment information to the transaction processing entity (e.g., merchant application 121, merchant computer 130, acquiring computer 150, etc.) associated with the received public key certificate (and the public key subsequently used to encrypt the payment information).

[0219] For example, in a first embodiment, the public key certificate may include a merchant application public key certificate, which the remote key manager 140 verifies and extracts or otherwise obtains the merchant application public key. The merchant application public key is then used to re-encrypt the decrypted payment information, and the remote key manager 140 sends the re-encrypted payment information to the merchant application 121. The merchant application 121 can receive the re-encrypted payment information, determine the merchant application private key associated with the re-encrypted payment information, and use the merchant application private key to decrypt the re-encrypted payment information. Accordingly, the merchant application 121 may have sensitive information stored on the secure element 122 and security information generated using a security algorithm for payment transactions from the mobile payment application 123.

[0220] Merchant application 121 can then use the decrypted payment information to initiate a payment transaction. Merchant application 121 can use any suitable method to initiate the payment transaction. For example, merchant application 121 can generate an authorization request message configured to be sent via payment processing network 160. Alternatively, although in Figure 6 Not shown, but merchant application 121 can use the merchant server key to re-encrypt the decrypted payment information and send it to merchant computer 130 for decryption and initiation of a payment transaction. Thus, the decrypted payment information can be passed to merchant computer 130 for the generation of an authorization request message or other initiation of a payment transaction. A similar process can be applied to any other transaction processor (e.g., acquiring computer, payment service provider system, etc.).

[0221] Additionally, in some embodiments, the remote key manager may include a mobile gateway to the payment processing network 160, which can perform all the functions of the remote key manager 140 and the payment processing network 160 described above. Therefore, the mobile device 120 can directly transmit encrypted payment information of a payment request to the payment processing network 160, which is configured to process remote payment transactions. Thus, the remote key manager 140 and the encryption key used for communication between the mobile payment application 123 and the remote key manager 140 can be associated with the payment processing network 160.

[0222] The mobile gateway (not shown) may include a secure channel generation module configured to establish a secure communication link between the mobile gateway, mobile device 120, and payment processing network computer 161. The secure channel generation module can exchange any relevant information so that the mobile payment application 123 and the mobile gateway generate matching or complementary session keys for securely transmitting sensitive information. Any other suitable methods for generating the secure channel can be implemented.

[0223] Further information regarding the capabilities of the mobile gateway 190 can be found in U.S. Patent No. 13 / 662,843, filed October 29, 2012, entitled “Over The Air Update of Payment Transaction Data Stored in Secure Memory”; U.S. Patent Application No. 12 / 563,410, filed September 21, 2009, entitled “Apparatus and Method for Preventing Unauthorized Access to Payment Application Installed in Contactless Payment Device”; and U.S. Patent Application No. 13 / 563,421, filed September 21, 2009, entitled “Over The Air Update of Payment Transaction Data Stored in Secure Memory”, which are incorporated herein by reference in their entirety for all purposes.

[0224] In various embodiments with a mobile gateway, a secure channel can be established, and communication can be sent between the mobile payment application 123, the mobile gateway associated with the payment processing network 160, and the payment processing network computer 161 to initialize and prepare the secure channel. The secure channel allows future communications between the mobile device 120 and the payment processing network 160 to be encrypted and protected from interception.

[0225] Secure channels can be established in any suitable manner. For example, a secure channel can be established using a mobile gateway encryption key provided to the mobile payment application 123 during the personalization process of the mobile payment application 123. Accordingly, the encryption key used to establish the secure channel may include a session key that changes for each session or remote payment transaction. A similar process is described in U.S. Patent Application No. 13 / 075,592, filed March 30, 2011, and granted to Aabye et al., which is incorporated herein by reference.

[0226] Furthermore, the encryption key can be a unique derived key (UDK) derived from the master key provided by the issuer of the mobile payment application 123, a trusted service manager (TSM) associated with the secure element 122, or the issuer of the secure element. Additionally, as those skilled in the relevant technology will recognize, any other suitable encryption method can be implemented. Thus, secure connections can be implemented using data encryption standards such as, for example, RSA with a key of at least 124 bits, Triple Data Encryption Standard (DES), 128-bit Advanced Encryption Standard (AES), the RC4 stream encryption algorithm using a minimum 128-bit key length, and so on.

[0227] After establishing a secure channel, the mobile payment application 123 can use the payment credentials stored in the secure element 122 and a mobile gateway encryption key (e.g., a shared encryption key or a method for generating a unique derived key for each session) stored in the secure element 122 to generate and send a payment request containing encrypted payment information. Therefore, the mobile gateway can decrypt the encrypted payment information provided by the mobile payment application 123 without affecting the encrypted transaction information transmitted from the merchant server and encrypted using the payment processing network's public key. Thus, the mobile gateway can use one encryption key for communication on the secure channel, while the payment processing network 160 can use different encryption keys to decrypt the encrypted transaction information provided by the merchant computer 130. Therefore, the mobile payment application 123 can use a first key (e.g., a session key) to generate and securely transmit payment credentials and consumer information stored in the secure element 122 of the mobile device 120, while the payment processing network 160 can use a second key (e.g., a payment processing network private key) to decrypt the transaction information transmitted from the merchant server computer.

[0228] Additionally, in some embodiments, a token registry or token vault may be implemented on the payment processing network 160 to enable the payment processing network 160 to de-tokenize tokens received as part of an authentication request to determine the account used to authenticate a remote transaction and the corresponding account issuer, as described above. Therefore, the payment processing network 160 may also be communicatively coupled to or merged with a token registry, which may include any database or other storage, wherein tokens may be issued to communication devices and associated with issuer accounts to enable the use of tokens in place of a Master Account Number / Identifier (PAN) to process transactions.

[0229] Additionally, in some embodiments, the remote key manager 140 may include a third-party service provider system (e.g., a mobile wallet provider). For example, the third-party service provider may include any entity with an interest or relationship to the consumer 110, mobile device 120, merchant, payment processing network 160, or any other payment transaction processing method or system. For example, the third-party service provider system may include a mobile wallet provider, mobile device manufacturer, mobile network operator, or any other entity that can connect to merchant and consumer devices. Accordingly, various embodiments of the present invention may allow the third-party service provider system to register merchants and manage the authentication process for merchants' remote transactions, thereby providing more secure processing of remote transactions.

[0230] Finally, while the embodiments focus on remote payment transactions, they are not limited to such transactions, and the authentication concepts described herein can be used for many different types of transactions. For example, the embodiments can be used to authenticate and authorize supply processes, card or account confirmation / verification processes, and / or any other issuer or other service provider processes, where authentication may be helpful when using communication devices.

[0231] Thus, authentication request and response messages transmitted via remote key manager 140 can be used to obtain authentication for any relevant activity from the relevant service provider or interested party. For example, in the case of a user provisioning process, prior to providing an account on a communication device, the authentication process and system described herein can be used to authenticate the user's Know Your Customer (KYC) information (e.g., Social Security number, date of birth, postal code, etc.) or any other personal information to allow the issuer to authenticate the consumer 110 or the account during the provisioning process. Therefore, during account provisioning on a mobile device, the consumer 110 can enter their user authentication data, personal information, answers to prompt questions, or any other relevant information, along with their account credentials (e.g., PAN, expiry date, etc.), into the remote transaction application 124 to initiate the provisioning of account information over communication and obtain authorization from the authentication computer 191 associated with the account issuer.

[0232] Such authentication and verification processes can be implemented using account provisioning requests, in conjunction with... Figure 6 Similar to the process shown above, the account supply request can allow consumer 110 to request personalization of mobile payment application 123 using specific account information associated with the account issuer using remote key manager 140.

[0233] For example, the interaction between the remote transaction application 124, the mobile payment application 123, the remote key manager 140, the payment processing network 160, the directory server computer 190, and the authentication computer 191 can be... Figure 6 The same applies as shown. However, instead of transmitting encrypted payment information associated with a remote payment transaction, consumer 110 can enter and transmit encrypted personal information and payment credentials associated with an account, allowing the issuer to: identify the account; authenticate consumer 110 as associated with known information about consumer 110 (e.g., KYC information of the account holder); and make an authorization decision regarding the supply process, as well as provide an account supply response that allows the supply system to initiate the supply of account information.

[0234] The account provisioning response may include any information that the provisioning system can use to provision the account on the communication device. For example, the account provisioning response may include a provisioning response value (or any other indicator) that authorizes the provisioning system to provision the account on the communication device. Additionally, the account provisioning response may include a generated account provisioning script or other formatted information and / or instructions that can be used to provision the account on the communication device. Accordingly, the provisioning script may be transmitted to the provisioning system or trusted service manager associated with the issuer, authentication computer 191, payment processing network 160, communication device, or any other entity in the remote transaction processing system to provision the account on the communication device.

[0235] Additionally, the account provisioning response may include user authentication data (e.g., PIN, password, password, etc.) that can be used during the remote payment transaction processing described above. Accordingly, authentication infrastructure can be used to establish the user authentication data to be used in conjunction with the payment transaction. In some embodiments, the user authentication data may be returned in the account provisioning response, which is provided via the methods described above. Figure 6 The authentication system shown in steps 613-618 is sent back. In some embodiments, user authentication data can be delivered via another channel or another known communication method (e.g., email, SMS, etc.) in addition to the account provisioning response to ensure that consumer 110 obtains user authentication data via a second or separate communication method. System security can be further guaranteed by ensuring that consumer 110 can access existing communication methods to obtain user authentication data.

[0236] Therefore, in some embodiments, consumer 110 can input personal information into a remote transaction application 124, a mobile payment application 123, or any other mobile device to authenticate themselves during a supply request provided to authentication computer 191 via remote key manager 140. The mobile application or remote transaction application 124 can pass account credentials to the mobile payment application 123, which can encrypt the personal information using a stored encryption key, as described above. The mobile payment application 123 can then pass the encrypted personal information to the remote transaction application 124 for transmission to the remote key manager 140. The remote key manager 140 can decrypt the personal information and / or account information and initiate a process as described in reference [reference missing]. Figure 6 The authentication process described in steps 610-616.

[0237] For example, account credentials / information included in the supply request can be used to identify the authentication computer 191, which can then compare the personal information with registered consumer information associated with the account to verify the consumer 110. For example, social security number, address, date of birth, or any other information can be provided by the consumer 110 and verified as part of the supply request verification. After verifying the consumer 110, the authentication computer 191 can generate a script or otherwise return an account supply response message indicating that the supply system can supply the account information on the communication device.

[0238] Therefore, the advantages provided by the various embodiments of the present invention can be offered in addition to remote payment transactions, which can allow for an efficient authentication process for communication devices to connect with authentication systems used for any type of authentication process.

[0239] III. Exemplary Computer Device

[0240] Figure 7 It is a high-level block diagram of a computer system that can be used to implement any of the entities or components described above. Figure 7 The subsystems shown are interconnected via system bus 775. Additional subsystems include a printer 703, a keyboard 706, a disk 707, and a monitor 709 coupled to a display adapter 704. Peripheral devices and input / output (I / O) devices coupled to I / O controller 700 can be connected to the computer system via any number of means known in the art, such as serial ports. For example, serial port 705 or external interface 708 can be used to connect computer devices to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus 775 allows central processing unit 702 to communicate with each subsystem and control the execution of instructions from system memory 701 or disk 707, as well as the exchange of information between subsystems. System memory 701 and / or disk can embody computer-readable media.

[0241] Storage media and computer-readable media for containing code or multiple portions of code may include any suitable media known or used in the art, including storage media and communication media, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing and / or transmitting information such as computer-readable instructions, data structures, program modules or other data, including RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, data signals, data transmission, or any other medium that can be used to store or transmit desired information and is accessible by a computer. Based on the disclosure and teachings provided herein, those skilled in the art will understand other ways and / or methods for implementing the various embodiments.

[0242] The foregoing description is illustrative only and not restrictive. Many variations of the invention will become apparent to those skilled in the art upon reading this disclosure. Therefore, the scope of the invention may not be determined by reference to the foregoing description, but rather by reference to the claims to be examined and their full scope or equivalents.

[0243] It is understood that the invention described above can be implemented in a modular or integrated manner, using computer software, or in the form of control logic. Based on the disclosure and teachings provided herein, those skilled in the art will recognize and understand other ways and / or methods of implementing the invention using hardware and combinations of hardware and software.

[0244] Any of the software components or functions described in this application can be implemented as software code, which is executed by a processor using, for example, conventional or object-oriented techniques and using any suitable computer language (such as, for example, Java, C++, or Perl). The software code can be stored as a series of instructions or commands on a computer-readable medium such as random access memory (RAM), read-only memory (ROM), magnetic media such as hard drives or floppy disks, or optical media such as CD-ROMs. 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.

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

[0246] References to “a” (“a”, “an”) or “the” are intended to refer to “one or more” unless specifically indicated otherwise.

Claims

1. A method comprising: On a mobile device, a mobile payment application retrieves payment information, including security information such as passwords and user authentication data, from a secure storage device. The mobile payment application uses a first encryption key to encrypt the payment information to form encrypted payment information; The mobile device provides a payment request to a server computer including the encrypted payment information, wherein the server computer is programmed to decrypt the encrypted payment information using a second encryption key, receive an authentication response value from the authentication computer in the payment information after sending the security information to the authentication computer, and re-encrypt the payment information using a third encryption key, wherein the authentication response value indicates verification of the security information by the account issuer associated with the account information in the decrypted payment information, and the verification of the security information includes comparing a password from the received security information with a password generated by the authentication computer, and comparing user authentication data from the received security information with user authentication data stored in an authentication database; as well as The mobile device receives a payment response from the server computer, which includes re-encrypted payment information, wherein a transaction processor associated with the mobile device decrypts the re-encrypted payment information using a fourth encryption key and initiates a payment transaction using the decrypted payment information.

2. The method of claim 1, wherein the transaction processor is a merchant application on the mobile device.

3. The method of claim 1, wherein the authentication computer is operated by the payment processing network on behalf of the account issuer.

4. The method of claim 1, wherein the payment information includes a payment voucher.

5. The method of claim 4, wherein the payment credential includes a payment token.

6. The method of claim 1, wherein the security information further includes device-specific security values.

7. The method of claim 6, wherein the payment request further includes a transaction processor certificate, and the server computer uses the transaction processor certificate to determine the third encryption key by: Verify that the transaction processor certificate is trustworthy; The transaction processor certificate is verified to be currently valid using a Certificate Authority; and Extract the third encryption key from the transaction processor certificate.

8. The method of claim 1, wherein the transaction processor initiates the payment transaction by mapping the decrypted payment information to an authorization request message, the authorization request message being configured to be processed by a payment processing network.

9. The method of claim 1, wherein after the payment transaction is initiated during the processing of the payment transaction, the authentication response value is verified by the payment processing network.

10. The method of claim 9, wherein the first encryption key includes the public key of a third-party public / private key pair, wherein the third-party public / private key pair includes a third-party public key and a third-party private key, wherein the first encryption key includes the third-party public key, and wherein the second encryption key includes the third-party private key.

11. The method of claim 10, wherein the server computer, the third-party public key, and the third-party private key are associated with a payment processing network.

12. A mobile device comprising: processor; and A computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to implement a method comprising: On the mobile device, a mobile payment application retrieves payment information, including security information such as passwords and user authentication data, from a secure storage device. The mobile payment application uses a first encryption key to encrypt the payment information to form encrypted payment information; The mobile device provides a payment request, including the encrypted payment information, to a server computer, wherein the server computer is programmed to decrypt the encrypted payment information using a second encryption key, receive an authentication response value from the authentication computer in the security information after sending the security information to the authentication computer, and re-encrypt the payment information using a third encryption key, wherein the authentication response value indicates verification of the security information by an account issuer associated with account information in the decrypted payment information, and the verification of the security information includes comparing a password from the received security information with a password generated by the authentication computer, and comparing user authentication data from the received security information with user authentication data stored in an authentication database; and The mobile device receives a payment response from the server computer, which includes re-encrypted payment information, wherein a transaction processor associated with the mobile device decrypts the re-encrypted payment information using a fourth encryption key and initiates a payment transaction using the decrypted payment information.

13. The mobile device of claim 12, wherein the transaction processor is a merchant application, and the mobile device further includes a remote transaction application communicating with the merchant application and the mobile payment application.

14. The mobile device of claim 12, wherein the secure memory further comprises a secure element.

15. The mobile device of claim 14, wherein the payment information includes a credential, and the credential is stored on the secure element.

16. The mobile device of claim 12, wherein the transaction processor is a merchant application.

17. The mobile device of claim 12, wherein the mobile device includes an antenna coupled to the processor.

18. The mobile device of claim 12, further comprising a remote transaction application, wherein the method further comprises: The mobile payment application sends the encrypted payment information to the remote transaction application, which then generates the payment request.

Images