KR102025816B1 - Method and system for secure authentication of user and mobile device without secure elements - Google Patents

Abstract

A method for generating payment credentials in a payment transaction comprises: storing in memory at least a disposable key associated with a transaction account; Receiving, by the receiving device, a personal identification number; Identifying, by the processing apparatus, a first session key; Generating, by the processing device, a second session key based at least on the stored disposable key and the received personal identification number; Generating, by the processing device, a first application cryptogram based on at least the first session key; Generating, by the processing device, a second application cryptogram based on at least the second session key; And transmitting, by a sending device, at least the first application cryptogram and the second application cryptogram for use in a payment transaction.

Description

Method and system for secure authentication of user and mobile device without secure elements}

Cross Reference to Related Application

This application discloses a pre-application US patent temporary application 61 / 979,112, filed April 14, 2014; 61 / 996,665, filed May 14, 2014; 61 / 979,113, filed April 14, 2014; And interim patent application 61 / 910,819, filed especially on December 2, 2013; 61 / 951,842, filed March 12, 2014; 61 / 955,716 filed March 19, 2014; 61 / 979,132, filed April 14, 2014; And 35 U.S.C. No. 61 / 980,784 filed April 17, 2014. Enjoying the benefit of priority under 119 (e), the entire contents of these US patent provisional applications are incorporated herein by reference.

Technical Field of the Invention

The present invention is directed to authenticating users and mobile devices without requiring a secure element in payment transactions. More specifically, the present invention relates to generating secure payment credentials in a mobile device used in a payment transaction without the use of secure elements.

The development of mobile communication technology has created enormous opportunities. One of the opportunities is to provide a user of the mobile computing device with the ability to initiate and pay for a payment transaction using their mobile device. One such approach that enables these operations on mobile devices has been the use of Near Field Communication (NFC) technology to securely transfer payment details from a mobile device to a nearby point of sale (POS) terminal. To accomplish this, mobile phones with secure element hardware, such as secure element (SE) chips, are used to securely store payment credentials. The secure element is something special that can be included within some NFC-enabled devices that are tamper-proof platforms that can securely host applications and their confidential data.

But not all mobile devices have security elements. In addition, even if the mobile device is equipped with such a secure element, some financial institutions may not have access to the secure elements on the mobile devices. As a result, most consumers with mobile devices that possess the hardware needed to conduct contactless remote payment transactions or other types of remote payment transactions may not actually use this feature. Because of this difficulty, there is a need for a technical solution that enables mobile computing devices to initiate and perform payment transactions without the use of secure elements.

Some methods and systems for conducting payment transactions using mobile devices without secure elements, or without using secure elements in mobile devices equipped with secure elements, are disclosed in Mehdi Collinge, filed March 14, 2013. US Patent Application No. 13 / 827,042 entitled "Systems and Methods for Processing Mobile Payments by Provisioning Credentials to Mobile Devices Without Secure Elements," et al., Which is incorporated by reference in its entirety. Incorporated herein by reference. While these methods and systems may be suitable for conducting payment transactions through a mobile device without using a secure element, many consumers, merchants and financial institutions may be interested in such transactions due to the desire for greater security. Be wary of participating.

As a result, not only provide enhanced security for transferring payment credentials from the mobile device to the POS during the financial transaction, but also receive and store payment credentials on a mobile device that lacks a secure element. There is a need for technical solutions that provide even greater security. Improved security in these processes can result in improved peace of mind for all involved entities, which can lead to an increase in the use of mobile devices for contactless payment transactions or remote payment transactions, and this is an existing payment method. This can provide tremendous benefits to the consumer compared to these.

The present invention provides a description of systems and methods for generating payment credentials in a payment transaction.

A method for generating payment credentials in a payment transaction comprises: storing in memory at least a disposable key associated with a transaction account; Receiving, by the receiving device, a personal identification number; Identifying, by the processing apparatus, a first session key; Generating, by the processing device, a second session key based at least on the stored disposable key and the received personal identification number; Generating, by the processing device, a first application cryptogram based on at least the first session key; Generating, by the processing device, a second application cryptogram based on at least the second session key; And transmitting, by a sending device, at least the first application cryptogram and the second application cryptogram for use in a payment transaction.

A method for generating payment credentials in a payment transaction includes: storing in a memory at least a card master key associated with a transaction account; Generating, by the processing apparatus, a first session key based at least on the stored card master key; Generating, by the processing device, a second session key; Generating, by the processing device, a first application cryptogram based on at least the first session key; Generating, by the processing device, a second application cryptogram based on at least the second session key; And transmitting, by a sending device, at least the first application cryptogram and the second application cryptogram for use in a payment transaction.

The system for generating payment credentials in a payment transaction includes: a memory, a receiving device, a processing device and a transmitting device. The memory is configured to at least store a disposable key associated with a trading account. The receiving device is configured to receive a personal identification number. The processing device is configured to: identify a first session key; Generate a second session key based at least on the stored disposable key and the received personal identification number; Generate a first application cryptogram based on at least the first session key; And generate a second application cryptogram based on at least the second session key. The transmitting device is configured to transmit at least the first application cryptogram and the second application cryptogram for use in a payment transaction.

Another system for generating payment credentials in a payment transaction includes a memory, a processing device and a transmission device. The memory is configured to at least store a card master key associated with a trading account. The processing device comprises: generating a first session key based at least on the stored card master key; Generate a second session key; Generate a first application cryptogram based on at least the first session key; And generate a second application cryptogram based on at least the second session key. The transmitting device is configured to transmit at least the first application cryptogram and the second application cryptogram for use in a payment transaction.

The effects of the present invention are individually indicated in the sections corresponding to this specification.

The scope of the present disclosure is best understood when reading the following detailed description of exemplary embodiments in conjunction with the accompanying drawings. The following figures are included.
1 is a block diagram illustrating a high level system architecture for processing payment transactions with enhanced security of provisioning and storage of payment credentials in accordance with example embodiments.
FIG. 2 is a block diagram illustrating the mobile device of FIG. 1 for processing payment transactions and securely receiving and storing payment credentials without a secure element in accordance with example embodiments.
3 is a block diagram illustrating a card database of the mobile device of FIG. 2 for storing payment credentials in accordance with example embodiments.
4 is a block diagram illustrating a memory of the mobile device of FIG. 2 for storing data used for generating enhanced storage keys and generating an application cryptogram, in accordance with example embodiments.
FIG. 5 is a block diagram illustrating the transaction management server of FIG. 1 for processing a payment transaction with a mobile device without a secure element in accordance with example embodiments.
FIG. 6 is a block diagram illustrating an account database of the processing server of FIG. 5 for storing payment credentials and account details, in accordance with example embodiments. FIG.
7 is a flow diagram illustrating a process for transmitting and verifying a dual application cryptogram to process a payment transaction involving a mobile device without a secure element in accordance with example embodiments.
8 is a flow diagram illustrating an alternative process for transmitting and verifying dual application cryptograms for processing a payment transaction involving a mobile device without a secure element in accordance with example embodiments.
9 is a flow diagram illustrating a process for forming, sending, and verifying a remote notification service or other data message provided to a mobile device without a secure element in accordance with example embodiments.
10A and 10B are flow diagrams illustrating a process for forming, sending, and verifying a return message by a mobile device without a secure element, in accordance with example embodiments.
FIG. 11 is a flow diagram illustrating a process for verifying a remote notification service message using the mobile device of FIG. 2, according to example embodiments.
12 is a diagram illustrating the generation of an enhanced storage key using the mobile device of FIG. 2, in accordance with example embodiments.
13 and 14 are flowcharts illustrating example methods for payment credentials generated in a payment transaction, in accordance with example embodiments.
15 is a flowchart illustrating an example method for receiving and processing a remote notification service message in accordance with example embodiments.
16 is a flowchart illustrating an example method of forming an enhanced storage key in accordance with example embodiments.
17 is a block diagram illustrating a computer system architecture in accordance with example embodiments.
Further areas of applicability of the present disclosure will become apparent from the detailed description provided below. It is to be understood that the detailed description of the exemplary embodiments is intended for exemplary purposes only, and therefore, is not necessarily intended to limit the scope of the present disclosure.

Terminology

Payment Network-A system or network used to transfer money through the use of cash-substitutes. Payment networks may use a variety of different protocols and procedures to process remittances for various types of transactions. Transactions that may be conducted via a payment network may include purchasing products or services, credit transactions, debit transactions, fund transactions, and withdrawals. Payment networks may be configured to conduct transactions through cash-substitutes, which may include payment cards, letters of credit, checks, financial accounts, and the like. Examples of networks or systems configured to perform as payment networks include MasterCard®, VISA®, Discover®, American Express®, PayPal®. Including those operated by such means. The use of the term "payment network" herein may mean both a payment network as an entity and a physical payment network, such as devices, hardware and software, including the payment network.

Transaction Account-A finance that can be used to fund a transaction, such as a checking account, savings account, credit account, virtual payment account, etc. account. The trading account may be associated with a consumer, which may be any suitable type of entity associated with a payment account, which may include an individual, family, company, corporation, government agency, and the like. In some examples, the trading account may be virtual, such as those operated by PayPal® or the like.

Payment Card-A card or data associated with a transaction account that can be provided to a merchant for funding a financial transaction through an associated transaction account. Payment cards are credit card, debit card, charge card, stored-value card, prepaid card, fleet card, virtual It may include a virtual payment number, a virtual card number, a controlled payment number, and the like. The payment card may be a physical card that may be provided to a merchant, or may be data representing an associated transaction account (eg, as stored on a communication device such as a smartphone or computer). For example, in some examples, data including a payment account number may be considered a payment card for the processing of a transaction funded by the associated transaction account. In some examples, a check may be considered a payment card if applicable.

Payment Transaction-A transaction between two entities in which money or other financial gains are exchanged from one entity to the other. A payment transaction may be a transfer of funds for purchase of goods or services, for debt repayment, or for any other exchange of financial interest, which will be apparent to a person skilled in the art. In some examples, payment transaction may refer to transactions that receive funds through a payment card and / or payment account, such as a credit card transaction. Such payment transactions may be processed through issuers, payment networks, and acceptors. The process for processing such a payment transaction may include at least one of authorization, batching, clearing, settlement, and funding. Authorization involves the provision of payment history by the consumer to the merchant, the submission of transaction details (including payment details, for example) from the merchant and their payment account used to fund the transaction. Verification of payment history with the issuer. Batching means storing approved transactions in a batch with other approved transactions for distribution to the underwriter. The settlement may include sending a batched transaction from the acquirer to the payment network for processing. Settlement may include withdrawal of the issuer by the payment network for a transaction involving the issuer's beneficiaries. In some examples, the issuer may pay the acquirer via a payment network. In other examples, the issuer may pay the acquirer directly. Funding may include payment from an underwriter to a merchant for a settlement and settlement payment transaction. It will be apparent to those skilled in the art that the order and / or classification of the steps described above are performed as part of a payment transaction processing.

Point of sale (POS)-a user who enters transactional data, payment data and / or other suitable types of data for the purchase of goods and / or services and / or payment for goods and / or services A computing device or computing system configured to receive interaction with (eg, a consumer, employee, etc.). Point of sale management is the physical device (such as a cash register, kiosk, desktop computer, smartphone, tablet computer, etc.) in a physical location (such as a "brick and motar" store) that a customer visits as part of a transaction. Or virtual in an e-commerce environment, such as an online retailer receiving communications from a customer over a network such as the Internet, where point-of-sale management may be virtual, by a user to initiate a transaction. Computing systems that receive data as a result of an actuated computing device or transaction may be considered point of sale management, where appropriate.

System for processing payment transactions using mobile devices without secure elements

1 illustrates a system 100 for processing a payment transaction using a mobile device without requiring the use of a secure element. The process then involves securely provisioning payment credentials to the mobile device, securely storing the payment credentials, and generating multiple application cryptograms for use in verifying and processing the payment transaction. It may include using payment credentials.

The system 100 may include a transaction management server 102. The transaction management server 102, described in more detail below, provides the mobile device 104 with payment credentials using a securely transmitted remote notification message and as part of a payment transaction. May be one or more computing devices specifically programmed to perform the functions described herein to verify the payment credentials generated by 104. Although the transaction management server 102 is shown and discussed herein as performing various functions, the transaction management server 102 is a number of computing devices, servers and / or configured to perform the functions discussed herein. It will be apparent to those skilled in the art that it can be composed of computing networks. The mobile device 104 discussed in greater detail below may be any type of mobile computing device suitable for performing the functions discussed herein. Any such type of mobile computing device may include a mobile phone, a smartphone, a smartwatch, other wearable or embedded computing device, a tablet computer, a laptop computer, and the like. In some embodiments, the mobile device 104 may be without a secure element. In other embodiments, the mobile device 104 may comprise a secure element, but such element may not be used with the methods and systems discussed herein, or provided herein to provide additional security. It may be used with the methods and systems discussed in the following.

The mobile device 104 may communicate with the transaction management server 104 using several communication channels, such as using dual channel communication. Dual channel communication may include communication using two channels in data transmission and reception to ensure greater security in the transmission of data, for example for verification and authentication. The mobile device 104 may include a mobile payment application (MPA) configured to be executed by the mobile device 104 to perform the functions of the mobile device 104 discussed herein. The MPA, described in more detail below, can be installed on the mobile device 104 and activated using an activation code provided by the transaction management server 102 using methods and systems that will be apparent to those skilled in the art. Can be. As such, the mobile device 104 and the transaction management server 102 may securely transmit and receive communications on one or more communication channels using shared data.

The system 100 may also include a publisher 106. The issuer 106 may be a financial institution such as an issuing bank that issues payment cards or payment credentials to the consumer 108 associated with the transaction account. The issuer 106 may provide the transaction management server 102 with payment details associated with the transaction account and / or the payment card. For example, the payment details may include a transaction account number, an account holder name, an expiration date, a security code, and the like. The transaction management server 102 may store the data in an account database. This is discussed in more detail below. The transaction management server 102 may also supply payment credentials to the mobile device 104. As used herein, the term “payment credential” refers to the mobile device 104 and the mobile device 104 when transmitting and verifying payment information used in a payment transaction using the methods and systems discussed herein. And / or any data used by the transaction management server 102, including but not limited to payment history, payment credentials, disposable keys, session keys, application passwords, card master keys, and the like. Do not.

In some embodiments, the payment credential may be supplied to the mobile device 104 via a remote notification service message. As discussed in more detail below, the remote notification service (RNS) message may be a secure message sent to the mobile device 104 and then verified by the mobile device 104. As such, the data contained in the security message may be secure from other devices and users. The MPA of the mobile device 104 may verify the authenticity of the received RNS message, and may decrypt the RNS message to obtain data contained within the RNS message. The mobile device 104 may then perform all necessary functions based on the data (eg, by executing instructions contained within the data) and, if applicable, the transaction management server ( 102 may generate a return message sent back. In some examples, the return message can be verified by the transaction management server 102.

In some examples, verification of RNS messages at the mobile device 104 or verification of a return message at the transaction management server 102 may use at least a message counter and an authentication code. Using both a counter and an authentication code can ensure that only the intended mobile device 104 will be able to verify and decrypt the data contained in the RNS message. In addition, if the rules and / or algorithms used in the generation of the authentication code are included in the MPA, then only the mobile device 104 containing the particular instance of the application program will be able to verify the RNS message. Resulting in increased security. If the RNS message can include payment credentials, it is only available if the payment credentials are only on the appropriate mobile device 104 and only if the MPA used to access the payment credentials is a proper and authenticated application. Can be guaranteed.

Payment credentials supplied to the mobile device 104 may be securely stored in a repository of the mobile device 104 such as a card database. This is explained in more detail below. In some embodiments, the mobile device 104 can be configured to generate an advanced storage key for use in securely storing data such as payment credentials in the database or memory of the mobile device 104. have. Generation of an enhanced storage key, described in more detail below, provides unique device information, unique MPA information, and randomly generated information to identify a secure storage key that can be used to securely store data on the mobile device 104. Can be used. As a result, the payment credential or other sensitive data may be securely stored in the mobile device 104 without the use of a secure element, which may initiate and conduct a payment transaction without the use of the secure element. May cause). This increases availability for publishers 106 and consumers 108 while maintaining a high level of security.

Once the mobile device 104 allows payment credentials for a transaction account to be received, verified, and securely stored in the mobile device 104, the consumer 108 can perform the payment transaction to perform a payment transaction. 104 may be brought to the merchant's point of sale management 110. The consumer 108 may select a product or service for purchase, initiate a payment transaction for the purchase with a merchant, and deliver the payment credentials for use in funding the payment transaction. Mobile device 104 may be used. Delivering the payment credentials to the point of sale management 110 includes conveying two or more application cryptograms. Using two or more application cryptograms is possible using methods and systems discussed herein, rather than available in existing contactless remote transactions, including transactions performed using mobile device 104 having a secure element. Resulting in a higher level of security for processed transactions.

The application cryptograms may be generated by the mobile device 104 using respective session keys and additional data, respectively. This is discussed in more detail below. An application cryptogram generated using data stored on the mobile device 104, such as in a storage associated with the enhanced storage key and associated with the MPA, indicates that the application cryptogram is specific to the mobile device 104 and the MPA. You can ensure that you authenticate your instance. In some examples, one of the ciphers and / or session keys used to generate the ciphers may use information provided by the consumer 108, such as a personal identification number (PIN). The use of a PIN or other consumer authentication information may enable a password to authenticate both the consumer 108 and the mobile device 104. In this case, the passwords generated by the mobile device 104 may include a password to authenticate the mobile device 104, and a password to authenticate both the mobile device 104 and the consumer 108. .

The cryptograms may be received by the point of sale management 110 as part of the performance of the payment transaction (eg, via near field communication). The application cryptograms may include payment information that may be required in any suitable type of payment transaction situation (e.g., contactless transaction, remote transaction, secure remote payment transaction, magnetic stripe transaction and M / Chip EMV transaction). It may carry additional payment information and may be sent to the point of sale 110 using any suitable method that will be apparent to those skilled in the art. The cryptograms may be sent to the acquirer 112, which may be a financial institution (eg, an acquiring bank) associated with the merchant. For example, the acquirer 112 may issue a trade account to the merchant that is used to receive fund payments from the consumer 108 for the payment transaction. The acquirer 112 may submit the cryptographs and additional transaction details to the payment network 114 using methods and systems that will be apparent to those skilled in the art. For example, the transaction details and the application cryptogram may be included in an authentication request submitted to the payment network 114 on a payment rail.

In some embodiments, all of the application cryptograms may be included in a single transaction message. For example, the mobile device 104 and / or the point of sale management 110 include application cryptograms in legacy data fields of a conventional transaction message to transmit application cryptograms using existing payment systems and hardware. can do. In some cases, the transaction management server 102 may be configured to use Track 2 data for verification of the application cryptograms (eg, in magnetic stripe transactions). In this example, if the transaction message includes Track 1 data, the transaction management server 102 may be configured to convert Track 1 data to Track 2 data. This may include converting changed Track 1 or Track 2 data into Track 1 or Track 2 data that has not been changed (eg, original, restored, etc.), respectively. By performing these functions and including the application cryptograms in legacy data fields, the transaction management server 102 does not require the use of a secure element on the mobile device 104 and for legacy payment systems. Without modification, it cannot be configured to process and verify remote payment transactions and contactless payment transactions using mobile device 104 with a high level of security.

The payment network 114 may process payment transactions using methods and systems that will be apparent to those skilled in the art. As part of the processing, the payment network 114 may send the application cryptograms to the issuer 106 for verification. In some embodiments, the verification can be performed by the payment network 114. The issuer 106 or the payment network 114 may communicate with the transaction management server 102. In some embodiments, the application cryptograms may be sent to the transaction management server 102, and the application cryptograms may be verified through verification application cryptogram generation using the transaction management server 102, wherein The verification application cryptogram may be generated using locally stored payment credentials. In other embodiments, the issuer 106 or payment network 114 may generate ciphers for verification of ciphers generated by the mobile device 104 and convert the ciphers into the issuer 106 or An application cryptogram may be requested from the transaction management server 102, which may return to the payment network 114.

Since the transaction management server 102 owns the payment credentials and other data used by the mobile device 104 to generate the application cryptography, the mobile device ( Validating the payment credentials generated by 104 may be performed through a comparison of an application cryptogram generated by the mobile device 104 and an application cryptogram generated by the transaction management server 102. In some embodiments, the transaction management server 102 may be part of the payment network 114 or the issuer 106. If the transaction management server 102 may be part of the payment network 114, the verification is part of the existing processing of the payment transaction (eg, in transaction funds using the transaction account of the consumer 108). May be performed prior to contacting the issuer 106 for approval with the issuer 106.

By using multiple application cryptograms, the security of payment transactions can be increased. In addition, where each password can authenticate individual data (eg, one password authenticates the mobile device 104, and the other (eg, via a consumer's PIN). Certifying both 104 and the consumer 108), it may also provide the issuer 106 with additional data and considerations for use in the decision to approve or reject the transaction. For example, if both ciphers are incorrect (eg, the ciphers generated by the mobile device 104 do not match the ciphers generated by the transaction management server 102), the transaction is rejected. Can be. If one cipher is correct and the other is incorrect, the transaction may be rejected for security reasons, or may be approved based on the issuer 106's decision, for example. For example, the issuer 106 may use the mobile device 104 for a transaction by an authenticated user where other available data is not the consumer 108 if consumer authentication fails but mobile authentication has passed. When you can show that you are doing so, you can approve the transaction.

As a result, the use of both cryptograms may enable beneficial data that may be used for payment network 114 and issuer 106 in the processing of a payment transaction. In addition, the use of two or more ciphers may enable increased security in existing contactless or remote payment methods, thereby reducing the number of fraudulent behaviors for consumers 108, issuers 106, and merchants. Can cause more acceptance. The use of two or more application cryptograms is securely supplied using the RNS messaging methods and systems discussed herein and from securely stored payment credentials through enhanced storage keys generated using the methods and systems discussed herein. When created, the overall security of the system 100 may be much increased compared to existing systems for contactless payment and transaction processing. As a result, the system 100 may provide increased security than that provided in existing contactless payment systems, in various aspects of data transfer, data storage, and data processing, and generally discussed herein. Other types of remote payment transactions and payment transactions that may use the methods and systems may be enabled.

Mobile devices

2 illustrates an embodiment of a mobile device 104 of the system 100. The embodiment of the mobile device 104 shown in FIG. 2 is provided by way of example only, and does not cover all possible configurations of the mobile device 104 suitable for performing the functions as described herein. It will be apparent to those skilled in the art to which the invention pertains. For example, the computer system 1700 shown in FIG. 17 and discussed in more detail below may be a suitable configuration of the mobile device 104.

The mobile device 104 can include a receiving unit 202. The receiving unit 202 may be configured to receive data over one or more networks via one or more network protocols. The receiving unit 202 is, for example, one or more application programs installed on the mobile device 104 and to be executed by the mobile device 104 (eg, a mobile payment application described in more detail below). Program data (MPA)). In addition, the receiving unit 202 may receive a Remote Notification Service (RNS) message, such as messages sent by the transaction management server 102 including RNS messages containing payment credentials. In addition, the receiving unit 202 may receive additional data suitable for performing existing functions (eg, call, mobile communication, etc.) of the mobile device 104. In some examples, the mobile device 104 may include multiple receiving units 202, such as individual receiving units 202, each configured to communicate with one or more separate networks via appropriate protocols. For example, the mobile device 104 may include a first receiving unit 202 for receiving data for NFC transactions and a second receiving unit 202 for receiving communications over a mobile communication network.

In addition, the mobile device 104 may include an input unit 214. The input unit 214 is one or more input devices (eg, keyboard, mouse, click wheel, scroll wheel) connected internally or externally with the mobile device 104 to receive input from the consumer 108. , Touch screen, microphone, camera, receiver, etc.). The input unit 214 can receive an input from the consumer 108, and the input can be processed by the processing unit 204.

The processing unit 204 may be configured to perform the functions of the mobile device 104 discussed herein. The processing unit 204 may execute program code stored in the mobile device for the MPA, for example, and perform a number of functions associated with each application program as well as other functions of the mobile device 104. It can be configured to. The processing unit 204 may receive input from the consumer 108 via the input unit 214, and accordingly perform data within the program, for example by executing an application program, thereby receiving data. Functions can be performed by receiving, transmitting data, and displaying data. This will be apparent to those skilled in the art. For example, the processing unit 204 may be configured to verify RNS messages, generate enhanced enhanced storage keys, and generate application cryptograms, which is described in more detail below.

In addition, the mobile device 104 may include a display unit 210. The display unit 210 is internal or external to the mobile device 104 to display data (eg, data sent by the processing unit 204 to the display unit 210 for display). It may be configured to communicate with one or more display devices that are connected. Display devices may include a liquid crytal display (LCD), a light emitting diode display, a thin film transistor display, a touch screen display, and the like.

In addition, the mobile device 104 may include a transmission unit 206. The transmitting unit 206 may be configured to transmit data over one or more networks via one or more network protocols. The sending unit 206 may send RNS response messages to the transaction management server 102. Further, the sending unit 206 may be configured to send application cryptograms and / or payment credentials for use in a payment transaction (eg, to point of sale management 110). The transmission unit 206 may be further functions of the mobile device 104 (e.g., existing functions of the mobile communication device for cellular communication transmission, etc.) that will be apparent to those skilled in the art. It may be further configured to perform. In some examples, the mobile device 104 may include a number of transmission units 206 that may be individually configured to communicate with one or more separate networks. The plurality of transmission units 206 are the same as the transmission unit 206 configured to transmit payment credentials and payment cryptography via NFC and another transmission unit 206 configured to transmit data via the mobile communication network.

The mobile device 104 may also include a card database 208. The card database 208, described in more detail below, may be a data store on the mobile device 104 configured to store data associated with one or more trading accounts and / or payment cards. The card database 208 may store payment credentials associated with the trading account, such as payment credentials supplied by the transaction management server 102 to the mobile device 104 in a secure RNS message, and an application cryptogram. It can store additional data that can be used for the generation of. This is explained in more detail below. In some examples, the card database 208 may be stored as part of the mobile payment application.

The mobile device 104 may further include a memory 212. The memory 212, discussed in more detail below, may be configured to store data for the mobile device 104 suitable for performing the functions of the mobile device 104 discussed herein. For example, the memory 212 may store data suitable for generating enhanced storage keys for encryption of additional data in the mobile device 104, such as the card database 208. This is explained in more detail below. The memory 212 also receives program code for an application program executed by the processing unit 204 (eg, an operating system, the data via the input unit 214, and receives the display unit 210). Program code for displaying data, rules and / or algorithms for performing the functions discussed herein, etc.). The memory 212 may also store data (e.g., rules and / or algorithms for transmitting and receiving cellular communications over the mobile network) suitable for performing existing functions of the mobile device 104. have. Additional data stored in the memory 212 will be apparent to those skilled in the art.

Mobile device card database

3 illustrates a card database 208 on the mobile device 104 for storing payment credentials and other data associated with a trading account for use in funding a payment transaction performed using the mobile device 108. An embodiment of the is shown.

The card database 208 may include one or more payment profiles 302 shown in FIG. 3 as payment profiles 302a, 302b, 302c. Each payment profile 302 may be associated with a trading account that may be used to fund a payment transaction, and payment credentials 304, one or more disposable keys 306, a first session key 308 ), A second session key 310 and an application transaction counter 312.

The payment credentials 304 are associated with the associated transaction account used for identification and verification by the payment network 114 and / or the issuer 106 when processing a payment transaction using the associated transaction account. May contain data. The payment credentials 304 may include, for example, a transaction account number, security code, expiration date, cardholder name, authenticated user name, tracking data, card layout description data, and digit count. (digit counts), bitmaps, and the like.

Disposable keys 306 may be valid payment tokens for a single payment transaction that may be used by processing unit 204 of the mobile device 104 to generate one or more of the application cryptograms used for the payment transaction. . In some embodiments, the disposable key 306 may include one or more of the other data elements included in the payment profile 302. For example, each disposable key 306 may include a separate application transaction counter 312 that may not be included separately in the payment profile 302. Different configurations of data stored in the payment profile 302 for use in performing the functions disclosed herein will be apparent to those skilled in the art. In some examples, the disposable key 306 may include a key used to generate one or more application cryptograms, or may consist of a key used to generate one or more application cryptograms. In some embodiments, the first session key 308 and the second session key 310 may be included in a disposable key 306 supplied to the mobile device 104, and the disposable key ( 306 can be generated using the data contained within.

The first session key 308 and the second session key 310 may generate application cryptograms that are sent to the point of sale management 110 as part of performing a payment transaction using the mobile device 104. May be additional keys used by the processing unit 204. In some embodiments, the first session key 308 is the processing unit 204 (eg, using program code, rules or algorithms stored in the memory 212 of the mobile device 104). May be used when generating a first application cryptogram. The second session key 310 may be used when generating a second application cryptogram.

In some embodiments, the second session key 310 may be generated by the processing unit 204. In this embodiment, the second session key 310 is used by the consumer 108 (e.g., via the input unit 214) and the disposable key 306 and user authentication data (e.g., via the input unit 214). Generated PIN). In such an embodiment, the second session key 310 may not be stored in the payment profile 302, but instead may be generated, used, and discarded as part of the payment transaction process. Thus, when the second application cryptogram is generated from the second session key 310 generated using the one-time key 306 and the consumer PIN, the mobile device 104 and the consumer 108 It can serve to authenticate everyone.

The personal identification number (PIN) may be used to authenticate the consumer 108 (eg, during registration of the MPA on the mobile device 104, or the issuer 106 and / or the During registration of a trading account with the transaction management server 102). When performing a payment transaction, the consumer 108 or another user of the mobile device 104 may provide a PIN through the input unit 214. In some embodiments, if the supplied PIN is not correct (eg, if the supplied PIN does not match the PIN supplied by the consumer 108 during registration), the processing unit 204 may perform the second session. Generating key 310 may then continue to generate the second application cryptogram. If the supplied PIN is not correct, then the second application cryptogram will not be correct, which means that the second application cryptogram by the transaction management server 102, the issuer 106 and / or the payment network 114 is invalid. Will cause a failed authentication, thereby providing the issuer 106 with the opportunity to reject the transaction in response, or nevertheless approve the transaction.

Mobile device memory

4 illustrates the mobile device 104 for performing payment transactions using the mobile device 104 and for storing other data and application programs that will be used to securely store data on the mobile device 104. One embodiment of a memory 212 is shown. In an exemplary embodiment, the memory 212 may not be a secure element.

The memory 212 may include device information 402. The device information 402 may include one or more data pieces associated with the mobile device 104, and in some examples, the one or more data pieces may be unique to the mobile device 104. For example, the device information 402 may include a media access control address (MAC) address, a reference number, a serial number, an identification number, and the like. Additional information that may be considered device information 402 of mobile device 104 will be apparent to those skilled in the art.

The memory 212 may also include a mobile payment application (MPA) 404. The MPA 404 is configured to perform the functions of the mobile device 104 discussed herein, such as receiving and storing payment credentials, verifying RNS messages, and generating application cryptograms for use in performing a payment transaction. It may be an application program. Additional features of the MPA 404 may include existing features of an electronic wallet or other similar application program that will be apparent to those skilled in the art.

The MPA 404 may include program code 406. The program code 406 is code executed by the processing unit 204 of the mobile device 104, such that the processing unit 204 and other components of the mobile device 104 are discussed herein. It may be code that causes the MPA 404 to perform the functions. For example, the program code 406 may include code suitable for generating application cryptograms, verifying RNS messages, and the like. The program code 406 may also include program code suitable for generating a random value that may be used when generating the enhanced storage key. The random value may be a random number or pseudo-random number that may be generated using methods and systems that will be apparent to those skilled in the art.

In addition, the MPA 404 may include an instance identifier 408. The instance identifier 408 may be used in the generation of the enhanced storage key used to protect data in the mobile device 104 (eg, in the card database 208), specific MPA 404. Can be unique. By having the instance identifier 408 unique to the MPA 404, a number of MPAs 404 can be installed on the mobile device 104, and any MPA 404 can be any other MPA ( Data securely stored by 404 may not be accessible, thereby ensuring that payment profiles 302 for certain trading accounts cannot be accessed by other programs. The instance identifier 408 may be a number, alphanumeric value, hexadecimal value, or any suitable value that may be unique for the MPA 404.

As will be discussed in more detail below, the processing unit 204 of the mobile device 104 may include the device information 402, a random value generated using the program code 406 of the MPA 404, and the It may be configured to generate a diversifier value using the instance identifier 408 stored in the MPA 404. The diversification value may be used by a cryptographic application 410 stored in the memory 212. The cryptographic application 410 may be an application program configured to perform whitebox cryptography and / or other suitable cryptographic functions that will be apparent to those skilled in the art.

The cryptographic application 410 may include program code 412. The program code 412 is configured to enable the processing unit 204 and other components of the mobile device 104 to perform cryptographic functions of the cryptographic application 410 discussed herein. May be executed by the processing unit 204. The functions may include the generation of an enhanced storage key. The enhanced storage key may be generated using an encryption key 414 included in the encryption application 410 and the diversification value generated by the mobile payment application 404. In some embodiments, the diversification key can be decrypted using the encryption key 414 to obtain the enhanced storage key.

In addition, the encryption application 410 is configured to encrypt the storage in the mobile device 104 using the enhanced storage key. In some embodiments, the encryption can be performed using one or more whitebox cryptography techniques. The encrypted store may be the card database 208 and / or any other suitable store in the mobile device 104, such as data stored in the MPA 404. In some embodiments, the encryption application 410 may be included as part of the MPA 404. The enhanced storage key may be stored in the encryption application 410 or the MPA 404, or in some examples, may be re-generated by the MPA 404 and the encryption application 410 when needed. Can be.

In addition, the memory 212 may include any additional data stored in the mobile device 104 suitable for performing the functions discussed herein, as well as any additional functions of the mobile devices. For example, the memory 212 may include program code for an operating system, code, rules or algorithms for receiving and transmitting mobile communications, such as a telephone call.

In some embodiments, the mobile device 104 may also be configured to receive data that has already been encrypted using the enhanced storage key, in which case the encrypted data is stored in the memory 212, the card. May be stored in an encrypted local store within the mobile device 104, such as a database 208 or other suitable store. In such embodiments, the mobile device 104 may be configured to send the generated random value to the transaction management server 102 or another trusted entity, and the transaction management server 102 or other trusted entity. May generate the enhanced storage key using the same methods and systems using the generated random value, and may encrypt the data supplied to the mobile device 104. Accordingly, the mobile device 104 can receive data that has already been encrypted using the enhanced storage key for local storage in the mobile device 104.

Transaction management server

5 illustrates one embodiment of the transaction management server 102 of the system 100. The embodiment of the transaction management server 102 shown in FIG. 5 has been provided by way of example only and does not cover all possible configurations of the transaction management server 102 suitable for performing functions as described herein. It will be apparent to those skilled in the art to which the present invention pertains. For example, the computer system 1700 shown in FIG. 17 and discussed in more detail below may be a suitable configuration of the transaction management server 102.

The transaction management server 102 may include a receiving unit 502. The receiving unit 502 may be configured to receive data over one or more networks via one or more network protocols. The receiving unit 502 may receive data such as a receive or return message, a confirmation message, a transaction notification, etc. from the mobile device 104, and from the payment network 114, the issuer 106 or another suitable entity. Data can be received. The receiving unit 502 may receive a transaction notification or cryptographic request, for example to initiate generating an application cryptogram for use in verifying payment credentials in a payment transaction. The receiving unit 502 can also receive transaction account data for use in generating payment credentials for providing to the mobile device 104, for example from the issuer 106.

In addition, the transaction management server 102 may include a processing unit 504. The processing unit 504 may be configured to perform the functions of the transaction management server 102 discussed herein, which will be apparent to those skilled in the art. The processing unit 504 thus: generates and decrypts RNS messages and data contained therein; Verify return messages from the mobile device (104); Generate payment credentials; Generate application ciphers; It may be configured to verify application cryptograms. This will be discussed in more detail below.

The transaction management server 102 may further include a transmission unit 506. The transmitting unit 506 may be configured to transmit data over one or more networks via one or more network protocols. The sending unit 506 may send RNS messages, payment credentials, application cryptograms, verification notifications, and other data that will be apparent to those skilled in the art. The transmitting unit 506 may be configured to transmit data to the mobile device 104, for example, via a mobile communication network or the Internet, the payment network 114, the issuer 106 and any It may be configured to send data to another suitable entity.

In addition, the transaction management server 102 may include an account database 508. The account database 508, discussed in more detail below, can be configured to store account information for multiple trading accounts. The account information may include data and keys used for generation of application cryptograms used when verifying payment credentials received during a payment transaction performed using the mobile device 104. The account database 508 also provides transaction data for payment transactions performed in conjunction with the mobile device 104, and other data (e.g., data associated with the consumer 108 or other associated transaction accounts). Data associated with authorized users).

In addition, the transaction management server 102 may include a memory 510. The memory 510 may be configured to store additional data for use by the transaction management server 102 when performing the functions disclosed herein. For example, the memory 510 may include rules or algorithms for verifying application cryptograms, rules or algorithms for generating verification notification, algorithms for generating session keys and application cryptograms, encryption of data and Encryption keys for decryption, and RNS messages can be stored. Additional data that may be stored in the memory 510 will be apparent to those skilled in the art.

Account Database on the Transaction Management Server

FIG. 6 illustrates an application of the transaction management server 102 for storing data relating to a transaction account for use in verifying payment credentials and other transaction data provided in the performance of a payment transaction including the mobile device 104. An embodiment of an account database 508 is shown.

The account database 508 may include a number of account profiles 602 as shown in FIG. 6 as account profiles 602a, 602b, 602c. Each account profile 602 includes one or more disposable keys 604, a first session key 606, a second session key 608, an application transaction counter 610, and a first card master key 612. can do. In some embodiments, account profile 602 may further include a second card master key 612.

Each account profile 602 may correspond to a payment profile 302 supplied to the mobile device 104. As such, the disposable keys 604 stored in the account profile 602 may correspond to the disposable keys 306 stored in the corresponding payment profile 302 associated with the same trading account. The data may be similar, in which case, when an application cryptogram is generated by the transaction management server 102 or the mobile device 104, the application cryptograms must match if the data is accurate and undamaged. do.

 In some embodiments, account profile 602 may include a personal identification number (PIN) corresponding to PIN 314 stored in corresponding payment profile 302. In this embodiment, the PIN 314 is provided to the receiving unit 202 transaction management server 102 in a secure message, such as a received message provided by the mobile device 104 discussed in more detail below. In other embodiments, a card master key such as the first card master key 612 may be used in place of the PIN. In such an embodiment, the processing unit 504 of the transaction management server 102 may be configured to generate a second session key 608 based on the second card master key 614, in which case, The second card master key 614 corresponds to the second session key 310 generated by the mobile device 104 using the disposable key 306 and the PIN 314. In some examples, the second session key 608 may also be based on the corresponding disposable key 604. In such embodiments, algorithms for the generation of session keys and / or application cryptograms indicate that the cryptograms generated by the mobile device 104 and the transaction management server 102 match based on the data used there. I can guarantee it.

The first session key 606 may be used by the processing unit 504 of the transaction management server 102 to generate a first application cryptogram, and the second session key 608 may be a second application. Can be used to generate a password. In some embodiments, the application transaction counter 610 may be used to generate one or more of the session keys and / or the application cryptograms. The application transaction counter 610 may be a value corresponding to a payment transaction to be performed and may be a value that is incremented or modified during each transaction. The application transaction counter 610 may correspond to the application transaction counter 312 stored in the corresponding payment profile 302 in the mobile device 104, whereby its use is such that only valid MPA 404 is valid session keys. And / or ensure that the correct application transaction counter 312 can be owned to generate application cryptograms. Additional techniques to further enhance the security of the session key and / or application cryptography may be used with unpredictable numbers and other techniques that will be apparent to those skilled in the art.

Process payment transactions using your mobile device

7 shows a process for the processing of a payment transaction performed using the mobile device 104 without a secure element, and using the generation and verification of two or more application cryptograms.

In step 702, the transaction management server 102 sends the payment credentials 304 and other account data (eg, via the RNS message, for example, discussed in more detail below) to (e.g., , Via the transmission unit 506). In step 704, the receiving unit 202 of the mobile device 104 may receive the payment credentials 304 and other account data. In step 706, the processing unit 204 of the mobile device 104 may store the data in a payment profile 302 in the card database 208. The account data may include the payment credentials 304, one or more disposable keys 308 and any other suitable data (eg, one or more of the session keys 308, 310).

In step 708, the processing unit 204 may generate two application cryptograms for use in conducting a payment transaction. In some embodiments, step 708 directs the mobile device 104 to initiate the transaction via short-range communication by instructing the consumer 108, for example via the input unit 214. By placing it near time management 110, or by any other suitable method. The generation of the application cryptograms may include generating a first application cryptogram using the first session key 308 stored in the payment profile 302. The second application cryptogram may be generated using a second session key 310, which may be generated using a one-time key 306 and a PIN 314. In some examples, the consumer 108 may enter a PIN into the mobile device 104 prior to step 708 or during the initiation of step 708 (eg, via the input unit 214). In some embodiments, one or both of the application cryptograms may be generated using the application transaction counter 312.

Once the application cryptograms are generated, the application cryptograms, along with the payment credentials 304, are issued via the point of sale 110, the acquirer 112, and the payment network 114 via the issuer 106. Can be delivered. In step 710, the payment credentials 304 and application cryptograms may be received by the issuer 106. In step 712, the sending unit 206 of the mobile device 104 may send a transaction notification to the transaction management server 102. In step 714, the receiving unit 502 of the transaction management server 102 may receive the transaction notification. The transaction notification may inform the transaction management server 102 that the mobile device 104 has initiated a payment transaction using the payment profile 302. In some examples, the transaction notification may include identification information.

In step 716, the processing unit 504 of the transaction management server 102 may identify an account profile 602 corresponding to the payment profile 302, and using the data contained therein, two Application ciphers may be generated. The first application cryptogram may be generated using the first session key 606, which may be generated using the first card master key 612. The second application cryptogram may be generated using the second session key 608. In some embodiments, one or two of the application cryptograms and / or the session keys may be further based on disposable keys 604, application transaction counter 610, or any other suitable data.

In step 718, the sending unit 506 of the transaction management server 102 may send the generated application cryptograms to the issuer 106, which may receive the cryptograms in step 718. In step 720, the issuer 106 may verify the application cryptograms provided by the mobile device 104 involving the payment credentials 304. Validation of the application cryptograms may include comparing the cryptograms supplied by the mobile device 104 with the application cryptograms generated and supplied by the transaction management server 102. Once verification is performed, then at step 722, the issuer 106 may process the transaction accordingly. Transaction processing may include, for example, approval of the payment transaction if one or both of the cryptograms are verified, or for example if one or both of the cryptograms are determined to be invalid. May include a refusal of

In step 724, a transaction notification may be sent by the issuer 106 or other entity (eg, the payment network 114, takeover 112, etc.) as part of the processing of the payment transaction. In step 726, the transaction notification may be sent to the transaction management server 102 and may be received by the receiving unit 502. Further, in step 728, the transaction notification may be received by the receiving unit 202 of the mobile device 104. The transaction notification may be an indication of approval or rejection of the payment transaction. Each of the processing unit 204 of the mobile device 104 and the processing unit 504 of the transaction management server 102 may perform one or more functions as a result of the received transaction notification. For example, if the transaction has been approved and processed successfully, the application counters 310, 610 in the respective profiles may be updated accordingly.

8 illustrates an alternative process for processing a payment transaction using the mobile device 104.

In step 802, the payment credentials 304 and other account data may be sent to the mobile device 104 by the sending unit 506 of the transaction management server 102. In step 804, the receiving unit 202 of the mobile device 104 may receive the payment credentials 304 and other account data, and the payment credentials 304 and other account data It may be stored in the payment profile 302 in step 806. In step 808, the processing unit 204 of the mobile device 104 may generate two or more application cryptograms as described above, and the cryptograms, payment credentials 304 and other suitable data. May be sent to the issuer 106 (eg, via the point of sale management 110).

In step 810, the issuer 106 may use the application cryptograms and any other suitable data that may be used by the issuer 106 to verify the transaction data and / or to process the approval or rejection of the transaction. Can be received. In step 812, the issuer 106 may submit a request for verification cryptograms to the transaction management server 102. In some embodiments, the request is suitable for use by the transaction management server 102 when identifying the account profile 602, which will be used to generate the verification cryptograms, or other payment credentials 304 or otherwise. May contain data. In one embodiment, the request may further include two application cryptograms generated by the mobile device 104 for verification.

In step 814, the receiving unit 502 of the transaction management server 102 may receive the cryptographic request. In step 816, the processing unit 504 of the transaction management server 102 may generate the two application cryptograms to be used for verification as described above. Also in embodiments where the cryptographic request includes the two application cryptograms generated by the mobile device 104, step 816 also uses the two newly generated application cryptograms to the processing unit 504. By verifying the two ciphers. In applicable embodiments the verification cryptography or verification result may be sent by the sending unit 506 to the issuer 106. In step 818, the issuer 106 may receive the verification cryptograms and / or the verification result.

In step 820, the issuer 106 may verify the application cryptograms provided by the mobile device 104 using the application cryptograms generated by the transaction management server 102. In embodiments in which the transaction management server 102 provides verification results to the issuer 106, step 820 may include identifying the results of verification of each of the two application cryptograms. In step 822, the issuer 106 may process the payment transaction accordingly based on the result of the verification. In step 824, transaction notifications may be sent to the transaction management server 102 and the mobile device 104, received by the receiving unit 502 in step 826, and the receiving unit 202 in step 828. Is received by.

Remote Notification Service and Data Messaging

9 shows a process for the transmission and verification of remote notification service (RNS) messages and other data messages sent from the transaction management server 102 to the mobile device 104. RNS messages may be sent via a remote notification service, such as using a mobile communication network associated with the mobile device 104. RNS messages may be used to supply payment credentials 304 and other account data (eg, account data used in the processing of payment transactions) to the mobile device 104 as described above, and the mobile It may be used to supply other information that may be used to establish a secure connection between the device 104 and the transaction management server 102.

In step 902, the processing unit 504 of the transaction management server 102 may generate a message. In examples where mutual authentication is established with the mobile device 104, the message may include information suitable for establishing the mutual authentication, such as a session identifier. In other examples, such as when mutual authentication is established between the transaction management server 102 and the mobile device 104 using the process shown in FIG. 9 and discussed herein, the generated message is payment credentials 304. And one or more instructions to be executed by the mobile device 104's MPA 404 (eg, removal of the disposable keys 306 or payment credentials 304, etc.). ), May be notifications (eg, account balance, payment notification, etc.) to be presented to the consumer 108, or may include other suitable data.

In step 904, the processing unit 504 may encrypt the generated message. The message can be encrypted using the private key of the private / public key pair, in which case the mobile device 104 can own the corresponding public key. In some examples, the message may be encrypted using an encryption key (eg, encryption key 414) associated with the mobile device 104 or the MPA 404. In step 906, the processing unit 504 may generate a message authentication code. The message authentication code may be generated using the encrypted message, and may be a key generated using one or more specially configured rules and / or algorithms. For example, the message authentication code can be generated using one or more encryption and obfuscation methods such as padding. In some embodiments, the message authentication code can be generated using the encryption key.

In step 908, the sending unit 506 of the transaction management server 102 may send the combined data message to the mobile device 104. In embodiments where the mutual authentication may be performed, the combined data message may be a remote notification service message sent to the mobile device 104 via the remote notification service. The combined data message may be received by the receiving unit 202 of the mobile device 104 at step 910 and may include the message authentication code and the encrypted message. In some examples, the combined data message may include an additional identifier, such as an additional identifier generated using methods known to the MPA 404 for validation of the combined data message. In some examples, such as when mutual authentication has already been performed, the combined data message may also include a message counter.

In step 912, the processing unit 204 may generate a reference authentication code. The reference authentication code may be generated using the received encrypted message, and may be generated using the same rules and algorithms as the transaction management server 102 used to generate the message authentication code, As such, if the message authentication code is generated by a trusted source (eg, the transaction management server 102), the generated reference authentication code will correspond to the message authentication code. In embodiments in which the message authentication code may be generated using the encryption key, the processing unit 204 may use the encryption key 414 or other suitable encryption key stored in the memory 212 to authenticate the reference. You can generate code.

In step 914, the processing unit 204 may verify the message authentication code by comparing the message authentication code included in the received combined data message with the generated reference authentication code. If both the message counter and the message authentication code are verified, the combined data message can be determined to be reliable (eg, genuine) as coming from the transaction management server 102. In examples where the combined data message may include a message identifier, the processing unit 204 may also generate a message identifier by using a process known by the MPA 404 for generation and comparison of the message identifier. The message identifier may be verified. In embodiments in which the combined data message may include a message counter, the processing unit 204 is within the mobile device 104 (eg, within the MPA 404 or within the payment profile 502). The stored reference counter can verify the message counter included in the received combined data message.

In step 916, the processing unit 204 may decrypt the encrypted message included in the received combined data message. The encrypted message can be decrypted using the key. For example, the encrypted message may be encrypted using a key stored in the memory 212 (eg, in the encryption application 410 or MPA 404) or (eg, using an enhanced storage key). ) Can be decrypted using a key stored in a locally encrypted database, or other suitable decryption method. In step 918, the processing unit 204 may perform one or more appropriate operations based on the data decrypted from the encrypted message. In the example shown in FIG. 9, the mobile device 104 uses the session identifier included in the encrypted message and decrypted by the processing unit 204, for example. You can perform mutual authentication with. In step 920, the transaction management server 102 may receive the session identifier and perform any additional operations required for mutual authentication with the mobile device 104. In examples where mutual authentication has already been performed, the message is suitable for performing the functions disclosed herein, such as payment credentials 404, disposable keys 406, program instructions for the MPA 404, and the like. May contain other information.

In some embodiments, the mobile device 104 may be configured to generate a return message (eg, via the MPA 404) and submit the return message to the transaction management server 102. In some examples, the return message may include data generated in response to the actions performed as indicated in the decrypted message as described above. For example, the return message may indicate valid receipt and storage of payment credentials 304 or disposable keys 306. In other examples, the return message can be a notification of receipt and verification of the combined data message. In examples where mutual authentication was first performed, the return message may include the session identifier used to perform the mutual authentication.

10A and 10B illustrate a process for generating and sending a return message by the mobile device 104 and verifying the return message by the transaction management server 102.

In step 1002, the processing unit 204 of the mobile device 104 may generate a received message. The received message may be generated based on program code 406 stored in the MPA 404, and further based on operations performed as indicated in the decrypted combined data message received from the transaction management server 102. can do. For example, the received message may include a notification of successful receipt and storage of payment credentials 304. In step 1004, the processing unit 204 may increment the reception counter. The reception counter may be a counter indicating the number of received messages transmitted to the transaction management server 102. The reception counter may be stored in the memory 212 (eg, in the MPA 404, or in a database encrypted using the enhanced storage key). It will be apparent to those skilled in the art that step 1004 may be an optional step and may be used only in cases where a counter is used for the validation of the data message.

In step 1006, the processing unit 204 may encrypt the received message. The received message may be encrypted using the encryption key 414 stored in the encryption application 410, otherwise it may be stored in the MPA 404 or a locally encrypted database. The encryption key used to encrypt the received message may be a private key that is part of a key pair, in which case the transaction management server 102 may possess a corresponding public key. In step 1008, the processing unit 204 may generate a reception authentication code based on the encrypted reception message. In some embodiments, the received authentication code may be generated using the same rules, algorithms and / or processes as used to generate the reference authentication code shown in step 912 of FIG. 9 as described above.

In step 1010, the sending unit 206 of the mobile device 104 may send a receipt notification message to the transaction management server 102. The reception notification message may be received by the reception unit 502 of the transaction management server 102 and may include at least the reception authentication code, the encrypted reception message and the reception counter. In some embodiments, the receipt notification message can be sent to the transaction management server 102 using a mobile communication network, such as a cellular network associated with the mobile device 104.

In step 1014, the processing unit 504 of the transaction management server 102 may increment a confirmation counter. The confirmation counter may indicate the number of messages received from the mobile device 104 used for verification of messages received from the mobile device 104. The confirmation counter may be stored in memory 510 or other suitable data store of the transaction management server 102. For example, in some embodiments, the confirmation counter can be stored in an account profile 602 associated with the mobile device 104. In one example, each account profile 602 sends a message sent from the transaction management server 102 and the mobile device 104 to the transaction management server 102 and the mobile device 104 associated with the corresponding transaction account. May include a confirmation counter (eg, and / or message counter) to be used for the purpose. It will be apparent to those skilled in the art that step 1014 can be an optional step and that a counter cannot be performed in examples where the counter cannot be used for verification of return messages.

In step 1016, the processing unit 504 may generate a confirmation authentication code. The confirmation authentication code may be generated based on an encrypted receipt message included in the receipt notification message, and may be generated using the same rules, algorithms, and / or processes used to generate the message authentication code. have. In step 1018, the processing unit 504 may verify the reception counter by comparing the reception counter included in the reception notification message with the confirmation counter. In step 1020, the processing unit 504 may verify the received authentication code by comparing the received authentication code with the message authentication code, thereby ensuring that the message is from an authorized mobile device 104. do.

If the counter and the authentication code have been verified (eg, if appropriate), then at step 1022, the processing unit 504 may decrypt the encrypted message included in the received receipt notification message. . The encrypted message can be decrypted using a stored encryption key or other suitable decryption method. The encrypted message can be decrypted to obtain the received message generated by the mobile device 104. In step 1024, the processing unit 504 may perform any suitable operations as needed based on the data included in the received message. For example, if the received message includes an indication of successful receipt and storage of disposable keys 306, the processing unit 204 may activate the corresponding disposable keys 604 in the corresponding account profile 602. Can be.

Data message verification

11 shows a process 1100 for verification of data messages received by the mobile device 104 from the transaction management server 102.

In step 1102, the processing unit 204 of the mobile device 104 is configured to authenticate encryption keys, local keys (e.g., locally encrypted storage encrypted using the memory 212 or enhanced storage key). Generate keys, and rules and / or algorithms for their use and application. In step 1104, the receiving unit 202 of the mobile device 104 may receive a data message from the transaction management server 102. In some embodiments, the data message may be received from the transaction management server 102 after mutual authentication between two devices, for example using the process shown in FIG. 9 and described above. The data message may include at least a message counter, a message authentication code and an encrypted message.

In step 1106, the processing unit 204 may increment the reference counter. The reference counter may be stored in the memory 212 or other local store, and may be used to indicate the number of messages received from the transaction management server 102. In some examples, the reference counter may be incremented using an algorithm, whereby the reference counter may not be incremented using consecutive numbers, but the mobile counter (eg, via the MPA 404) It may be incremented using algorithms known to the device 104 and the transaction management server 102.

In step 1108, the processing unit 204 may verify the message counter included in the received data message. Validation of the message counter may include a comparison of the value of the reference counter and the message counter after being incremented. The failed verification may indicate that the source of the data message is not the transaction management server 102 or is not reliable. If the verification fails, at step 1110, the processing unit 204 may perform one or more appropriate operations associated with the receipt and / or verification of the failed data message. For example, the processing unit 204 may discard the data message, inform the transaction management server 102, lock the associated payment profile 302, or perform other actions that will be apparent to those skilled in the art. Can be done.

If the verification of the message counter passes, then the process 1110 may proceed to step 1112, in which case the encrypted message may be padded. Padding of the encrypted message may include adding values to the encrypted message or data associated with it. Padding can be used to increase the security of the message verification process. Because padding has to be performed by the mobile device 104 and the transaction management server 102 known to each other, which need to be replicated by unauthorized entities in order to successfully send or receive data messages without authentication. It may be another function. It will be apparent to one skilled in the art that step 1112 may be an optional step. In some embodiments, step 1112 can be applied to some examples of the process 1110. For example, the encrypted message may be padded at certain increments of the reference counter.

In step 1114, the processing unit 204 may generate a reference authentication code. The reference authentication code may be generated based on the encrypted message (eg, padded, if applicable) using one or more rules or algorithms such as those stored in step 1102. In some embodiments, the reference authentication code can be a key or a value generated by the application of a key to the encrypted message. In step 1116, the processing unit 204 may verify the message authentication code received in the RNS message. Verification of the message authentication code is another identification method if the received data message originated from an authorized source (eg, the transaction management server 102), the comparison of the code with the generated reference authentication code. It may include.

If the verification of the message authentication code fails, the process 1100 may proceed to step 1110, in which case the failure process is performed. If the verification of the message authentication code passes, then, in step 1118, the encrypted message included in the received data message can be decrypted by the processing unit 204. The message may be decrypted using one or more encryption / decryption keys, rules and / or algorithms, such as those stored in the mobile device 104 in step 1102. For example, the encryption key 414 stored in the encryption application 410 of the memory 212 can be used to decrypt the encrypted message. In step 1120, the processing unit 204 may perform one or more actions as appropriate based on the contents of the decrypted message. For example, if the decrypted message includes disposable keys 306, the disposable keys 306 may be stored in an appropriate payment profile 302 of the card database 208, thereby Card database 208 may be encrypted using the enhanced storage key.

Enhanced storage key

12 illustrates the mobile device 104 for secure storage of data such as payment profiles 302 and other data that can be stored and accessed securely on the mobile device 104 without the use of a secure element. 104 illustrates the generation and use of the enhanced storage key.

The device information 402 stored in the memory 212 of the mobile device 104 may include three or more pieces of device information 1202, shown as device information 1202a, 1202b, 1202c in FIG. 12. Each piece of device information 1202 may be associated with the mobile device 104. In some examples, each piece of device information 1202 may be unique to the mobile device 104. In other examples, one or more of the device information pieces 1202 may not be unique to the mobile device 104 (eg, model number), but the three device information pieces 1202 may be When taken, it may be unique to the mobile device 104 (eg, unique coupling). The pieces of device information 1202 may be data that will not change for the life of the mobile device 104.

The processing unit 204 of the mobile device 104 may generate a mobile device fingerprint 1204 based on the three pieces of device information 1202a, 1202b, 1202c. The mobile device fingerprint 1204 may be a value unique to the mobile device 104, and one or more rules stored in the memory 212, such as included in the program code 406 of the MPA 404. Or algorithms. For example, the mobile device fingerprint 1204 may be a numerical value, a hexadecimal value, a string, or the like.

In addition, the processing unit 204 may be configured to generate the diversification value 1208 using the mobile device fingerprint 1204. The diversification value may be generated by combining the mobile device fingerprint 1204 with the instance identifier 408 of the MPA 404 as well as the random value 1206. The random value 1206 may be random or random or pseudo-random number generated by the processing unit 204. In some examples, the random value 1206 may be generated in accordance with one or more rules or algorithms stored in the memory 212. In addition, the combination of the mobile device fingerprint 1204, the instance identifier 408, and the random value 1206 is performed using one or more rules or algorithms such as stored within the program code 406 of the MPA 404. Can be. Use of the instance identifier 408 to generate the diversification value may result in the ability to securely store data associated with an instance of the MPA 404, whereby multiple installations of the MPA 404 may result in the MPA. Data stored by other instances of 404 becomes inaccessible.

The processing unit 204 may then generate an enhanced storage key 1210 through application of the encryption key 414 stored in the encryption application 410 to the diversification value 1208. In some examples, the enhanced storage key 1210 can be generated by decryption of the diversification key 1208 using the encryption key 414. In other examples, the enhanced storage key 1210 may be a value resulting from encryption of the diversification value 1208 using the encryption key 414. In some embodiments, the enhanced storage key 1210 may be generated as a result of performing whitebox cryptography using the encryption key 414 and the diversification value 1208.

Once the enhanced storage key 1210 is generated, the processing unit 204 can use the enhanced storage key 1210 to encrypt the local database 1210. The local database 1210 may include, for example, the card database 208, one or more payment profiles 302, a portion of the memory 212, or other suitable data source. In some examples, the local database 1210 may be part of another database in the mobile device 104, such as the card database 208. For example, the card database 208 may include a number of local databases 1212. The plurality of local databases 1212 is the same as a separate local database 1212 for each instance of the MPA 404 for storing payment profiles 302 associated with it. In so doing, the resulting encrypted local database 1214 may be any other internal or external to the mobile device 104, except for a particular instance of the MPA 404 that includes the instance identifier 408. Data stored inaccessible by the application program can be safely stored. Accordingly, the encrypted local database 1214 may be ideal for storing payment credentials 304, disposable keys 306, and other account data, and secure sensitive account information without the use of secure elements. You can enable storage.

In some embodiments, the storage key can also be used by the transaction management server 102 to provide encrypted data to the mobile device 104 for storage in the encrypted local database 1214. For example, the sending unit 206 of the mobile device 104 may send the generated random value 1206 to the transaction management server 102. In some examples, the instance identifier 408 may also be sent to the transaction management server 102, or in advance by the transaction management server 102 (eg, during registration of the MPA 404). Can be owned. The transaction management server 102 then generates the enhanced storage key 1210 on its own and uses the enhanced storage key 1210 to send data (e.g., to the mobile device 104). Payment credentials 304, disposable keys 306, etc.) and then store the encrypted data in the mobile device 104. Thereafter, the mobile device 104 can store data that has already been encrypted in the encrypted local database 1214.

First Example Method for Generating Payment Credentials in a Payment Transaction

FIG. 13 shows a method 1300 for generating payment credentials in a payment transaction, which uses two application cryptograms for secure use of payment credentials in the mobile device 104 without a secure element. It involves doing.

At step 1302, at least the disposable key (eg, disposable key 306) may be stored in a memory (eg, payment profile 302) associated with the trading account. In some embodiments, the memory 302 may be a non-secure element memory in a mobile communication device (eg, the mobile device 104). In step 1304, a personal identification number (PIN) may be received by a receiving device (eg, the receiving unit 202 and / or the input unit 214).

In step 1306, a first session key (eg, first session key 308) may be identified by a processing device (eg, the processing unit 204). In step 1308, a second session key (eg, second session key 310) may be generated by the processing device 204 based at least on the stored disposable key 306 and the received PIN. have.

In step 1310, a first application cryptogram may be generated by the processing device 204 based at least on the first session key 308. In step 1312, a second application cryptogram may be generated by the processing device 204 based at least on the second session key 310.

At step 1314, at least the first application cryptogram and the second application cryptogram may be transmitted by a transmitting device (eg, the transmitting unit 206) for use in a payment transaction. In some embodiments, the first application cryptogram and the second application cryptogram may be transmitted to a point of sale device (eg, point of sale management 110). In one embodiment, the method 1300 may further comprise storing, in the memory 302, a card master key associated with the transaction account, in which case the first session key 308 is identified. The method includes generating, by the processing device 204, the first session key 308 based at least on the stored card master key.

In some embodiments, the method 1300 may also include storing an application transaction counter (eg, an application transaction counter at 312) in the memory 302, in which case the Identifying the first session key 308 includes generating, by the processing device 204, the first session key 308 based at least on the stored application transaction counter 312. In one embodiment, the method 1300 further includes verifying, by the processing device 204, the received PIN before generating the second session key 310. In a further embodiment, the processing device 204 may be configured to generate an invalid second session key 310 if the verification of the received PIN fails.

Second Example Method for Generating Payment Credentials in a Payment Transaction

14 illustrates a method 1400 for generating payment credentials in a payment transaction, wherein the method 1400 verifies two application cryptograms of payment credentials generated by the mobile device 104 without using a secure element. It involves using.

At step 1402, at least a card master key (eg, first card master key 612) may be stored in a memory (eg, account profile 602) associated with a trading account. In step 1404, a first session key (eg, first session key 606) is generated by a processing device (eg, processing device 504) based at least on the stored card master key 612. Can be generated. In step 1406, a second session key (eg, a second session key at 608) may be generated by the processing device 504.

In step 1408, a first application cryptogram may be generated by the processing device 504 based at least on the first session key 606. In step 1410, a second application cryptogram may be generated by the processing device 504 based at least on the second session key 608. In step 1412, at least the first application cryptogram and the second application cryptogram may be transmitted by a transmitting device (eg, transmitting device 506) for use in a payment transaction.

In one embodiment, the method 1400 may further comprise storing, in the memory 602, a transaction account sequence number associated with the transaction account, wherein the first session key is stored in the stored account. It is further based on the transaction account sequence number. In some embodiments, the method 1400 also includes storing, in the memory 602, a second card master key (eg, a second card master key of 614) associated with the transaction account. And, in this case, the second session key 608 is based at least on the stored second card master key 614.

In one embodiment, the method 1400 comprises: receiving, by a receiving device (eg, receiving unit at 502), a first corresponding application cryptogram and a second corresponding application cryptogram; By the processing device, (i) verifying the received first corresponding application cryptogram based on the generated first application cryptogram, and (ii) the received second application cryptogram based on the generated second application cryptogram. Verifying the corresponding application cryptogram; And transmitting, by the transmitting device 506, the result of the verification for use in the payment transaction. In a further embodiment, the first corresponding application cryptogram and the second corresponding application cryptogram may be received from a point of sale device (eg, point of sale management 110). In yet further embodiments, the results of the verification may be sent to a financial institution (eg, the issuer 106) associated with the transaction account.

Example Method for Processing Data Messages

FIG. 15 illustrates a method 1500 for processing a data message, such as a remote notification message received via a remote notification service, which method 1500 uses a data message by the mobile device 104 without using a secure element. Receiving and verifying.

At step 1502, at least an encryption key may be stored in a memory (eg, the memory 212). In some embodiments, the memory 212 may be a non-secure element memory in a mobile communication device (eg, mobile device at 104). In step 1504, the data message may be received by a receiving device (eg, receiving unit at reference numeral 202), in which case the data message may include at least an encrypted message and a message authentication code, wherein A message authentication code is generated using at least part of the encrypted message. In some embodiments, the data message can be a remote notification service message received via a remote notification service.

In step 1506, a reference authentication code may be generated by a processing device (eg, processing unit 204) using at least some of the encrypted messages included in the received data message. In one embodiment, the memory 212 may further include one or more authentication code generation rules, and wherein the reference authentication code is stored in one or more of the encrypted message included in the received data message. It may be generated based on the application of the authentication code generation rules. In step 1508, the received data message may be verified by the processing device 204 based on a check of the message authentication code included in the received data message against the generated reference authentication code. have. In some embodiments, the memory can further include a reference counter, the received data message can further include a message counter, and the received data message is configured to receive the received data with respect to the stored reference counter. It may be further verified by the processing device 204 based on the confirmation of the message counter included in the message.

In step 1510, the encrypted message included in the data message may be decrypted by the processing device 204 using the stored encryption key to obtain a decrypted message. In one embodiment, the decrypted message may include at least one of the following for use in a payment transaction: a digital card profile (e.g., payment credentials of reference 304) and a disposable key (e.g., For example, the disposable key of reference numeral 306). In some embodiments, the method 1500 may also include checking, by the processing device 204, the data format of the decrypted message based on one or more data formatting rules. .

In one embodiment, the method 1500 may further include transmitting, by the transmitting device (eg, the transmitting device at 206), a receipt notification in response to the received data message. In a further embodiment, the method 1500 comprises: performing, by the processing device 204, one or more operations based on the decrypted message; Generating, by the processing device (204), a return message as a result of the one or more operations performed or based on the one or more operations performed; Encrypting, by the processing device (204), the generated return message using the stored encryption key to obtain an encrypted return message; And generating, by the processing device 204, a return authentication code using at least a portion of the encrypted return message, wherein the received receipt notification is sent to the encrypted return message and It includes the return authentication code. In a further embodiment, the memory 212 may further include a return counter, and the transmitted receipt notification may further include the return counter.

In some embodiments, the method 1500 further includes padding, by the processing device 204, the encrypted message included in the received data message using a padding key. In this case, the portion of the encrypted message used to generate the reference authentication code is the padded encrypted message. In a further embodiment, the padding key may be the encryption key. In another further embodiment, the memory 212 may further include an authentication code padding algorithm, and padding the encrypted message using the padding key includes: the padding key for the authentication code padding algorithm. Padding the encrypted message based on the application of.

Example Method for Forming an Enhanced Storage Key

FIG. 16 illustrates a method 600 for forming an enhanced storage key for securely encrypting and storing local data in mobile device 104 without a secure element.

In step 1602, device information (eg, device information at 402) associated with at least a mobile communication device (eg, mobile device at 104), a first application program (eg, the mobile payment application Program code associated with a second application program (eg, cryptographic application of reference number 410), (eg, reference code 412). Program code) may be stored in a memory (eg, memory 212) of the mobile communication device 104, the program code 406 associated with the first application program 404 being at least an instance identifier ( For example, an instance identifier 408, wherein program code 412 associated with the second application program 410 is at least a first key. (Eg, encryption key 414).

In some embodiments, the device information 402 can include one or more unique identifiers associated with the mobile communication device 104. In one embodiment, the instance identifier 408 may be unique to the instance of the first application program 404. In some embodiments, the second application program 410 may be configured to perform whitebox cryptography using the first key. In one embodiment, the first key may be a dynamic key. In some embodiments, program code 412 associated with the second application program 410 may be included in program code 406 associated with the first application program 404. In further embodiments, the second application program 410 may be an executable function of the first application program 404.

In step 1604, a device fingerprint associated with the mobile communication device 104 (eg, a mobile device fingerprint at 1204) causes execution of the program code 406 associated with the first application program 404. Can be generated by a processing device (eg, processing unit 204) based on the stored device information 402. In step 1606, a random value (eg, a random value of 1206) may be generated by the processing device 204 through execution of program code 406 associated with the first application program 404. . In some embodiments, the random value 1206 may be random or pseudo-random.

In step 1608, a diversification value (eg, a diversification value of reference numeral 1208) is determined by the program associated with the generated device fingerprint 1204, the generated random value 1206, and the first application program 404. It may be formed by the processing device 204 based at least on the instance identifier 408 included in code 406. In step 1610, the formed diversification value 1208 is executed by the program code 412 associated with the second application program 410 to obtain a storage key (eg, an enhanced storage key at 1210). Can be decrypted by the processing device 204 using the first key stored in the program code 412 associated with the second application program 410.

In some embodiments, the method 1600 includes: storing protected data in a local database (eg, a local database of 1212) of the mobile communication device 104; And encrypting, by the processing device 204, the protected data stored in the local database 1212 using the storage key 1210. In one embodiment, the method 1600 also includes: storing program data associated with the first application program 404 in the memory 212; And storing the generated random value 1206 in program data associated with the first application program 404.

In one embodiment, the method 1600 further comprises: transmitting, by a transmitting device (eg, a transmitting unit of reference numeral 206), at least the random value 1206; Receiving, by a receiving device (eg, receiving unit at 202) one or more encrypted parameters, each of the one or more encrypted parameters being encrypted using the storage key 1210, step; And storing the received one or more encrypted parameters in a local database 1212 of the mobile communication device 104. In a further embodiment, the storage key 1210 may be sent to a third party (eg, the transaction management server 102, wherein the one or more encrypted parameters may be received from the third party 102). In some further embodiments, the instance identifier 408 may also be transmitted by the transmitting device 206.

Computer system architecture

17 illustrates a computer system 1700 in which embodiments or portions of embodiments of the present invention may be implemented as computer-readable code. For example, the transaction management server 102 and the mobile device 104 of FIG. 1 may use hardware, software, firmware, non-transitory computer readable media having stored instructions, or a combination thereof to provide a computer system ( 1700 and may be implemented in one or more computer systems or other processing systems. Hardware, software, or any combination thereof includes modules and components used to implement the methods of FIGS. 7, 8, 9A, 9B, 10A, 10B, 11, and 13-16. can do.

If programmable logic is used, such logic can be executed on a commercial processing platform or special purpose device. Those skilled in the art will appreciate that embodiments of the disclosed subject matter may be virtually embedded in any device, as well as multi-core multiprocessor systems, multicomputers, mainframe computers, distributed or clustered computers. Or one of various computer system configurations, including small computers. For example, at least one processor device and memory may be used to implement the embodiments described above.

The processor unit or apparatus discussed herein may be a single processor, multiple processors or combinations thereof. Processor devices may have one or more processor "cores". The terms "computer program medium", "non-transitory computer readable medium" and "computer executable medium" as discussed herein generally refer to removable storage unit 1718, removable storage unit 1722, and hard disk drive. Used to refer to tangible media, such as a hard disk installed at 1712.

Various embodiments of the present disclosure are described with respect to such example computer system 1700. After reading this description, it will be apparent to those skilled in the art how to implement the invention using other computer systems and / or computer architectures. Although the operations may be described in sequential processes, some of the operations may be local or remote in nature, in parallel, concurrently, and / or in a distributed environment, and for access by single processor machines or multi-processor machines. It can be performed using the program code stored as. In addition, in some embodiments, the order of the operations may be re-configured without departing from the spirit of the disclosed invention.

Processor device 1704 may be a special purpose or general purpose processor device. The processor device 1704 may be coupled to a communication infrastructure 1706 such as a bus, message queue, network, multi-core message-delivery scheme, and the like. The network may be any network suitable for performing the functions as disclosed herein, and may be a local area network (LAN), wide area network (WAN), wireless network (eg, WiFi), mobile communication network, satellite Network, internet, optical fiber, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to those skilled in the art. The computer system 1700 may also include a main memory 1708 (eg, random access memory, read-only memory, etc.), and may also include auxiliary storage 1710. The auxiliary storage device 1710 may include a hard disk drive 1712 and a removable storage drive 1714 such as a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, and the like.

The removable storage drive 1714 can read from and write to the removable storage unit 1718 in a well-known manner. The removable storage unit 1718 may include a removable storage medium that can be read by and written to by the removable storage drive 1714. For example, if the removable storage drive 1714 is a floppy disk drive or a universal serial bus (USB) port, the removable storage unit 1718 may be a floppy disk or a portable flash drive, respectively. In one embodiment, the removable storage unit 1718 may be a non-transitory computer readable recording medium.

In some embodiments, the secondary storage 1710 is an alternative means for allowing computer programs or other instructions to be loaded into the computer system 1700 (eg, the removable storage unit 1722). And interface 1720). Examples of such means include program cartridges and cartridge interfaces (eg, as found in video game systems), removable memory chips (eg, EEPROM, PROM, etc.) and associated sockets, as will be apparent to those skilled in the art, and Other removable storage units 1722 and interfaces 1720 may be included.

Data stored in the computer system 1700 (eg, in main memory 1708 and / or auxiliary storage 1710) may be stored in optical memory (eg, compact disks, digital multifunction disks, Blu-ray disks). Etc.), or any type of suitable computer readable medium, such as magnetic tape storage (e.g., hard disk drive). The data may consist of any type of suitable database configuration, such as a relational database, structured query (SQL) database, distributed database, object database, and the like. Appropriate configurations and storage types will be apparent to those skilled in the art.

The computer system 1700 can also include a communication interface 1724. The communication interface 1724 may be configured to allow software and data to be transferred between the computer system 1700 and external devices. Exemplary communication interfaces 1724 may include a modem, a network interface (eg, an Ethernet card), a communication port, a PCMCIA slot and a card, and the like. The software and data delivered through the communication interface 1724 may be in the form of signals that may be electronic signals, electromagnetic signals, optical signals, or other signals that will be apparent to those skilled in the art. The signals can travel through a communication path 1726 that can be configured to carry the signals and can be implemented using wires, cables, optical fibers, telephone lines, cellular links, radio frequency links, and the like.

The computer system 1700 may further include a display interface 1702. The display interface 1702 can be configured to allow data to be transferred between the computer system 1700 and an external display 1730. Example display interfaces 1702 may include a high-definition multimedia interface (HDMI), a digital visual interface (DVI), a video graphics array (VGA), or the like. The display 1730 is a cathode ray tube (CRT) display, a liquid crystal display (LCD), a light emitting diode (LED) display, for displaying data transmitted through the display interface 1702 of the computer system 1700, It may be any suitable type of display, including capacitive touch displays, thin-film transistor (TFT) displays, and the like.

Computer program media and computer executable media may refer to memories, such as the main memory 1708 and the auxiliary storage 1710, which may be memory semiconductors (eg, DRAM, etc.). Such computer program products may be means for providing software to the computer system 1700. Computer programs (eg, computer control logic) may be stored in the main memory 1708 and / or the auxiliary memory 1710. Computer programs may also be received via the communication interface 1724. Such computer programs, when executed, may enable the computer system 1700 to implement the methods discussed herein. In particular, the computer programs, when executed, are executed by FIGS. 7, 8, 9A, 9B, 10A, 10B, 11 and 13-16 when the processor device 1704 is discussed herein. It may be possible to implement the described methods. Accordingly, such computer programs may represent controllers of the computer system 1700. When the present invention is implemented using software, the software may be stored in a computer program product, and the removable storage drive 1714, the interface 172 and the hard disk drive 1712, or the communication interface 1724 may be stored. May be loaded into the computer system 1700.

Techniques consistent with this disclosure provide, among other features, systems and methods for processing payment transactions using a mobile device without using a secure element, the systems and methods for sending and receiving remote notification service messages. Verification, and storing data securely using enhanced storage keys. While various example embodiments of the disclosed systems and methods have been described above, it should be understood that they have been presented for purposes of illustration only and are not intended to be limiting. They are not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings, or they may be obtained from practicing the invention without departing from the breadth or scope of the invention.

Claims (14)

A method for generating payment credentials in a payment transaction,
The method is:
Generating, by the processing device, a second session key based on at least one stored key and personal identification number associated with the transaction account;
Generating, by the processing device, a first application cryptogram based on at least a first session key;
Generating, by the processing device, a second application cryptogram based on at least the second session key; And
Sending, by a sending device, at least the first application cryptogram and the second application cryptogram for use in a payment transaction. The method according to claim 1,
The method is:
Prior to generating the second session key, storing in the memory a card master key associated with the transaction account; And
Identifying, by the processing device, the first session key,
Identifying the first session key includes:
Generating, by the processing device, the first session key based at least on the stored card master key. The method according to claim 1,
The method is:
Prior to generating the second session key, storing an application transaction counter in a memory; And
Identifying, by the processing device, the first session key,
Identifying the first session key includes:
Generating, by the processing device, the first session key based at least on the stored application transaction counter. The method according to claim 1,
The method is:
Verifying, by the processing device, the personal identification number before generating the second session key. The method according to claim 4,
And the processing device is configured to generate an invalid second session key if the verification of the personal identification number fails. The method according to claim 1,
The first application cryptogram and the second application cryptogram are transmitted to a point of sale device. The method according to claim 2,
The memory is a non-secure element memory in a mobile communication device. A system for generating payment credentials in a payment transaction,
The system is:
Processing unit; And
A transmission device,
The processing unit is:

Generate a second session key based on the at least one stored key associated with the transaction account and the received personal identification number;
Generate a first application cryptogram based on at least the first session key; And
Generate a second application cryptogram based on at least the second session key,
The transmitting device is configured to transmit at least the first application cryptogram and the second application cryptogram for use in a payment transaction. The method according to claim 8,
The system is:
Further comprising a memory configured to store a card master key associated with the trading account,
The processing unit is:
And generate the first session key based at least on the stored card master key. The method according to claim 8,
The system is:
Further comprising a memory configured to store an application transaction counter;
The processing unit is:
And generate the first session key based at least on the stored application transaction counter. The method according to claim 8,
And the processing device is further configured to verify the personal identification number before generating the second session key. The method according to claim 11,
And the processing device is configured to generate an invalid second session key if the verification of the personal identification number fails. The method according to claim 8,
The first application cryptogram and the second application cryptogram are transmitted to a point of sale device. The method according to claim 9,
The memory is a non-secure element memory in a mobile communication device.

Images