RU2663319C2 - Method and system of safe authenticating user and mobile device without safety elements - Google Patents

Abstract

FIELD: physics.SUBSTANCE: method includes: storing a one-time key associated with a transaction account in memory; reception of a personal identification number by the receiving device; identification of the first session key by the processing device; generation of the second session key by the processing device, based on the stored one-time key and the received personal identification number; generation of the first application cryptogram by the processing device based on the first session key; generation of the second application cryptogram by the processing device, based on the second session key, and transmission of, at least, the first application cryptogram and the second application cryptogram by the transmitter for use in the payment transaction. The system implements the said method.EFFECT: security of payment.26 cl, 18 dwg

Description

RELATED APPLICATIONS

[0001] This application claims advantage under Section 119 of Section 35 of the U.S. Code of Laws, previously filed provisional patent applications No. 61 / 979,122, filed April 14, 2014; 61 / 996,665, filed May 14, 2014; 61 / 979,113, filed April 14, 2014 and, in particular, provisional patent applications No. 61 / 910,819, filed 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 61 / 980,784, filed April 17, 2014, each of which is incorporated herein by reference in its entirety.

FIELD OF TECHNOLOGY

[0002] The present invention relates to authenticating a user and a mobile device without the need for a security element in a payment transaction, and more particularly to generating secure payment credentials in a mobile device used in a payment transaction without using security elements.

BACKGROUND

[0003] Advances in mobile communications technologies have created tremendous opportunities, one of which is to enable the user of a mobile computing device to initiate and pay for payment transactions using his mobile device. One such approach, providing the possibility of such actions on a mobile device, was the use of short-range communication technology (NFC) for the secure transfer of payment details from a mobile device to the nearest contactless point of sale (POS) terminal. To achieve this, mobile phones with security element hardware, such as Security Element Crystal (SE), are used to securely store payment credentials. A security element is a special element that can be incorporated into some devices with the NFC capability, which is a platform protected from malicious interference that can safely host applications and their sensitive data.

[0004] However, not all mobile devices have security features. In addition, some financial institutions may not have access to security elements on mobile devices, even if the mobile device is equipped with such an element. As a result, many consumers with mobile devices that have the required hardware to conduct remote contactless or other types of payment transactions may not be able to actually use this opportunity. Due to such difficulties, there is a need for a technical solution that could enable mobile computing devices to initiate and conduct payment transactions without the use of security features.

[0005] Some methods and systems for conducting payment transactions using mobile devices with no security features, or without using security features in mobile devices equipped with them, can be found in US Patent Application No. 13 / 827,042, entitled ystem Systems and Methods for Processing Mobile Payments by Provisioning Credentials to Mobile Devices Without Secure Elementsʺ by Mehdi Collinge et al., Filed March 14, 2013, which is incorporated herein by reference in its entirety. Although such methods and systems may be suitable for conducting payment transactions via a mobile device without using a security element, many consumers, merchants and financial institutions may be wary of participating in such transactions because of the desire for even greater security.

[0006] As a result, there is a need for technical solutions to provide even greater security for receiving and storing payment credentials in a mobile device that does not have a security element, as well as providing increased security when transferring payment credentials to a point of sale from a mobile device during financial transaction. Increased security in these processes can lead to increased peace of mind for all involved facilities, which can lead to increased use of mobile devices for contactless or remote payment transactions, which can provide a large number of benefits for consumers compared to traditional payment methods.

SUMMARY OF THE INVENTION

[0007] The present invention provides a description of systems and methods for generating payment credentials in payment transactions.

[0008] A method for generating payment credentials in a payment transaction includes: storing in memory at least a one-time key associated with a transaction account; receiving a personal identification number by the receiver; identification by the processing device of the first session key; generating, by the processing device, a second session key, based at least on the stored one-time key and the received personal identification number; generating, by the processing device, a first application cryptogram based on at least a first session key; generating, by the processing device, a second cryptogram of the application based on at least a second session key; and transmitting, by the transmitter, at least a first application cryptogram and a second application cryptogram for use in a payment transaction.

[0009] Another method for generating payment credentials in a payment transaction includes: storing at least the primary key of the card associated with the transaction account; generating, by the processing device, the first session key, based at least on the stored master key of the card; generating the processing device of the second session key; generating, by the processing device, a first application cryptogram based on at least a first session key; generating, by the processing device, a second cryptogram of the application based on at least a second session key; and transmitting, by the transmitter, at least a first application cryptogram and a second application cryptogram for use in a payment transaction.

[0010] A 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 store at least a one-time key associated with the transaction account. The receiving device is configured to receive a personal identification number. The processing device is configured to: identify the first session key, generate a second session key, based at least on the stored one-time key and the received personal identification number; generating a first application cryptogram based on at least a first session key; and generating a second cryptogram of the application, based on at least a second session key. The transmitting device is configured to transmit at least a first application cryptogram and a second application cryptogram for use in a payment transaction.

[0011] Another system for generating payment credentials in a payment transaction includes a memory, a processing device, and a transmitting device. The memory is configured to store at least the main key of the card associated with the transaction account. The processing device is configured to generate a first session key, based at least on the stored main key of the card; generating a second session key; generating a first application cryptogram based on at least a first session key; and generating a second cryptogram of the application, based on at least a second session key. The transmitting device is configured to transmit at least a first application cryptogram and a second application cryptogram for use in a payment transaction.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The scope of the present invention is best understood from the following detailed description of exemplary embodiments when read in conjunction with the accompanying drawings.

[0013] FIG. 1 is a block diagram illustrating a high-level system architecture for processing payment transactions with enhanced security in providing and storing payment credentials according to exemplary embodiments.

[0014] FIG. 2 is a block diagram illustrating the mobile device of FIG. 1 for processing payment transactions without a security element and safely receiving and storing payment credentials according to exemplary embodiments.

[0015] FIG. 3 is a block diagram illustrating a card database of the mobile device of FIG. 2 for storing payment credentials according to exemplary embodiments.

[0016] FIG. 4 is a block diagram illustrating a memory of the mobile device of FIG. 2 for storing data used in generating advanced storage keys and generating cryptograms of an application according to exemplary embodiments.

[0017] FIG. 5 is a block diagram illustrating the transaction management server of FIG. 1 for processing payment transactions with a mobile device without a security element according to exemplary embodiments.

[0018] FIG. 6 is a block diagram illustrating a billing database of the processing server of FIG. 5 for storing payment credentials and account details according to exemplary embodiments.

[0019] FIG. 7 is a flowchart illustrating a process for transmitting and validating double cryptograms of a payment transaction processing application in which a mobile device without a security element is involved, according to exemplary embodiments.

[0020] FIG. 8 is a flowchart illustrating an alternative process for transmitting and validating double cryptograms of a payment transaction processing application in which a mobile device without a security element is involved, according to exemplary embodiments.

[0021] FIG. 9 is a flowchart illustrating a process for creating, transmitting, and validating a remote notification service or other data message provided to a mobile device without a security element, according to exemplary embodiments.

[0022] FIGS. 10A and 10B are flowcharts illustrating a process for creating, transmitting, and validating a message returned by a mobile device without a security element according to exemplary embodiments.

[0023] FIG. 11 is a flowchart illustrating a message validation process of a remote notification service using the mobile device of FIG. 2 according to exemplary embodiments.

[0024] FIG. 12 is a diagram illustrating the generation of an enhanced storage key using the mobile device of FIG. 2, according to exemplary embodiments.

[0025] FIGS. 13 and 14 are flowcharts illustrating exemplary methods for generating payment credentials in a payment transaction, according to exemplary embodiments.

[0026] FIG. 15 is a flowchart illustrating an example method of receiving and processing a remote notification service message according to exemplary embodiments.

[0027] FIG. 16 is a flowchart illustrating an example method of generating an enhanced storage key according to exemplary embodiments.

[0028] FIG. 17 is a block diagram illustrating the architecture of a computer system according to exemplary embodiments.

[0029] Additional areas of applicability of the present invention will become apparent from the detailed description presented later in this document. It should be understood that a detailed description of exemplary embodiments is intended for purposes of illustration only and, therefore, is not intended to necessarily limit the scope of the invention.

DETAILED DESCRIPTION

Glossary of Terms

[0030] A payment network is a system or network used to transfer money through the use of money substitutes. Payment networks can use many different protocols and procedures to process money transfers for various types of transactions. Transactions that can be performed through the payment network may include purchases of a product or service, purchases on credit, debit transactions, cashless transfers of money, withdrawals from an account, etc. Payment networks can be made with the possibility of transactions through money substitutes, which may include payment cards, letters of credit, checks, transaction accounts, etc. Examples of networks or systems configured to operate as payment networks include those managed by MasterCard®, VISA®, Discover®, American Express®, PayPal®, and the like. The use of the term “payment network” in this document may refer to both the payment network in the form of an object and the physical payment network, such as equipment, hardware and software, containing the payment network.

[0031] A transaction account is a financial account that can be used to finance a transaction, such as a current account, savings account, credit account, virtual payment account, etc. A transaction account may be associated with a consumer, which may be any suitable type of facility associated with a payment account, which may include a person, family, company, corporation, government facility, etc. In some cases, the transaction account may be virtual, for example, those accounts operated by PayPal®, etc.

[0032] Payment card is a card or data associated with a transaction account that may be provided to a merchant to finance a financial transaction through an associated transaction account. Payment cards can include credit cards, debit cards, payment cards, cards with a stored amount, prepaid cards, corporate corporate cards, virtual payment numbers, virtual card numbers, controlled payment numbers, etc. The payment card may be a physical card that may be provided to a merchant or service provider, or it may be data representing an associated transaction account (for example, stored in a communication device such as a smartphone or computer). For example, in some cases, data including a payment account number may be considered as a payment card for processing a transaction funded by an associated transaction account. In some cases, the check may be considered as a payment card, where applicable.

[0033] A payment transaction is a transaction between two entities in which money or other financial gain is exchanged from one entity to another. A payment transaction may be a transfer of funds, for the purchase of goods or services, for paying off a debt, or for any other exchange of financial benefits, which is obvious to a specialist in this field of technology. In some cases, a payment transaction may refer to transactions funded by a payment card and / or payment account, such as credit card transactions. Such payment transactions can be processed by the issuer, the payment network and the acquirer. The processing of such a payment transaction may include at least one of authorization, packaging, clearing, settlement and financing. Authorization may include providing the consumer with payment details to the merchant, submitting transaction details (for example, including payment details) by the merchant to his acquirer, and verifying that the issuer made the payment of the consumer’s payment account used to finance the transaction. Batching may refer to storing an authorized transaction in a batch with other authorized transactions for distribution to the acquirer. Clearing may include sending batch transactions from the acquirer to the payment network for processing. Mutual settlement may include debiting the issuer by the payment network for transactions affecting the issuer's beneficiaries. In some cases, the issuer may pay for the acquirer through a payment network. In other cases, the issuer may pay the acquirer directly. Financing may include payment to a merchant from an acquirer for payment transactions that have been cleared and settled. One skilled in the art will understand that the order and / or categorization of the steps described above is performed as part of the payment transaction processing.

[0034] Point of sale - A computing device or computer system configured to receive interaction with a user (eg, consumer, employee, etc.) to enter transaction data, payment data, and / or other suitable data types for purchase and / or payment for goods and / or services. The outlet can be a physical device (for example, a cash register, kiosk, desktop computer, smartphone, tablet computer, etc.) in a physical location that the consumer visits as part of a transaction, such as a physical store, or can be virtual in the environment e-commerce, such as online retail stores, that receive data from consumers over a network such as the Internet. In cases where a point of sale can be virtual, a computing device controlled by the user to initiate a transaction, or a computer system that receives data as a result of a transaction, can be considered as a point of sale under appropriate conditions.

System for processing payment transactions using a mobile device without security features

[0035] FIG. 1 illustrates a system 100 for processing payment transactions using a mobile device without requiring the use of security elements, which may include securing payment credentials for the mobile device, storing them securely, and using them to generate numerous cryptograms of the application for use in validation and processing of a payment transaction.

[0036] The system 100 may include a transaction management server 102. The transaction management server 102, described in more detail below, may be one or more computing devices specifically programmed to perform the functions described herein, to provide payment credentials to the mobile device 104 using a securely transmitted remote notification message, and to validate payment credentials generated by mobile device 104 as part of a payment transaction. Although it is depicted and described herein that the transaction management server 102 performs numerous functions, it will be apparent to one skilled in the art that the transaction management server 102 may be comprised of multiple computing devices, servers, and / or computer networks configured to perform functions described in this document. Mobile device 104, described in more detail below, can be any type of mobile computing device suitable for performing the functions described herein, which may include a cell phone, smartphone, smartwatch, other wearable or integrated computing device, tablet computer, laptop computer etc. In some embodiments, computing device 104 may not have a security element. In other embodiments, the mobile device 104 may include a security element, but such a element may not be used in conjunction with the methods and systems described herein, or may be used in conjunction with the methods and systems described herein, for example, to provide additional security.

[0037] The mobile device 104 may communicate with the transaction management server 104 using multiple communication channels, for example, using two-channel communication. Two-channel communication may include the use of two communication channels when transmitting and receiving data, for example, for verification and authentication, to provide greater security when transmitting data. 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 described herein. The MPA, described in more detail below, can be installed on the mobile device 104 and can be activated using the activation code provided by the transaction management server 102, using methods and systems that are obvious to a person skilled in the art, such that the mobile device 104 and the management server 102 transactions can safely transmit and receive communications over one or more communication channels using shared data.

[0038] The system 100 may also include an issuer 106. The issuer 106 may be a financial institution, such as an issuing bank, that issues a payment card or payment credentials to a consumer 108 associated with the transaction account. Issuer 106 may provide the payment details associated with the transaction account and / or payment card to the transaction management server 102. Payment details may include, for example, transaction account number, account holder name, expiration date, security code, etc. Transaction management server 102 may store data in an account database, described in more detail below. Transaction management server 102 may also provide payment credentials to mobile device 104. As used herein, the term "payment credentials" may refer to any data used by mobile device 104 and / or transaction management server 102 when transmitting and verifying the validity of payment information used in a payment transaction using the methods and systems described in this document, including, but not limited to, payment details, payment credentials, one-time keys, session keys, application cryptograms, card master keys, etc.

[0039] In some embodiments, payment credentials may be provided to the mobile device 104 via a remote notification service message. As described in more detail below, a Remote Notification Service (RNS) message can be a secure message that is transmitted to the mobile device 104, and then verified by the mobile device 104 so that the data contained therein can be protected from other devices and users. The MPA of the mobile device 104 can verify the authenticity of the received RNS message and can decrypt it to obtain the data included in it. The mobile device 104 can then perform any necessary functions based on data (for example, such as by executing instructions included in the data), and, if applicable, can generate a return message to be sent back to the transaction management server 102. In some cases, the returned message may be validated by the transaction management server 102.

[0040] In some cases, the validation of the RNS messages in the mobile device 104 or the validation of the returned messages in the transaction management server 102 may use at least message counters and an authentication code. The use of both counters and authentication codes can ensure that only the mobile device 104, which is implied, can be able to verify and decrypt the data included in the RNS message. Furthermore, if the rules and / or algorithms used to generate the authentication code are included in the MPA, then only the mobile device 104, which also includes a specific instance of the application program, may be able to verify the authenticity of the RNS message, resulting in further enhanced security. In cases where the RNS message may include billing credentials, this can ensure that billing credentials are only available on the corresponding mobile device 104, and only if the MPA used to access them is a proper and authorized application.

[0041] The payment credentials provided to the mobile device 104 can be safely stored in a storage in the mobile device 104, such as a card database, described in more detail below. In some embodiments, mobile device 104 may be configured to generate an advanced storage key for use in securely storing data, such as payment credentials, in a database or memory in mobile device 104. Generating an advanced storage key, as described in more detail below, can use unique device information, unique MPA information and randomly generated information to identify a secure storage key that cat The other can be used to securely store data on mobile device 104. As a result, payment credentials or other sensitive data can be safely stored on mobile device 104 without the use of a security element, which may result in mobile device 104 being able to initiate and conduct payment transactions without the use of a security element, increasing accessibility for issuers 106 and consumers 108, while maintaining a high level of security.

[0042] If the mobile device 104 has payment account credentials accepted, verified for validity and stored securely in it, the consumer 108 may take the mobile device 104 to a point of sale 110 at a merchant to conduct a payment transaction. Consumer 108 may select goods or services to purchase, may initiate a payment transaction to purchase them from a merchant, and may use mobile device 104 to transfer payment credentials for use in financing a payment transaction. The transfer of payment credentials to a point of sale 110 may include the transfer of two or more cryptograms of the application. The use of two or more cryptograms of the application may lead to a higher level of security for transactions processed using the methods and systems described in this document than that available with traditional contactless and remote transactions, including transactions conducted using a mobile device 104, having a security element.

[0043] Each cryptogram of the application can be generated by the mobile device 104 using separate session keys and additional data, described in more detail below. Application cryptograms generated using data stored in the mobile device 104, for example, in a storage that is secured by an advanced storage key and that is associated with the MPA, can ensure that the application cryptograms authenticate the mobile device 104 and a specific MPA instance. In some cases, one of the cryptograms and / or session keys used to generate the cryptograms may use information provided by the consumer 108, such as a personal identification number (PIN). Using PIN or other consumer authentication information may make it possible that the cryptograms authenticate both the consumer 108 and the mobile device 104. In this case, the cryptograms generated by the mobile device 104 may include one that authenticates the mobile device 104, and a second that authenticates both the mobile device 104 and the consumer 108.

[0044] Cryptograms may be received by a point of sale 110 as part of a payment transaction, for example, by short-range communication. Application cryptograms may accompany additional payment information, such as may be required in the context of any suitable type of payment transaction, such as a contactless transaction, a remote transaction, a secure remote payment transaction, a magnetic stripe transaction, and an EMV M / Chip transaction, and may be transmitted to outlet 110, using any suitable method as described herein, which is obvious to a person skilled in the art. Cryptograms may be transmitted to acquirer 112, which may be a financial institution, such as an acquirer bank associated with a merchant. Acquirer 112, for example, may issue a transaction account to a merchant that is used to receive a cash payment from consumer 108 for a payment transaction. The acquirer 112 may provide cryptograms and additional transaction information about the payment network 114 using methods and systems that are obvious to a person skilled in the art. For example, transaction information and cryptograms of the application may be included in the authorization request submitted by the payment network 114 according to the payment rules.

[0045] In some embodiments, both application cryptograms may be included in a single transaction message. For example, mobile device 104 and / or point of sale 110 may include both application cryptograms in the fields of existing data of a traditional transaction message to transmit both application cryptograms using existing payment systems and hardware. In some cases, the transaction management server 102 may be configured to use the Track 2 data (track 2) to verify the validity of cryptograms of the application, such as in a transaction using a magnetic strip. In such cases, if the transaction message includes Track 1 data (track 1), the transaction management server 102 may be configured to convert the Track 1 data to Track 2 data, which may also include converting the modified Track 1 or Track 2 data in unmodified (for example, original, restored, etc.) Track 1 or Track 2 data, respectively. By performing these functions and by including application cryptograms in the fields of existing data, the transaction management server 102 can be configured to process and verify the validity of remote and contactless payment transactions using a mobile device 104 with a higher level of security, without requiring the use of a security element on a mobile device 104 and without modifying existing payment systems.

[0046] The payment network 114 may process the payment transaction using methods and systems that are obvious to a person skilled in the art. As part of the processing, the payment network 114 may transmit application cryptograms to the issuer 106 for verification. In some embodiments, verification may 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, application cryptograms may be transmitted to the transaction management server 102 and may be verified by generating validation cryptograms of the application using the transaction management server 102, which may be generated using locally stored payment credentials. In other embodiments, the issuer 106 or the payment network 114 may request cryptograms of the application from the transaction management server 102, which can generate them and return the cryptograms to the issuer 106 or the payment network 114 for verification in comparison with the cryptograms created by the mobile device 104.

[0047] Since the transaction management server 102 has payment credentials and other data used by the mobile device 104 to generate application cryptograms, validation of the payment credentials generated by the mobile device 104 to finance the payment transaction can be performed by comparing the application cryptograms generated by the mobile device 104, and those generated by the transaction management server 102. In some embodiments, the transaction management server 102 may be part of the payment network 114 or issuer 106. In cases where the transaction management server 102 may be part of the payment network 114, validation may be performed before contacting the issuer 106 as part of traditional payment transaction processing (e.g. to approve the financing of the transaction using the consumer transaction account 108 with the issuer 106).

[0048] Through the use of multiple cryptograms of the application, the security of payment transactions can be enhanced. In addition, in cases where each cryptogram can authenticate separate data, such as cases where one cryptogram authenticates the mobile device 104 and the other authenticates both the mobile device 104 and the consumer 108 (for example, via a consumer PIN), it can also provide issuer 106 additional data and reasons to use when deciding to approve or reject the transaction. For example, if both cryptograms are incorrect (for example, the cryptograms generated by the mobile device 104 do not coincide with those generated by the transaction management server 102), the transaction may be rejected. If one cryptogram is correct and the other is incorrect, the transaction may be rejected for security reasons, or may be approved, for example, based on the decision of the issuer 106. For example, the issuer 106 may approve a transaction where user authentication fails, but the mobile device is authenticated, since other available data may indicate that an authorized user, but not a consumer 108, is using the mobile device 104 for a transaction.

[0049] As a result, the use of both cryptograms can provide useful data that can be used by payment networks 114 and emitters 106 in processing payment transactions. In addition, the use of two or more cryptograms can provide increased security than in traditional methods of contactless or remote payment, which can lead to less fraud and greater recognition for consumers 108, issuers 106 and merchants. In cases where the use of two or more cryptograms of the application is generated from payment credentials that were securely used using the RNS messaging methods and systems described in this document and stored securely through advanced storage keys generated using the methods and systems described in This document, the overall security of the system 100 can be greatly improved compared to traditional systems for processing contactless payments and ADCC. As a result, system 100 can provide enhanced security in several aspects of data transfer, storage, and processing than was provided in traditional contactless payment systems and for other types of remote payment transactions and payment transactions in general, which may use the methods and systems described herein .

Mobile device

[0050] FIG. 2 illustrates an embodiment of a mobile device 104 of system 100. It is obvious to a person skilled in the art that an embodiment of the mobile device 104 shown in FIG. 2 is provided only as an illustration and cannot be exhaustive for all possible configurations of a mobile devices 104 suitable for performing functions as described herein. For example, the computer system 1700 depicted in FIG. 17 and described in more detail below may be a suitable configuration for a mobile device 104.

[0051] The mobile device 104 may 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 may receive, for example, program data for one or more application programs to be installed on and executed on the mobile device 104, such as a mobile payment application (MPA), described in more detail below. The receiving unit 202 may also receive Remote Notification Service (RNS) messages, such as messages sent by the transaction management server 102, including RNS messages that include billing credentials. The receiving unit 202 may also receive additional data suitable for performing the traditional functions of the mobile device 104, such as telephone, cellular, etc. In some cases, 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 suitable protocols. For example, mobile device 104 may include a first receiving unit 202 for receiving data for NFC transactions, and a second receiving unit 202 for receiving communication over a mobile communication network.

[0052] Mobile device 104 may also include an input unit 214. The input unit 214 may be configured to communicate with one or more input devices that are internally or externally connected to the mobile device 104 to receive input from the consumer 108, such as a keyboard, mouse, control wheel, scroll wheel, touch screen, microphone, camera, receiver, etc. An input unit 214 may receive input from a consumer 108, which may be processed by the processing unit 204.

[0053] The processing unit 204 may be configured to perform the functions of the mobile device 104 described herein. Processing unit 214 may execute program code stored in a mobile device, such as for MPA, and may be configured to perform a variety of functions associated with each application program, in addition to other functions of mobile device 104. Processing unit 204 may receive input from the consumer 108 through the input unit 214 and perform functions accordingly, for example, by executing application programs, performing functions in programs, receiving data, transmitting data, displaying data, etc. ., which is clear to a person skilled in the art. For example, processing unit 204 may be configured to validate RNS messages, generate advanced storage keys, and generate application cryptograms, as described in more detail below.

[0054] Mobile device 104 may also include a display unit 210. The display unit 210 may be configured to communicate with one or more display devices that are internally or externally connected to the mobile device 104 to display data, such as data transmitted to the display unit 210 for display by the processing unit 204. Display devices may include liquid crystal displays, light emitting diode displays, thin film transistor displays, touch screen displays, etc.

[0055] The mobile device 104 may also include a transmitting unit 206. The transmitting unit 206 may be configured to transmit data over one or more networks using one or more network protocols. The transmitting unit 206 may transmit RNS response messages to the transaction management server 102. The transmitting unit 206 may also be configured to transmit cryptograms of the application and / or payment credentials, for example, a point of sale 110, for use in a payment transaction. The transmitting unit 206 may further be configured to perform additional functions of the mobile device 104, which is obvious to a person skilled in the art, such as the traditional functions of a mobile communication device for transmitting cellular communications, etc. In some cases, the mobile device 104 may include multiple transmit units 206, which may be separately configured to communicate with one or more separate networks, such as a transmit unit 206, configured to transmit payment credentials and cryptograms of the application via NFC, and another transmitting unit 206, configured to transmit data over a mobile communication network.

[0056] Mobile device 104 may also include a card database 208. The card database 208, described in more detail below, can be a data store on a mobile device 104, which is configured to store data associated with one or more transaction accounts and / or payment cards. The card database 208 may store the payment credentials associated with the transaction account, such as provided to the mobile device 104 by the transaction management server 102 in a secure RNS message, and additional data that can be used to generate cryptograms of the application, as described in more detail below. In some cases, the card database 208 may be stored as part of a mobile payment application.

[0057] The mobile device 104 may further include a memory 212. The memory 212, described 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 described herein. For example, memory 212 may store data suitable for generating advanced storage keys for encrypting additional data in mobile device 104, such as card database 208, as described in more detail below. The memory 212 may also be configured to store program code for application programs executed by processing unit 204, such as an operating system, program code for receiving data by data input and display unit 214 by means of display unit 210, rules and / or algorithms for performing functions described in this document, etc. The memory 212 may also store data suitable for performing the traditional functions of the mobile device 104, such as rules and / or algorithms for transmitting and receiving cellular communications via a mobile communications network. Additional data stored in memory 212 is obvious to a person skilled in the art.

Mobile Device Card Database

[0058] FIG. 3 illustrates an embodiment of a card database 208 of a mobile device 104 for storing payment credentials and other data associated with transaction accounts for use in financing payment transactions conducted using the mobile device 108.

[0059] The card database 208 may include one or more of the payment profiles 302 shown in FIG. 3 as payment profiles 302a, 302b, and 302c. Each payment profile 302 may be associated with a transaction account that can be used to finance a payment transaction and may include at least payment credentials 304, one or more one-time keys 306, a first session key 308, a second session key 310, and a transaction counter 312 applications.

[0060] Payment credentials 304 may include data associated with a related transaction account, which is used to identify and validate the payment network 114 and / or issuer 106 when processing a payment transaction using the related transaction account. Payment credentials 304 may include, for example, payment account number, security code, expiration date, cardholder name, authorized user name, tracking data, card layout description data, number of digits, bitmaps, etc.

[0061] One-time keys 306 may be payment tokens valid for one payment transaction, which may be used by processing unit 204 of mobile device 104 to generate one or more cryptograms of the application used in the payment transaction. In some embodiments, the one-time key 306 may include one or more other data items included in the payment profile 302. For example, each one-time key 306 may include a separate application transaction counter 312 that may not be included separately in the payment profile 302 Various configurations of data stored in the payment profile 302 for use in performing the functions described herein are apparent to those skilled in the art. In some cases, a one-time key 306 may include, or may consist of, a key used to generate one or more cryptograms of the application. In some embodiments, the first session key 308 and the second session key 310 may be included in a one-time key 306 provided to the mobile device 104 and / or generated using data included in the one-time key 306.

[0062] The first session key 308 and the second session key 310 may be additional keys that are used by the processing unit 204 to generate application cryptograms transmitted to the outlet 110 as part of a payment transaction using the mobile device 104. In some embodiments, the first session the key 308 can be used when generating the first cryptogram of the application by the processing unit 204, for example, using program code, rules or algorithms stored in the mobile memory 212 the first device 104. The second session key 310 may be used in generating the second cryptogram application.

[0063] In some embodiments, the second session key 310 may be generated by processing unit 204. In such an embodiment, the second session key 310 may be generated using a one-time key 306 and user authentication data, such as PIN provided by the consumer 108 (for example, via input unit 214). In such an embodiment, the second session key 310 may not be stored in the payment profile 302 and, instead, may be generated, used, and discarded as part of the payment transaction process. The second cryptogram of the application, therefore, can, when generating from the second session key 310, which is generated using the one-time key 306 and the consumer PIN, serve to authenticate both the mobile device 104 and the consumer 108.

[0064] A Personal Identification Number (PIN) can be a number provided by a consumer 108 (for example, when registering an MPA on a mobile device 104 or registering a transaction account with an issuer 106 and / or transaction management server 102) that can be used to authenticate a consumer 108. When conducting 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 provided PIN is incorrect (for example, does not match the PIN provided by the consumer 108 during registration), then the processing unit 204 may continue to generate a second session key 310 and then generate a second cryptogram of the application. If the provided PIN is incorrect, then the second cryptogram of the application will thus be incorrect, which will lead to an unsuccessful verification of the reliability of the second cryptogram of the application by the transaction management server 102, the issuer 106 and / or the payment network 114, which may allow the issuer 106 to reject the transaction accordingly or still approve the transaction.

Mobile device memory

[0065] FIG. 4 illustrates an embodiment of a memory 212 of a mobile device 104 for storing application programs and other data to be used in a secure data store on mobile device 104 and for conducting payment transactions using mobile device 104. In an exemplary embodiment, memory 212 is not may be a safety feature.

[0066] The memory 212 may include information about the device 402. The device information 402 may include one or more pieces of data associated with the mobile device 104, which, in some cases, may be unique to the mobile device 104. For example, the device information 402 may include a media access control address , reference number, serial number, identification number, etc. Additional information, which may be considered as information 402 about the device of mobile device 104, is obvious to a person skilled in the art.

[0067] The memory 212 may also include a mobile payment application (MPA) 404. The MPA 404 may be an application program configured to perform the functions of the mobile device 104 described herein, such as receiving and storing payment credentials, verification the reliability of RNS messages and the generation of cryptograms of the application for use in conducting payment transactions. Additional features of the MPA 404 may include traditional features of a digital wallet or other similar application program, which is obvious to a person skilled in the art.

[0068] The MPA 404 may include program code 406. The program code 406 may be a code executed by the processing unit 204 of the mobile device 104, which causes the processing unit 204 and other components of the mobile device 104 to execute MPA functions 404, as described herein . For example, program code 406 may include code suitable for generating cryptograms of an application, validating RNS messages, etc. The program code 406 may also include program code suitable for generating a random value that can be used to generate an advanced storage key. The random value may be a random or pseudo-random number that can be generated using methods and systems that are obvious to a person skilled in the art.

[0069] The MPA 404 may also include an instance identifier 408. Instance identifier 408 may be a value unique to a particular MPA 404 that can be used to generate an advanced storage key used to secure data in mobile device 104, such as card database 208. Having an instance ID 408 unique to MPA 404, multiple MPA 404s can be installed on mobile device 104, and any one MPA 404 cannot access data that is safely stored by any other MPA 404, which can thus ensure that payment profiles 302 for specific transaction accounts are not available for other programs. Instance identifier 408 may be a number, an alphanumeric value, a hexadecimal value, or any suitable value that may be unique to the MPA 404.

[0070] As described in more detail below, the processing unit 204 of the mobile device 104 may be configured to generate a diversifier value using device information 402, a random value generated using the MPA program code 406 404, and an instance identifier 408 stored in the MPA 404. The value of the diversifier can be used by the cryptographic application 410, also stored in the memory 212. The cryptographic application 410 may be an application program configured to execute cryptography type "white box" and / or any other suitable cryptographic function, which is obvious to a person skilled in the art.

[0071] The cryptographic application 410 may include program code 412. The program code 412 may be executed by the processing unit 204 of the mobile device 104, making it possible for the processing unit 204 and other components of the mobile device 104 to perform the cryptographic functions of the cryptographic application 410 described herein. Functions may include generating an advanced storage key. The enhanced storage key can be generated using the diversifier value generated by the mobile payment application 404 and the encryption key 414 included in the cryptographic application 410. In some embodiments, the diversifier key can be decrypted using the encryption key 414 to obtain the enhanced storage key.

[0072] The cryptographic application 410 can also be configured to encrypt storage in mobile device 104 using an advanced storage key. In some embodiments, encryption may be performed using one or more white box cryptography techniques. The encrypted storage may be card database 208 and / or any other suitable storage on mobile device 104, such as data stored in MPA 404. In some embodiments, cryptographic application 410 may be included as part of MPA 404. The enhanced storage key may be stored in cryptographic application 410 or MPA 404, or, in some cases, can be regenerated by MPA 404 and cryptographic application 410, when necessary.

[0073] The memory 212 may also include any additional data stored in the mobile device 104 suitable for performing the functions described herein, as well as any additional functions of the mobile devices. For example, memory 212 may include program code for an operating system, code, rules, or algorithms for receiving and transmitting mobile communications, such as phone calls, etc.

[0074] In some embodiments, mobile device 104 may also be configured to receive data already encrypted using an advanced storage key that can be stored in encrypted local storage in mobile device 104, for example, in memory 212, card database 208, or in another suitable repository. In such an embodiment, the mobile device 104 may be configured to transmit the generated random value to a transaction management server 102 or other trusted entity that can generate an advanced storage key using the same methods and systems using the generated random value and can encrypt data that provided to the mobile device 104. The mobile device 104 can thus receive data already encrypted using the enhancement storage key for local storage on the mobile device 104.

Transaction management server

[0075] FIG. 5 illustrates an embodiment of a transaction management server 102 of a system 100. It will be apparent to those skilled in the art that the embodiment of the transaction management server 102 depicted in FIG. 5 is provided as an illustration only and may not be exhaustive for all. possible configurations of the transaction management server 102 suitable for performing functions as described herein. For example, the computer system 1700 depicted in FIG. 17 and described in more detail below may be a suitable configuration of a transaction management server 102.

[0076] 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. A receiving unit 502 may receive data from a mobile device 104, for example, receiving returned messages, confirmation messages, transaction notifications, etc., a payment network 114, an issuer 106, or other suitable entity. The receiving unit 502 may receive transaction notifications or cryptogram requests, for example, to initiate the generation of application cryptograms for use in validating payment credentials in a payment transaction. The receiving unit 502 may also receive transaction account data, for example, from the issuer 106, for use in generating payment credentials for provision to the mobile device 104.

[0077] The transaction management server 102 may also include a processing unit 504. Processing unit 504 may be configured to perform the functions of the transaction management server 102 described herein, which is obvious to a person skilled in the art. Processing unit 504 can thus be configured to generate and encrypt RNS messages and the data included therein, verify the authenticity of the returned messages from the mobile device 104, generate payment credentials, generate cryptograms of the application, verify the authenticity of the cryptograms of the application, etc. ., as described in more detail below.

[0078] The transaction management server 102 may further include a transmitting unit 506. The transmitting unit 506 may be configured to transmit data over one or more networks via one or more network protocols. The transmitting unit 506 can transmit RNS messages, payment credentials, application cryptograms, validation notifications, and other data that are obvious to a person skilled in the art. The transmitting unit 506 may be configured to transmit data to a mobile device 104, for example, via a mobile communication network or the Internet, a payment network 114, an issuer 106, and any other suitable object.

[0079] The transaction management server 102 may also include an invoice data base 508. The invoice data base 508, described in more detail below, may be configured to store account information for multiple transaction accounts. Account information may include data and keys used to generate cryptograms of the application used to verify the validity of the payment credentials received during payment transactions conducted using the mobile device 104. The account data base 508 may also be configured to store data transaction information for payment transactions conducted with the participation of the mobile device 104 and other data, such as data associated with the consumer 108 or other authorized agents users of the related transaction account.

[0080] The transaction management server 102 may also include a memory 510. The memory 510 may be configured to store additional data for use by the transaction management server 102 in performing the functions described herein. For example, memory 510 may store rules or algorithms for validating application cryptograms, rules or algorithms for generating validation notifications, algorithms for generating session keys and application cryptograms, encryption keys for encrypting and decrypting RNS data and messages, etc. Additional data that may be stored in memory 510 is obvious to a person skilled in the art.

Transaction Management Server Account Database

[0081] FIG. 6 illustrates an embodiment of an account database 508 of a transaction management server 102 for storing data related to transaction accounts for use in validating payment credentials and other transaction data provided when conducting payment transactions involving the use of a mobile device 104 .

[0082] The invoice data base 508 may include a plurality of account profiles 602, shown in FIG. 6, as account profiles 602a, 602b, and 602c. Each account profile 602 may include one or more one-time keys 604, a first session key 606, a second session key 608, an application transaction counter 610, and a first card master key 612. In some embodiments, the account profile 602 may further include a second card master key 612.

[0083] Each account profile 602 may correspond to a payment profile 302 provided to the mobile device 104. Essentially, one-time keys 604 stored in the account profile 602 may correspond to one-time keys 306 stored in the corresponding payment profile 302 related to the same transaction account . The data may be similar, such that when the application cryptogram is generated by the transaction management server 102 or the mobile device 104, the application cryptograms must match if the data is correct and not tampered with, which may make it possible to verify the validity of the payment credentials provided by the mobile device 104.

[0084] In some embodiments, the account profile 602 may include a personal identification number (PIN) that corresponds to a PIN 314 stored in the corresponding payment profile 302. In such an embodiment, the PIN 314 may be provided to the receiving unit 202 of the transaction management server 102 in a secure a message, such as a receipt message provided by the mobile device 104, described in more detail below. In other embodiments, a card master key may be used in place of a PIN, such as a first card master key 612. 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 master key 614 of the card, which corresponds to the second session key 310 generated by the mobile device 104 using a one-time key 306 and PIN 314. In some cases, the second session key 608 may also be based on a corresponding one-time key 604. In such embodiments, algorithms for generating session keys and / or application cryptograms eniya can ensure that the cryptogram generated by the mobile device 104 and the transaction management server 102, correspond on the basis of the data used therein.

[0085] The first session key 606 can be used by the processing unit 504 of the transaction management server 102 to generate the first cryptogram of the application, and the second session key 608 can be used to generate the second cryptogram of the application. In some embodiments, an application transaction counter 610 may be used to generate one or more session keys and / or cryptograms of the application. The transaction counter 610 of the application may be a value corresponding to the ongoing payment transaction, which is increased or otherwise 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, so that its use can ensure that only reliable MPA 404 can have the correct application transaction counter 312 to generate valid session keys and / or cryptograms applications. Additional methods may be used to further enhance the security of generating the session key and / or cryptograms of the application, such as unpredictable numbers and other methods that are obvious to a person skilled in the art.

Processing payment transactions using a mobile device

[0086] FIG. 7 illustrates a process for processing payment transactions conducted using a mobile device 104 without a security element and using the generation and validation of two or more cryptograms of an application.

[0087] At step 702, the transaction management server 102 may provide (for example, through the transmitting unit 506) payment credentials 304 and other account data to the mobile device 104, for example, via an RNS message described in more detail below. At step 704, the receiving unit 202 of the mobile device 104 may receive payment credentials 304 and other account data. At step 706, the processing unit 204 of the mobile device 104 may store data in the payment profile 302 in the card data base 208. Account data may include payment credentials 304, one or more one-time keys 308, and any other suitable data, such as one or more session keys 308 and 310.

[0088] At step 708, the processing unit 204 may generate two cryptograms of the application for use in conducting a payment transaction. In some embodiments, step 708 may be initiated by consumer 108, for example, by indicating via input unit 214, by placing mobile device 104 near a point of sale 110 to initiate a transaction by short-range communication, or in another suitable manner. Generating application cryptograms may include generating a first application cryptogram using a first session key 308 stored in the payment profile 302. A second application cryptogram can be generated using a second session key 310, which can be generated using a one-time key 306 and PIN 314. In some In some cases, the consumer 108 may enter the PIN in the mobile device 104 (for example, via the input unit 214) before step 708 or during the initiation of step 708. In some embodiments, the implementation Ia one or both cryptogram applications may also be generated using a counter 312 application transaction.

[0089] If cryptograms of the application were generated, they, together with payment credentials 304, can be transmitted to the issuer 106 through the outlet 110, acquirer and payment network 114. Payment credentials 304 and cryptograms of the application can be received by the issuer 106 at step 710. At step 712, the transmitting unit 206 of the mobile device 104 may transmit a transaction notification to the transaction management server 102. At step 714, the receiving unit 502 of the transaction management server 102 may receive a transaction notification. The transaction notification may notify the transaction management server 102 that the mobile device 104 has initiated a payment transaction using the payment profile 302. In some cases, the transaction notification may include identification information.

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

[0091] In step 718, the transmitting unit 506 of the transaction management server 102 may transmit the generated application cryptograms to the issuer 106, which may receive the cryptograms in step 718. At step 720, the issuer 106 may verify the validity of the application cryptograms provided by the mobile device 104 accompanying the payment credentials 304 Validation of the cryptograms of the application may include comparing the cryptograms provided by the mobile device 104 with the cryptograms of the application generated and presented ennymi transaction management server 102. If the validation is performed, then, at step 722, the issuer 106 may process the transaction accordingly. Transaction processing may include the approval of a payment transaction, for example, if one or both cryptograms are verified for reliability, or the rejection of a payment transaction, for example, if it is determined that one or both cryptograms are invalid.

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

[0093] FIG. 8 illustrates an alternative payment transaction processing process using a mobile device 104.

[0094] At step 802, payment credentials 304 and other account data may be transmitted to mobile device 104 by transmitting unit 506 of transaction management server 102. At step 804, the receiving unit 202 of the mobile device 104 may receive payment credentials 304 and other account data that may be stored in the payment profile 302 at step 806. At step 808, the processing unit 204 of the mobile device 104 may generate two cryptograms of the application, as described above, and may transmit cryptograms, payment credentials 304, and other suitable data to the issuer 106 (for example, through a point of sale 110).

[0095] At 810, the issuer 106 may receive application cryptograms and any other suitable data that may be used by the issuer 106 to verify the accuracy of the transaction data and / or process approval or rejection of the transaction. At 812, the issuer 106 may submit a cryptogram verification request to the transaction management server 102. In some embodiments, the request may include payment credentials 304 or other data suitable for use by the transaction management server 102 in identifying the account profile 602 to be used to generate validation cryptograms. In one embodiment, the request may further include two application cryptograms generated by the mobile device 104 for validation.

[0096] At step 814, the receiving unit 502 of the transaction management server 102 may receive a cryptogram request. At 816, the processing unit 504 of the transaction management server 102 may generate two application cryptograms to be used for validation, as described above. In embodiments where the cryptogram request also includes two application cryptograms generated by the mobile device 104, step 816 may also include validating the two cryptograms by processing unit 504 using two newly generated application cryptograms. Validation cryptograms, or the validation result in applicable embodiments, may be transmitted by the transmitting unit 506 to the issuer 106. At step 818, the issuer 106 may receive validation cryptograms and / or the validation result.

[0097] At step 820, the issuer 106 may verify the validity of the application cryptograms provided by the mobile device 104 using the application cryptograms generated by the transaction management server 102. In embodiments where the transaction management server 102 provides the validation result to the issuer 106, step 820 may include identifying the validation result of each of the two cryptograms of the application. At 822, the issuer 106 may process the payment transaction accordingly, based on the result of the validation. At step 824, transaction notifications can be transmitted to the transaction management server 102 and the mobile device 104 received by the respective receiving units 502 and 202 in steps 826 and 828, respectively.

Remote Notification Service and Data Messaging

[0098] FIG. 9 illustrates a process for transmitting and validating Remote Notification Service (RNS) messages and other data messages transmitted from a transaction management server 102 to a mobile device 104. RNS messages can be transmitted through a remote notification service, such as a service that uses a mobile communication network associated with mobile device 104. RNS messages can be used to provide payment credentials 304 and other account data to mobile device 104, such as account data a, used in the processing of payment transactions, as described above, and other information that can be used to establish a secure connection between the mobile device 104 and the transaction management server 102.

[0099] At step 902, the processing unit 504 of the transaction management server 102 may generate a message. In cases where mutual authentication is established with the mobile device 104, the message may include information suitable for establishing mutual authentication, such as a session identifier. In other cases, such as when mutual authentication has been established between the transaction management server 102 and the mobile device 104 using the process depicted in FIG. 9 and described herein, the generated message may include payment credentials 304 and account data, may include one or more instructions for execution by MPA 404 of the mobile device 104 (for example, deleting one-time keys 306 or payment credentials 304, etc.), may represent notifications for I the user 108 (e.g., account balance, a payment notice, etc.) or may include other suitable data.

[0100] At 904, the processing unit 504 may encrypt the generated message. The message may be encrypted using a secret key from a pair of secret / public key, where the mobile device 104 may have a corresponding public key. In some cases, the message may be encrypted using the encryption key associated with the mobile device 104 or MPA 404, such as encryption key 414. At 906, the processing unit 504 may generate a message authentication code. A message authentication code can be generated using an encrypted message and can be a key that is generated using one or more specially configured rules and / or algorithms. For example, a message authentication code may be generated using one or more encryption and confusion methods, such as filling in insignificant information. In some embodiments, a message authentication code may be generated using an encryption key.

[0101] In step 908, the transmitting unit 506 of the transaction management server 102 may transmit the merged data message to the mobile device 104. In embodiments where mutual authentication can be performed, the merged data message may be a remote notification service message transmitted to the mobile device 104 through the remote notification service. The combined data message may be received by the receiving unit 202 of the mobile device 104 in step 910, and may include a message authentication code and an encrypted message. In some cases, the combined data message may also include an additional identifier, such as an identifier generated using methods known to the MPA 404 to verify its authenticity. In some cases, such as when mutual authentication has already been completed, the message with the combined data may also include a message counter.

[0102] At step 912, the processing unit 204 may generate a reference authentication code. The authentication reference code can be generated using the received encrypted message and can be generated using the same rules and algorithms that the transaction management server 102 used to generate the message authentication code, so that the generated authentication reference code will correspond to the message authentication code if the message authentication code is generated a reliable source (e.g., transaction management server 102). In embodiments where the message authentication code may be generated using the encryption key, the processing unit 204 may generate a reference authentication code using the encryption key 414 stored in the memory 212 or another suitable encryption key.

[0103] At step 914, the processing unit 204 can verify the authenticity of the message authentication code included in the received message with the combined data by comparing it with the generated reference authentication code. If the authenticity of both the message counter and the message authentication code is verified, then it can be determined that the message with the combined data is reliable (for example, authentic), as received from the transaction management server 102. In cases where the combined data message may include a message identifier, processing unit 204 can also verify the authenticity of the message identifier by generating a message identifier using a process known to the MPA 404 to generate and compare it. In embodiments where the combined data message may include a message counter, processing unit 204 may check the accuracy of the message counter included in the received combined data message with a reference counter stored in mobile device 104, for example, in MPA 404 or billing profile 502.

[0104] At step 916, the processing unit 204 may decrypt the encrypted message included in the received message with the combined data. An encrypted message can be decrypted using a key, such as a key stored in memory 212 (e.g., in a cryptographic application 410 or MPA 404) or stored in a local encrypted database (e.g., encrypted using an advanced storage key) or another suitable decryption method. At step 918, processing unit 204 may perform one or more appropriate actions based on data decrypted from the encrypted message. In the example of FIG. 9, the mobile device 104 may authenticate with the transaction management server 102, for example, using a session identifier included in the encrypted message and decrypted by the processing unit 204. At step 920, the transaction management server 102 may receive a session identifier and perform any additional steps necessary for mutual authentication with the mobile device 104. In cases where mutual authentication has already been performed, the message may include other information suitable for performing the functions described in this document, such as payment credentials 404, one-time keys 406, program instructions for MPA 404, etc.

[0105] In some embodiments, the mobile device 104 may be configured (eg, through the MPA 404) to generate and present a return message to the transaction management server 102. In some cases, the returned message may include data generated in response to actions performed as instructed in the decrypted message, as described above. For example, the returned message may indicate the reliable receipt and storage of payment credentials 304 or one-time keys 306. In other cases, the returned message may be a notification of receipt and validation of the message with the combined data. In cases where mutual authentication is first performed, the returned message may include a session identifier used to perform mutual authentication.

[0106] FIGS. 10A and 10B depict a process for generating and transmitting a returned message by the mobile device 104 and verifying its authenticity by the transaction management server 102.

[0107] In step 1002, the processing unit 204 of the mobile device 104 may generate a receive message. A receive message may be generated based on program code 406 stored in the MPA 404, and may further be based on actions performed as indicated in the decrypted message with the combined data received from the transaction management server 102. For example, a receipt message may include a notification of the successful receipt and storage of payment credentials 304. At block 1004, the processing unit 204 may increase the receipt counter. The receipt counter may be a counter indicating the number of receive messages transmitted to the transaction management server 102. The receipt counter may be stored in memory 212, for example, in the MPA 404, or in a database encrypted using an advanced storage key. For a person skilled in the art it is obvious that step 1004 can be an optional step and can only be used in cases where the counter is used to verify the authenticity of the data message.

[0108] In step 1006, the processing unit 204 may encrypt the receive message. The receive message may be encrypted using the encryption key 414 stored in the cryptographic application 410, or may otherwise be stored in the MPA 404 or a locally encrypted database. The encryption key used to encrypt the receipt message may be a secret key as part of a key pair, the transaction management server 102 having a corresponding public key. At step 1008, the processing unit 204 may generate a receipt authentication code based on an encrypted receipt message. In some embodiments, the receipt authentication code may be generated using the same rules, algorithms, and / or processes that were used to generate the reference authentication code shown in step 912 of FIG. 9 described above.

[0109] In step 1010, the transmitting unit 206 of the mobile device 104 may transmit a receipt notification message to the transaction management server 102. The receipt notification message may be received by the receiving unit 502 of the transaction management server 102 and may include at least a receipt authentication code, an encrypted receipt message, and a receipt counter. In some embodiments, the receipt notification message may be transmitted to the transaction management server 102 using a mobile communication network, such as a cellular network associated with the mobile device 104.

[0110] At 1014, the processing unit 504 of the transaction management server 102 may increment the acknowledgment counter. The acknowledgment counter may indicate the number of messages received from the mobile device 104 used to verify the authenticity of the messages received from the mobile device 104. The acknowledgment counter may be stored in the memory 510 of the transaction management server 102 or in another suitable data store. For example, in some embodiments, a confirmation counter may be stored in the account profile 602 associated with the mobile device 104. In one example, each account profile 602 may include a confirmation counter (eg, and / or a message counter) to be used for messages transmitted to / from the transaction management server 102 and the mobile device 104 related to the corresponding transaction account. For a person skilled in the art it is obvious that step 1014 may be an optional step and may not be performed in cases where the counter may not be used to verify the authenticity of the returned messages.

[0111] At block 1016, the processing unit 504 may generate a confirmation authentication code. A confirmation authentication code may be generated based on the 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. At 1018, the processing unit 504 may check the validity of the receipt counter included in the receipt notification message by comparing it with the acknowledgment counter. At 1020, the processing unit 504 can verify the validity of the receipt authentication code by comparing it with the message authentication code to ensure that the message comes from an authorized mobile device 104.

[0112] If the counter (for example, if applicable) and the authentication code is verified, then, at 1022, the processing unit 504 can decrypt the encrypted message included in the received receipt notification message. An encrypted message can be decrypted using a stored encryption key or other suitable decryption method. The encrypted message may be decrypted to receive a receive message generated by the mobile device 104. At step 1024, the processing unit 504 may perform any appropriate action as necessary based on the data included in the receive message. For example, if the receive message includes an indication of the successful receipt and storage of one-time keys 306, processing unit 204 may activate the corresponding one-time keys 604 in the corresponding account profile 602.

Validation of data messages

[0113] FIG. 11 illustrates a process 1100 for validating data messages received by a mobile device 104 from a transaction management server 102.

[0114] At step 1102, the processing unit 204 of the mobile device 104 may store encryption keys, authentication generation keys, and rules and / or algorithms for use and application in a local storage, such as memory 212 or a locally encrypted storage, encrypted using an advanced storage key . At 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, a data message may be received from the transaction management server 102 after establishing mutual authentication between the two devices, for example, using the process depicted in FIG. 9 and described above. A data message may include at least a message counter, a message authentication code, and an encrypted message.

[0115] At step 1106, the processing unit 204 may increment the reference counter. The reference counter may be stored in memory 212 or other local storage and may be used to indicate the number of messages received from the transaction management server 102. In some cases, the reference counter may be incremented using an algorithm, so that the reference counter may not be incremented using sequential numbers, but by an algorithm known to mobile device 104 (e.g., via MPA 404) and transaction management server 102.

[0116] At step 1108, the processing unit 204 may check the accuracy of the message counter included in the received data message. The validation of the message counter may include comparing the message counter with the value of the reference counter after increasing. An unsuccessful validation may indicate that the source of the data message is not the transaction management server 102, or else it is not reliable. If the validation is unsuccessful, then at block 1110, the processing unit 204 may perform one or more appropriate actions associated with the unsuccessful receipt and / or validation of the data message. For example, processing unit 204 may discard a data message, may notify transaction management server 102, may block associated payment profile 302, or perform another action that is obvious to a person skilled in the art.

[0117] If a message counter validation passes, then process 1100 may go to step 1112, where the encrypted message may be filled with insignificant information. Filling the encrypted message with insignificant information may include adding values to the encrypted message or the data associated with it. Filling with insignificant information can be used to increase the security of the message validation process, since there may be another function that should be performed by the mobile device 104 and the transaction management server 102, known to each other, which should be duplicated by an unauthorized object in order to successfully transmit or receive a data message without authorization. For a person skilled in the art it is obvious that step 1112 may be an optional step. In some embodiments, step 1112 may be applied in some instances of process 1110. For example, an encrypted message may be populated with insignificant information at some increases in the reference counter.

[0118] At step 1114, the processing unit 204 may generate a reference authentication code. The authentication authentication code may be generated based on an encrypted message (for example, filled with insignificant information, if applicable) using one or more rules or algorithms, such as stored in step 1102. In some embodiments, the authentication authentication code may be a key or may represent is the value generated by applying the key to an encrypted message. At step 1116, the processing unit 204 can verify the authenticity of the message authentication code received in the RNS message. Validation of the message authentication code may include comparing the code with the generated authentication reference code, as another identification method, if the received data message is from an authorized source (e.g., transaction management server 102).

[0119] If the verification of the message authentication code is unsuccessful, the process 1100 may proceed to step 1110, where the failure processing is performed. If a message authentication code is validated, then at step 1118, the encrypted message included in the received data message can be decrypted by processing unit 204. The message can be decrypted using one or more encryption / decryption keys, rules and / or algorithms, such as those stored in the mobile device 104 at step 1102. For example, the encryption key 414 stored in the cryptographic application 410 of the memory 212 can be used to decryption of the encrypted message. At step 1120, the processing unit 204 may perform one or more actions as necessary, based on the contents of the decrypted message. For example, if the decrypted message includes one-time keys 306, one-time keys 306 can be stored in the corresponding payment profile 302 of the card database 208, which can thus be encrypted using an advanced storage key.

Advanced Storage Key

[0120] FIG. 12 illustrates the generation and use of an advanced storage key by a mobile device 104 for securely storing data in a mobile device 104, such as payment profiles 302 and other data that can be safely stored and that can be safely accessed in a mobile device 104 without using security elements.

[0121] 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 in FIG. 12 as the device information 1202a, 1202b and 1202c. Each piece of device information 1202 may be associated with a mobile device 104. In some cases, each piece of device information 1202 may be unique to mobile device 104. In other cases, one or more pieces of device information 1202 may not be unique to mobile device 104 ( for example, model number), but three pieces of information about the device 1202, taken together, may be unique to the mobile device 104 (for example, a unique combination). Portions of device information 1202 may be data that does not change over the life of the mobile device 104.

[0122] The processing unit 204 of the mobile device 104 may generate a characteristic feature 1204 of the mobile device based on three pieces of information about the device 1202a, 1202b, and 1202c. Feature 1204 of a mobile device may be a value unique to mobile device 104 and may be generated using one or more rules or algorithms stored in memory 212, for example, included in MPA 404 program code 404. Feature 1204 of a mobile device may represent itself, for example, a numeric value, a hexadecimal value, a character string, etc.

[0123] The processing unit 204 may also be configured to generate a diversifier value 1208 using the characteristic feature 1204 of the mobile device. A diversifier value can be generated by combining the characteristic 1204 of the mobile device with the identifier 408 of the MPA instance 404, as well as a random value 1206. The random value 1206 can be a random or pseudo-random number generated by the processing unit 204. In some cases, a random value 1206 may be generated in accordance with one or more rules or algorithms stored in the memory 212. The combination of the feature 1204 of the mobile device, instance identifier 408 and the random value 1206 may also be performed using one or more rules or algorithms, such like those stored in MPA 406 program code 406. Using instance identifier 408 to generate a diversifier value can lead to a safe x Anenij data associated with an instance of 404 MPA, so that the numerous installation MPA 404 may not be able to perform treatment to data stored in other instances of 404 MPA.

[0124] The processing unit 204 can then generate an enhanced storage key 1210 by applying the encryption key 414 stored in the cryptographic application 410 to a diversifier value 1208. In some cases, an enhanced storage key 1210 may be generated by decrypting the diversifier value 1208 using the encryption key 414. In other cases, the enhanced storage key 1210 may be a value resulting from the encryption of the diversifier value 1208 using the encryption key 414. In some embodiments, an enhanced storage key 1210 may be generated by performing white box cryptography using an encryption key 414 and a diversifier value 1208.

[0125] If the enhanced storage key 1210 has been generated, the processing unit 204 may use the enhanced storage key 1210 to encrypt the local database 1210. The local database 1210 may consist, for example, of a card database 208, one or more payment profiles 302, a portion of memory 212, or another suitable data source. In some cases, local database 1210 may be part of another database on mobile device 104, such as card database 208. For example, the card database 208 may include many local databases 1212, such as a separate local database 1212 for each instance of the MPA 404 for storing payment profiles 302 associated with it. The resulting encrypted local database 1214 can thus safely store data that is not available to any other application program, internal or external to mobile device 104, except for a specific instance of MPA 404, which includes instance identifier 408. Therefore, the encrypted local database 1214 may be ideal for storing payment credentials 304, one-time keys 306, and other account data and can provide secure storage of sensitive account information without the use of security features.

[0127] In some embodiments, the storage key may also be used by transaction management server 102 to provide encrypted data to mobile device 104 for storage in an encrypted local database 1214. For example, the transmitting unit 206 of the mobile device 104 may transmit the generated random value 1206 to the transaction management server 102. In some cases, instance identifier 408 may also be transmitted to the transaction management server 102, or the transaction management server 102 may have it in advance, for example, during registration of the MPA 404. The transaction management server 102 may then generate the advanced storage key 1210 itself, encrypt the data to be provided mobile device 104, such as payment credentials 304, one-time keys 306, etc., using the enhanced storage key 1210, and then transmit the encrypted data to m abundant device 104. Mobile device 104 may then store already encrypted data in an encrypted local database 1214.

The first example method for generating payment credentials in a payment transaction

[0127] FIG. 13 illustrates a method 1300 for generating payment credentials in a payment transaction, comprising using two cryptograms of an application to securely use payment credentials in a mobile device 104 without a security element.

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

[0129] At step 1306, the first session key (eg, the first session key 308) can be identified by a processing device (eg, processing unit 204). At 1308, a second session key (eg, second session key 310) may be generated by the processing device 204 based on at least the stored one-time key 306 and the received PIN.

[0130] At step 1310, the first cryptogram of the application may be generated by the processing device 204 based on at least the first session key 308. At step 1312, the second cryptogram of the application may be generated by the processing device 204 based on at least the second session key 310.

[0131] At step 1314, at least the first cryptogram of the application and the second cryptogram of the application can be transmitted by a transmitting device (eg, transmitting unit 206) for use in a payment transaction. In some embodiments, the first cryptogram of the application and the second cryptogram of the application may be transmitted to a point of sale device (e.g., point of sale 110). In one embodiment, the method 1300 may further include storing in the memory 302 the master key of the card associated with the transaction account, the identification of the first session key 308 includes generating by the processing device 204 the first session key 308 based on at least the stored master key cards.

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

The second example method of generating payment credentials in a payment transaction

[0133] FIG. 14 illustrates a method 1400 for generating payment credentials in a payment transaction, including using the validation of two cryptograms of a payment credential application generated by the mobile device 104 without using a security element.

[0134] In step 1402, at least the card master key (for example, the first card master key 612) may be stored in a memory (for example, account profile 602) associated with the transaction account. At 1404, a first session key (e.g., a first session key 606) may be generated by a processing device (e.g., processing device 504) based on at least the stored master key 612 of the card. At 1406, a second session key (eg, second session key 608) may be generated by processing device 504.

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

[0136] In one embodiment, the method 1400 may further include storing in 602 a sequence number of the transaction account associated with the transaction account, the first session key being further based on the stored sequence number of the transaction account. In some embodiments, the method 1400 may also include storing a second card master key (e.g., a second card master key 614) associated with the transaction account in memory 602, the second session key 608 based on at least the second card master key 614 stored .

[0137] In one embodiment, method 1400 may further include: receiving, by a receiving device (eg, receiving unit 502), a first corresponding cryptogram of the application and a second corresponding cryptogram of the application; validation by the processing device (i) of the received first corresponding cryptogram of the application, based on the generated first cryptogram of the application, and (ii) the received second corresponding cryptogram of the application, based on the generated second cryptogram of the application; and transmitting, by the transmitting device 506, a validation result for use in a payment transaction. In another embodiment, the first respective cryptogram of the application and the second corresponding cryptogram of the application may be received from a point of sale device (e.g., point of sale 110). In yet another embodiment, the result of the validation may be transferred to a financial institution (eg, issuer 106) associated with a transaction account.

An example method for processing a data message

[0138] FIG. 15 illustrates a method 1500 for processing a data message, such as a remote notification message received by a remote notification service, including receiving and validating it with a mobile device 104 without using a security element.

[0139] In step 1502, at least the encryption key may be stored in memory (eg, in memory 212). In some embodiments, the memory 212 may be a memory without a security element in a mobile communication device (eg, mobile device 104). At 1504, a data message may be received by a receiver (e.g., receiver 202), wherein the data message may include at least an encrypted message and a message authentication code, where a message authentication code is generated using at least a portion of the encrypted message . In some embodiments, the data message may be a remote notification service message received by the remote notification service.

[0140] At 1506, a reference authentication code may be generated by a processing device (eg, processing unit 204) using at least a portion of the encrypted message included in the received data message. In one embodiment, memory 212 may further include one or more rules for generating an authentication code, and a reference authentication code may be generated based on applying the stored one or more rules for generating an authentication code to a portion of the encrypted message included in the received data message. At 1508, the received data message can be checked for authenticity by the processing device 204 based on a comparison of the message authentication code included in the received data message with the generated authentication reference code. In some embodiments, the memory may further include a reference counter, the received data message may further include a message counter, and the received data message may be further checked for validity by processing device 204 based on a comparison of the message counter included in the received message with data with a stored reference counter.

[0141] At step 1510, the encrypted message included in the data message can be decrypted by the processing device 204 using the stored encryption key to obtain the decrypted message. In one embodiment, the decrypted message may include at least one of: a digitized card profile (e.g., payment credentials 304) and a one-time key (e.g., one-time key 306) for use in a payment transaction. In some embodiments, the method 1500 may also include comparing the decrypted message data format device 204 based on one or more data formatting rules.

[0142] In one embodiment, method 1500 may further include transmitting, by a transmitting device (eg, transmitting unit 206), a notification of receipt in response to a received data message. In another embodiment, method 1500 may further include: performing one or more actions by processing device 204 based on the decrypted message; generating, by the processing device 204, a return message as a result of one or more actions performed or based on them; encrypting the generated return message by the processing device 204 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, in which the transmitted receipt notification includes an encrypted return message and a return authentication code. In yet another embodiment, the memory 212 may further include a return counter, and the transmitted receipt notification may further include a return counter.

[0143] In some embodiments, the method 1500 may also include filling insignificant information with the encrypted message processing device 204 included in the received data message using the insignificant information filling key, in which the portion of the encrypted message used to generate the authentication reference code represents an encrypted message filled with insignificant information. In another embodiment, the key filled insignificant information may be an encryption key. In yet another embodiment, the memory 212 may further include an algorithm for filling insignificant information with an authentication code, and filling in an encrypted message with insignificant information using an insignificant information key, may include filling in an encrypted message with insignificant information, based on applying the insignificant information key to an algorithm for filling in authentication code with insignificant information.

An exemplary method for generating an advanced storage key

[0144] FIG. 16 illustrates a method 600 for generating an advanced storage key for securely encrypting and storing local data in a mobile device 104 without using a security element.

[0145] In step 1602, at least device information (eg, device information 402) associated with a mobile communication device (eg, mobile device 104), a program code (eg, program code 406) associated with the first application program ( for example, by mobile payment application 404), and the program code (e.g., program code 412) associated with the second application program (e.g., cryptographic application 410) can be stored in the memory (e.g., memory 212) of the mobile communication device 104 in Orom, program code 406 associated with the first application program 404 includes at least an instance identifier (e.g., instance identifier 408) and program code 412 associated with the second application program 410 includes at least a first key (e.g. encryption key 414).

[0146] In some embodiments, device information 402 may include one or more unique identifiers associated with 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 white-box 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 other embodiments, the second application program 410 may be an executable function of the first application program 404.

[0147] In step 1604, a device characteristic (eg, a characteristic of mobile device 1204) associated with the mobile communication device 104 may be generated by a processing device (eg, processing unit 204) based on the stored device information 402 by executing program code 406 associated with the first application program 404. At 1606, a random value (eg, random value 1206) may be generated by the processing device 204 by executing program code 406 associated with the first application program 404. In some embodiments, the random value 1206 may be a random or pseudo-random number.

[0148] In step 1608, a diverifier value (eg, diverifier value 1208) may be generated by the processing device 204 based on at least the generated device characteristic 1204, the random value 1206 generated, and the instance identifier 408 included in the program code 406 associated with the first 404 application program. At step 1610, the generated diversifier value 1208 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 by executing the program code 412 associated with the second application program 410 to obtain a storage key (e.g. Advanced Storage Key 1210).

[0149] In some embodiments, the method 1600 may further include: storing, in a local database (eg, local database 1212), the mobile communications device 104 protected data; and encryption by the protected data processing device 204 stored in the local database 1212 using the storage key 1210. In one embodiment, the method 1600 may also include: storing in program memory 212 the program data associated with the first application program 404; and storing, in program data associated with the first application program 404, a random value 1206 generated.

[0150] In one embodiment, the method 1600 may also include: transmitting by the transmitting device (eg, transmitting unit 206) at least a random value 1206; receiving by the receiving device (for example, receiving unit 202) one or more encrypted parameters, in which each of one or more encrypted parameters is encrypted using a storage key 1210; and storing in a local database 1212 data of the mobile communication device 104, received one or more encrypted parameters. In another embodiment, the storage key 1210 may be transmitted to a third party (eg, transaction management server 102), and one or more encrypted parameters may be received from the third party 102. In still other embodiments, instance identifier 408 may also be transmitted by transmitting device 206.

Computer system architecture

[0151] FIG. 17 illustrates a computer system 1700 in which embodiments of the present invention, or portions thereof, may be implemented as computer readable code. For example, the transaction management server 102 and the mobile device 104 of FIG. 1 may be implemented in a computer system 1700 using hardware, software, firmware, long-term computer-readable media having instructions stored thereon, or combinations thereof, and can be implemented in one or more computer systems or other processing systems. The hardware, software, or any combination thereof may contain modules and components used to implement the methods of FIGS. 7, 8, 9, 10A, 10B, 11 and 13-16.

[0152] If programmable logic is used, such logic may be executed on a commercially available processing platform or on a special-purpose device. One of ordinary skill in the art may appreciate that embodiments of the disclosed subject matter may be practiced with various computer system configurations, including multi-core multiprocessor systems, minicomputers, large electronic computers, computers connected or grouped in clusters with distributed functions , as well as widespread or miniature computers that can be built into almost any device. For example, at least one processor device and memory may be used to implement the above-described embodiments.

[0153] A processor unit or device, as described herein, may be a single processor, multiple processors, or a combination thereof. Processor devices may have one or more processor cores. The terms “computer program environment”, “long-term computer-readable medium” and “computer-used medium”, as described herein, are used to generically refer to physical media such as a removable storage unit 1718, a removable storage unit 1722, and a hard disk installed in drive 1712 on the hard drive.

[0154] Various embodiments of the present invention are described based on this exemplary computer system 1700. After reading this description, it will become apparent to a person skilled in the art how to implement the present invention using other computer systems and / or computer architectures. Although operations can be described as a sequential process, some operations can actually be performed in parallel, simultaneously and / or in a distributed environment and with software code stored locally or remotely for access by single-processor or multiprocessor machines. In addition, in some embodiments, the order of operations may be reordered without departing from the spirit of the disclosed subject matter.

[0155] The processor device 1704 may be a special purpose or general purpose processor device. The processor device 1704 may be connected to a communications infrastructure 1706, such as a bus, message queue, network, multicore messaging circuit, etc. A network may be any network suitable for performing the functions described herein, and may include a local area network (LAN), wide area network (WAN), wireless network (eg, WiFi), a mobile network, satellite network, and the Internet , fiber optic communication line, coaxial cable, infrared frequency, radio frequency (RF), or any combination thereof. Other suitable network types and configurations are apparent to those skilled in the art. The computer system 1700 may also include main memory 1708 (eg, random access memory, read only memory, etc.) and may also include secondary memory 1710. Secondary memory 1710 may include a hard disk drive 1712 and removable storage 1714, such as a diskette drive, a magnetic tape drive, an optical disk drive, flash memory, etc.

[0156] Removable storage 1714 may be read from and / or written to removable storage unit 1718 in a well-known manner. The removable storage unit 1718 may include removable storage media that can be read and written by the removable drive 1714. For example, if the removable drive 1714 is a floppy disk drive or universal serial bus port, the removable storage unit 1718 may be a floppy disk or portable flash drive. drive respectively. In one embodiment, removable storage unit 1718 may be a long-term computer-readable recording medium.

[0157] In some embodiments, secondary memory 1710 may include alternative means for allowing computer programs or other instructions to be loaded into computer system 1700, such as a removable storage unit 1722 and interface 1720. Examples of such means may include a software cartridge and interface cartridge (for example, which are found in video game systems), a removable memory chip (for example, electrically erasable programmable read-only memory (EEPROM), programmable by read-only memory (PROM), etc.) and its associated slot, and other removable storage units 1722 and interfaces 1720, which is obvious to a person skilled in the art.

[0158] Data stored in a computer system 1700 (eg, main memory 1708 and / or secondary memory 1710) can be stored on suitable computer-readable media of any type, such as optical storage device (eg, compact disc, digital multifunction disk, a Blu-ray disc, etc.) or a tape drive (such as a hard disk drive). Data can be configured in any type of suitable database configuration, such as a relational database, an SQL type database (such as a structured query language), a distributed database, an object-oriented database, etc. Suitable configurations and types of storage devices are apparent to those skilled in the art.

[0159] The computer system 1700 may also include a communication interface 1724. Communication interface 1724 may be configured to transfer software and data between computer system 1700 and external devices. Exemplary communication interfaces 1724 may include a modem, a network interface (e.g., an Ethernet card), a communication port, a socket, and a PCMCIA card (International Association of Memory Card Manufacturers for Personal Computers), etc. The software and data carried through the communication interface 1724 may be in the form of signals, which may be electronic, electromagnetic, optical or other signals, which is obvious to a person skilled in the art. The signals can be transmitted through the communication path 1726, which can be configured to carry signals and can be implemented using wire, cable, fiber optics, telephone line, cell phone communication line, radio frequency communication line, etc.

[0160] The computer system 1700 may further include a display interface 1702. The display interface 1702 may be configured to transfer data between a computer system 1700 and an external display 1730. Exemplary display interfaces 1702 may include a high-resolution multimedia interface (HDMI), a digital video interface (DVI), a video graphics matrix (VGA), etc. . The display 1730 may be any suitable type of display for displaying data transmitted through the display interface 1702 of a computer system 1700, including a cathode ray tube (CRT) display, a liquid crystal display (LCD), a light emitting diode (LED) display, and a capacitive touch display such as a thin-matrix transistor (TFT) active matrix display, etc.

[0161] A computer program environment and a medium used by a computer may refer to a memory, such as a main memory 1708 and a secondary memory 1710, which may be a semiconductor memory (eg, dynamic random access memory (DRAM), etc.). These computer program products may constitute means for providing software to the computer system 1700. Computer programs (eg, computer control logic) may be stored in main memory 1708 and / or secondary memory 1710. Computer programs may also be received via communication interface 1724. Such computer programs, when executed, may enable the computer system 1700 to implement the present methods described herein. In particular, computer programs, when executed, may enable the processor device 1704 to implement the methods depicted in FIGS. 7, 8, 9, 10A, 10B, 11, and 13-16, as described herein. Therefore, such computer programs can be represented by controllers of a computer system 1700. Where the present invention is implemented using software, the software can be stored in a computer program product and downloaded to a computer system 1700 using a removable drive 1714, an interface 1720, and a drive 1712 on hard drive, or 1724 communication interface.

[0162] Methods compatible with the present invention provide, among other features, systems and methods for processing payment transactions using a mobile device without the use of a security element, including the transmission and validation of remote notification service messages and the secure storage of data using an advanced storage key. Although various exemplary embodiments of the disclosed system and method have been described above, it should be understood that they were presented for the purpose of example only and not limitation. They are not exhaustive and do not limit the invention to the exact form disclosed. Modifications and variations are possible in the light of the above ideas, or they can be obtained by practical use of the invention without departing from the breadth or scope.

Claims (77)

1. A method for generating payment credentials in a payment transaction, comprising: storing in memory at least a one-time key associated with the transaction account; receiving a personal identification number by the receiver; identification by the processing device of the first session key; generating, by the processing device, a second session key, based at least on the stored one-time key and the received personal identification number; generating, by the processing device, a first application cryptogram based on at least a first session key; generating, by the processing device, a second cryptogram of the application based on at least a second session key; and transmitting, by the transmitter, at least a first application cryptogram and a second application cryptogram for use in a payment transaction. 2. The method according to claim 1, additionally containing: storing in memory the main key of the card associated with the transaction account, and the identification of the first session key includes generating by the processing device the first session key, based at least on the stored master key of the card. 3. The method according to claim 1, additionally containing: saving in the memory of the transaction counter of the application, and the identification of the first session key includes generating by the processing device the first session key, based at least on the stored application transaction counter. 4. The method according to claim 1, additionally containing: validation by the processing device of the received personal identification number before generating the second session key. 5. The method according to claim 4, in which the processing device is configured to generate an invalid second session key, if the validation of the received personal identification number is unsuccessful. 6. The method according to claim 1, in which the first cryptogram of the application and the second cryptogram of the application are transmitted to the device of the outlet. 7. The method according to claim 1, in which the memory is a memory without a security element in a mobile communication device. 8. A method for generating payment credentials in a payment transaction, comprising: storing in memory at least the main key of the card associated with the transaction account; generating, by the processing device, the first session key, based at least on the stored master key of the card; generating the processing device of the second session key; generating, by the processing device, a first application cryptogram based on at least a first session key; generating, by the processing device, a second cryptogram of the application based on at least a second session key; and transmitting, by the transmitter, at least a first application cryptogram and a second application cryptogram for use in a payment transaction. 9. The method of claim 8, further comprising: storing in memory the sequence number of the transaction account associated with the transaction account, and the first session key is further based on the stored sequence number of the transaction account. 10. The method of claim 8, further comprising: storing in memory the second master key of the card associated with the transaction account, and the second session key is based at least on the stored second master key of the card. 11. The method of claim 8, further comprising: receiving the first corresponding cryptogram of the application and the second corresponding cryptogram of the application by the receiver; validation by the processing device (i) of the received first corresponding cryptogram of the application, based on the generated first cryptogram of the application, and (ii) the received second corresponding cryptogram of the application, based on the generated second cryptogram of the application; and Transmission by the transmitting device of a validation result for use in a payment transaction. 12. The method according to claim 11, in which the first corresponding cryptogram of the application and the second corresponding cryptogram of the application are received from the device of the outlet. 13. The method according to claim 11, in which the result of the verification is transmitted to the financial institution associated with the transaction account. 14. A system for generating payment credentials in a payment transaction, comprising: a memory configured to store at least a one-time key associated with the transaction account; a receiving device configured to receive a personal identification number; a processing device configured to: identify the first session key, generating a second session key, based at least on the stored one-time key and the received personal identification number, generating a first application cryptogram based on at least a first session key, and generating a second application cryptogram based on at least a second session key; and a transmitting device configured to transmit at least a first application cryptogram and a second application cryptogram for use in a payment transaction. 15. The system of clause 14, in which the memory is additionally configured to store the main key of the card associated with the transaction account, and the identification of the first session key includes generating by the processing device the first session key, based at least on the stored master key of the card. 16. The system of clause 14, in which the memory is further configured to store an application transaction counter, and the identification of the first session key includes generating by the processing device the first session key, based at least on the stored application transaction counter. 17. The system of claim 14, wherein the processing device is further configured to verify the received personal identification number before generating a second session key. 18. The system of claim 17, wherein the processing device is configured to generate an invalid second session key if the validity of the received personal identification number is unsuccessful. 19. The system of claim 14, in which the first cryptogram of the application and the second cryptogram of the application are transmitted to the device of the outlet. 20. The system of claim 14, wherein the memory is a memory without a security element in a mobile communication device. 21. A system for generating payment credentials in a payment transaction, comprising: a memory configured to store at least the main key of the card associated with the transaction account; processing device configured to generating the first session key, based at least on the stored master key of the card, generating a second session key, generating a first application cryptogram based on at least a first session key, and generating a second application cryptogram based on at least a second session key; and a transmitting device configured to transmit at least a first application cryptogram and a second application cryptogram for use in a payment transaction. 22. The system according to item 21, in which the memory is further configured to store the sequence number of the transaction account associated with the transaction account, and the first session key is further based on the stored sequence number of the transaction account. 23. The system according to item 21, in which the memory is further configured to store a second master key of the card associated with the transaction account, and the second session key is based at least on the stored second master key of the card. 24. The system of claim 21, further comprising: a receiver configured to receive a first corresponding cryptogram of the application and a second corresponding cryptogram of the application, wherein the processing device is further configured to validate (i) the received first corresponding cryptogram of the application, based on the generated first cryptogram of the application, and (ii) the received second corresponding cryptogram of the application, based on the generated second cryptogram of the application, and the transmitting device is further configured to transmit a validation result for use in a payment transaction. 25. The system according to paragraph 24, in which the first corresponding cryptogram of the application and the second corresponding cryptogram of the application are received from the device of the outlet. 26. The system according to paragraph 24, in which the result of the verification is transmitted to the financial institution associated with the transaction account.

Images