RU2653290C1 - Method and system for generation of improved storage key in mobile device without protective elements - Google Patents

Abstract

FIELD: network communication technology.

SUBSTANCE: invention relates to network communication technologies. Method comprises: storage, in the memory of the mobile device, of at least (i) information about the device associated with the mobile device, (ii) program code associated with the first program, the code including an instance identifier, and (iii) program code associated with the second program, the code including the first key; generation of a characteristic feature of the device associated with the mobile device, based on the device information, by executing the code associated with the first program; generation of a random value by executing the code associated with the first program; construction of the value of the diversifier based on the generated characteristic feature of the device, the generated random value and the instance identifier included in the code associated with the first program; and decryption of the constructed value of the diversifier using the first key stored in the code associated with the second program by executing the code associated with the second program to obtain the storage key.

EFFECT: technical result is improved data transmission security.

24 cl, 17 dwg

Description

RELATED APPLICATIONS

[0001] This application claims priority according to 35 U.S.C. 119 (e), previously filed of provisional patent applications No. 61/910819, filed December 2, 2013; 61/951842, filed March 12, 2014; 61 / 955,716 filed March 19, 2014; 61/979132, filed April 14, 2014; and 61/980784, filed April 17, 2014; 61/979122, filed April 14, 2014; 61/996665, filed May 14, 2014; and, in particular, provisional patent application No. 61/979113, filed April 14, 2014, each of which is incorporated here by reference in full.

FIELD OF THE INVENTION

[0002] The present invention relates to the generation of an advanced storage key for use in a mobile device without the need for a security element, and in particular, the use of multiple values to construct an advanced storage key in a mobile device without a security element for use in the secure storage of data in a mobile device .

BACKGROUND

[0003] The development of mobile and other communication technologies has created impressive opportunities, in particular, it provided the user of a mobile computing device with the ability to initiate and pay for payment transactions using his mobile device. One such approach to enabling such actions on a mobile device involves the use of Near Field Communication (NFC) technology to securely transfer payment details from a mobile device to a nearby contactless point of sale (POS) terminal. To this end, mobile phones equipped with a security element equipment, for example, security element (SE) chips, are used for secure storage of payment details. The security element is a feature that can be incorporated into some devices with NFC capabilities, which is a wear-resistant platform on which you can safely place 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 features on a mobile device, even if the mobile device is equipped with such a device. As a result, many buyers with mobile devices who have the necessary equipment to conduct contactless or other types of remote payment transactions may not be able to actually use these opportunities. Due to such difficulties, a technical solution is required that allows mobile computing devices to initiate and conduct payment transactions without the use of security elements.

[0005] Some methods and systems for conducting payment transactions using mobile devices without security features or without the use of security features in mobile devices equipped with them can be found in US Patent Application No. 13/827042, entitled Method 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 in its entirety by reference. Although such methods and systems may be suitable for conducting payment transactions via a mobile device without the use of a security element, many buyers, merchants and financial institutions may be wary of participating in such transactions because of the desire for even greater security.

[0006] As a result, technical solutions are required to provide even greater security for receiving and storing payment details in a mobile device that does not have a security element, as well as providing increased security when transferring payment details to a point of sale from a mobile device during a financial transaction. Increased security in these processes can lead to increased peace of mind for all involved entities, which can lead to increased use of mobile devices for contactless or remote payment transactions, which can provide customers with a large number of advantages over traditional payment methods.

SUMMARY OF THE INVENTION

[0007] The present disclosure provides a description of systems and methods for constructing advanced storage keys.

[0008] A method for constructing an improved storage key includes: storing, in memory of a mobile communication device, at least (i) device information associated with a mobile communication device, (ii) program code associated with a first application program, wherein the program code includes at least an instance identifier, and (iii) the program code associated with the second application program, the program code including the first key; generating, by the processing device, a characteristic feature of the device associated with the mobile communication device based on the stored information about the device by executing program code associated with the first application program; generating, by the processing device, a random value by executing program code associated with the first application program; constructing, by the processing device, the values of the diversifier based on at least the generated characteristic feature of the device, the generated random value and the identifier of the instance included in the program code associated with the first application program; and decryption, by the processing device, of the constructed value of the diversifier using the first key stored in the program code associated with the second application program, by executing the program code associated with the second application program to obtain the storage key.

[0009] A system for constructing an improved storage key includes a memory of a mobile communication device and a processing device. The memory of the mobile communication device is configured to store at least: information about the device associated with the mobile communication device; program code associated with the first application program, wherein the program code includes at least an instance identifier; and program code associated with the second application program, the program code including a first key. The processing device is configured to: generate a characteristic feature of the device associated with the mobile communication device based on the stored information about the device by executing program code associated with the first application program; generate a random value by executing program code associated with the first application program; build the value of the diversifier based on at least the generated characteristic feature of the device, the generated random value and the identifier of the instance included in the program code associated with the first application program; and decrypt the constructed value of the diversifier using the first key stored in the program code associated with the second application program by executing the program code associated with the second application program to obtain the storage key.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to better understand the scope of the present invention, reference should be made to the following detailed description of illustrative embodiments in conjunction with the accompanying drawings. The following figures are included in the drawings:

[0011] FIG. 1 is a block diagram illustrating a high-level architecture of a system for processing payment transactions with enhanced security in providing and storing payment details in accordance with illustrative embodiments.

[0012] FIG. 2 is a block diagram showing the mobile device shown in FIG. 1, for processing payment transactions without a security element and safely receiving and storing payment details in accordance with illustrative embodiments.

[0013] FIG. 3 is a block diagram showing a map database of the mobile device shown in FIG. 2, for storing payment details in accordance with illustrative embodiments.

[0014] FIG. 4 is a block diagram showing the memory of the mobile device shown in FIG. 2, for storing data used in generating advanced storage keys and generating cryptograms of applications in accordance with illustrative embodiments.

[0015] FIG. 5 is a block diagram illustrating the transaction management server shown in FIG. 1, for processing payment transactions by a mobile device without a security element in accordance with illustrative embodiments.

[0016] FIG. 6 is a block diagram showing a billing database of the processing server shown in FIG. 5, for storing payment details and account details in accordance with illustrative embodiments.

[0017] FIG. 7 is a flowchart illustrating a process for transmitting and verifying double cryptograms of payment transaction processing applications involving a mobile device without a security element, in accordance with illustrative embodiments.

[0018] FIG. 8 is a flowchart illustrating an alternative process for transmitting and verifying dual cryptograms of payment transaction processing applications involving a mobile device without a security element, in accordance with illustrative embodiments.

[0019] FIG. 9 is a flowchart illustrating a process for creating, transmitting, and certifying a remote notification service message or other data message provided to a mobile device without a security element, in accordance with illustrative embodiments.

[0020] FIG. 10A and 10B is a flowchart illustrating a process for creating, transmitting, and attesting a message returned by a mobile device without a security element in accordance with illustrative embodiments.

[0021] FIG. 11 is a flowchart illustrating a process for verifying a message of a remote notification service using the mobile device shown in FIG. 2, in accordance with illustrative embodiments.

[0022] FIG. 12 is a diagram illustrating the generation of an advanced storage key using the mobile device shown in FIG. 2, in accordance with illustrative embodiments.

[0023] FIG. 13 and 14 are flowcharts illustrating illustrative methods for generated payment details in a payment transaction in accordance with illustrative embodiments.

[0024] FIG. 15 is a flowchart illustrating an example method for receiving and processing a remote notification service message in accordance with illustrative embodiments.

[0025] FIG. 16 is a flowchart illustrating an illustrative method of constructing an improved storage key in accordance with illustrative embodiments.

[0026] FIG. 17 is a block diagram illustrating the architecture of a computer system in accordance with illustrative embodiments.

[0027] Further applications of the present invention are apparent from the following detailed description. It should be understood that a detailed description of illustrative embodiments is provided for purposes of illustration only and therefore is not intended to limit the scope of the invention.

DETAILED DESCRIPTION

Glossary of Terms

[0028] A payment network is a system or network used to transfer money through the use of cash substitutes. Payment networks can use a variety of protocols and procedures to process money transfers for various types of transactions. Transactions that can be carried out through the payment network can include purchases of products or services, credit purchases, debit transactions, fund transfers, account withdrawal transactions, etc. Payment networks can be arranged to carry out transactions through cash substitutes, which may include payment cards, letters of credit, checks, transaction accounts, etc. Examples of networks or systems configured to act as a payment networks include system controlled by MasterCard ^{®, VISA ®, Discover ®, American} Express ®, PayPal ® etc. As used herein, the term “payment network” can refer to both the payment network as a subject and the physical payment network, for example, hardware, equipment, and software containing the payment network.

[0029] A transaction account is a financial account that can be used to fund a transaction, for example, a current account, a savings account, a credit account, a virtual payment account, etc. A transaction account may be associated with a customer, which may be any suitable type of entity related to a payment account, which may include a person, family, company, corporation, government agency, etc. In some cases, a transaction account can be virtual, for example, an account managed by PayPal ^® , etc.

[0030] Payment card - card or data associated with a transaction account that may be provided to the merchant to fund a financial transaction through an appropriate transaction account. Payment cards may include credit cards, debit cards, payment cards, cards with a stored amount, prepaid cards, transport cards, virtual payment numbers, virtual card numbers, managed payment numbers, etc. A payment card may be a physical card that may be provided to a merchant, or may be data representing a corresponding transaction account (for example, stored in a communication device, for example, a smartphone or computer). For example, in some cases, data including a payment account number can be considered as a payment card for processing a transaction funded by the corresponding transaction account. In some cases, a check can be considered a payment card, when applicable.

[0031] A payment transaction is a transaction between two entities in which there is an exchange of money or other tangible benefit between the entities. A payment transaction can be a transfer of funds, for the purchase of goods or services, for paying a debt, or for any other exchange of material benefits that will be obvious to experts in this field of technology. In some cases, a payment transaction may refer to transactions funded by a payment card and / or payment account, for example, credit card transactions. Such payment transactions can be processed through the issuer, the payment network and the acquirer. The process for processing such a payment transaction may include at least one of authorization, grouping, clearing, settlement and funding. Authorization may include the acquisition of payment details by the buyer to the merchant, the submission of transaction details (for example, including payment details) from the merchant to their acquirer, and verification of the payment details by the issuer of the buyer’s payment account used to fund the transaction. Grouping may mean maintaining an authorized transaction in conjunction with other authorized transactions for distribution to the acquirer. Clearing may include sending grouped transactions from the acquirer to the payment network for processing. The settlement may include debiting the issuer by the payment network for transactions involving the beneficiaries of the issuer. In some cases, the issuer can pay the acquirer through a payment network. In other cases, the issuer may pay the acquirer directly. Funding may include payment to the merchant from the acquirer for payment transactions that have been cleared and settled. It will be apparent to those skilled in the art that the order and / or categorization of the steps discussed above is carried out in the processing order of a payment transaction.

[0032] Point of sale - a computing device or computing system configured to receive interaction with a user (eg, customer, employee, etc.) to enter transaction data, payment data, and / or other suitable data types for purchase and / or payment for goods and / or services. A store can be a physical device (for example, a cash register, kiosk, desktop computer, smartphone, tablet computer, etc.) in a physical place that a customer visits as part of a transaction, for example, in a regular store, or it can be virtual e-commerce environments, such as online retailers, that receive transmissions from customers over a network, such as the Internet. In cases where the outlet can be virtual, the computing device used by the user to initiate the transaction, or the computing system that receives data as a result of the transaction, can be considered as a point of sale, as far as applicable.

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

[0033] FIG. 1 illustrates a system 100 for processing payment transactions using a mobile device without the need for security features, which may include securely providing payment details to a mobile device, storing them securely, and using multiple application cryptograms to generate when verifying and processing a payment transaction .

[0034] The system 100 may include a transaction management server 102. The transaction management server 102, discussed in more detail below, may be one or more computing devices specifically programmed to perform the functions discussed here to provide payment details to the mobile device 104 using a securely transmitted remote notification message and to verify the payment details generated by the mobile device 104 during the payment transaction. Although it has been illustrated and discussed here that the transaction management server 102 performs various functions, it will be apparent to those skilled in the art that the transaction management server 102 may consist of multiple computing devices, servers, and / or computer networks configured to perform the functions discussed herein. Mobile device 104, discussed in more detail below, can be any type of mobile computing device suitable for the functions discussed herein, which may include a cell phone, smartphone, smartwatch, other wearable or integrated computing device, tablet computer, laptop computer, and etc. In some embodiments, implementation, mobile device 104 may not have a security element. In other embodiments, the mobile device 104 may include a security element, but such an element may not be used in conjunction with the methods and systems discussed herein, or may be used in conjunction with the methods and systems discussed herein, for example, to provide additional security.

[0035] The mobile device 104 may communicate with the transaction management server 102 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 guarantee increased security when transmitting data. The mobile device 104 may include a mobile payment application (MPA) to be executed by the mobile device 104 to perform the functions of the mobile device 104 discussed here. The MPA, discussed in more detail below, can be installed on the mobile device 104 and can be activated using an activation code, provided by the transaction management server 102 using methods and systems that would be apparent to those skilled in the art, so that the mobile device 104 and the control server 102 Transactions could safely transmit and receive transmissions on one or more communication channels using shared data.

[0036] The system 100 may also include an issuer 106. The issuer 106 may be a financial institution, for example, an issuing bank that issues a payment card or payment details to a customer 108 associated with a transaction account. Issuer 106 may provide payment details associated with the transaction account and / or payment card to 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, discussed in more detail below. Transaction management server 102 may also provide payment details to mobile device 104. The term “payment details” as used herein may refer to any data used by mobile device 104 and / or transaction management server 102 when transmitting and verifying payment information used in a payment transaction using here are methods and systems, including, but not limited to, payment details, payment details, single-use keys, session keys, application cryptograms main keys of cards, etc.

[0037] In some embodiments, payment details may be provided to the mobile device 104 through a remote notification service message. As discussed in more detail below, the Remote Notification Service (RNS) message can be a secure message that is transmitted to the mobile device 104 and then authenticated by the mobile device 104, which allows it to protect the data contained in it 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 therein. Then, the mobile device 104 may perform any necessary functions based on the data (for example, for example, by following the instructions included in the data), and, if applicable, may generate a return message for sending back to the transaction management server 102. In some cases, the return message may be authenticated by the transaction management server 102.

[0038] In some cases, at least message counters and an authentication code can be used to authenticate RNS messages in the mobile device 104 or to certify return messages on the transaction management server 102. The use of counters and authentication codes at the same time can ensure that only the intended mobile device 104 is able to authenticate and decrypt the data included in the RNS message. In addition, 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, is able to authenticate the RNS message, which further enhances security. In cases where the RNS message may include payment details, this can ensure that payment details are only available on the proper mobile device 104, and only if the MPA used to access them is a proper and authorized application.

[0039] The payment details provided to the mobile device 104 can be stored securely in storage in the mobile device 104, for example, a card database, discussed in more detail below. In some embodiments, the mobile device 104 may be configured to generate an advanced storage key for use in the secure storage of data, such as payment details, in a database or memory in mobile device 104. When generating an advanced storage key, as discussed in more detail below , you can use unique device information, unique MPA information, and randomly generated information to identify a secure storage key that can It can be used for secure storage of data in mobile device 104. As a result, payment details or other sensitive data can be safely stored in mobile device 104 without the use of a security element, which allows mobile device 104 to initiate and conduct payment transactions without the use of a security element, increasing accessibility for issuers 106 and buyers 108, while maintaining a high level of security.

[0040] After the payment details for the transaction account have been accepted, verified, and safely stored on the mobile device 104, the buyer 108 may bring the mobile device 104 to a merchant 110 at a merchant to conduct a payment transaction. Buyer 108 may select goods or services to purchase, may initiate a payment transaction to purchase from a merchant, and may use mobile device 104 to transfer payment details for use in funding a payment transaction. Transferring payment details to a point of sale 110 may include transmitting two or more cryptograms of applications. The use of two or more application cryptograms can provide a higher level of security for transactions processed using the methods and systems discussed here than available with traditional contactless and remote transactions, including transactions conducted using a mobile device 104 having a security element.

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

[0042] Cryptograms may be received by the point of sale 110 in the order of the payment transaction, for example, by means of near contactless communication. Application cryptograms may accompany additional payment information, for example, may be required in the context of any suitable type of payment transaction, for example, contactless transaction, remote transaction, secure remote payment transaction, magnetic stripe transaction and M / Chip EMV transaction, and may be transmitted to a point of sale 110 using any suitable method in accordance with it, as will be apparent to those skilled in the art. Cryptograms may be transmitted to acquirer 112, which may be a financial institution, for example, an acquirer bank associated with a merchant. Acquirer 112 may, for example, issue a merchant with a transaction account that is used to receive payment of funds from buyer 108 for a payment transaction. The acquirer 112 may provide cryptograms and additional transaction details to the payment network 114 using methods and systems that will be apparent to those skilled in the art. For example, transaction details and application cryptograms may be included in an authorization request submitted to the payment network 114 on payment rails.

[0043] In some embodiments, both application cryptograms may be included in a single transaction message. For example, mobile device 104 and / or outlet 110 may include both application cryptograms in traditional data fields of a traditional transaction message for transmitting both application cryptograms using existing payment systems and equipment. In some cases, the transaction management server 102 may be configured to use the data from track 2 to verify application cryptograms, for example, in a magnetic stripe based transaction. In such cases, if the transaction message includes the data of track 1, the transaction management server 102 may be configured to convert the data of track 1 to the data of track 2, which may also include converting the modified data of track 1 or track 2 to unmodified (e.g. , original, reconstructed, etc.) data from track 1 or track 2, respectively. By implementing these functions and by incorporating application cryptograms into traditional data fields, the transaction management server 102 is able to process and authenticate remote and contactless payment transactions using the mobile device 104 at a higher level of security, without the need for a security element on the mobile device 104, and without modification to traditional payment systems.

[0044] The payment network 114 may process the payment transaction using methods and systems that will be apparent to those skilled in the art. in processing order, payment network 114 may transmit application cryptograms to issuer 106 for verification. In some embodiments, the 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 can be transmitted to transaction management server 102 and can be verified by generating authentication cryptograms of applications using transaction management server 102, which can be generated using locally stored payment details. In other embodiments, the issuer 106 or the payment network 114 may request cryptograms of applications from the transaction management server 102, which can generate them and return the cryptograms to the issuer 106 or to the payment network 114 to verify the cryptograms created by the mobile device 104.

[0045] Since the transaction management server 102 has the payment details and other data used by the mobile device 104 to generate application cryptograms, the payment details created by the mobile device 104 to fund the payment transaction can be verified by comparing the cryptograms of the applications generated by the mobile device 104 and generated by the transaction management server 102. In some embodiments, the transaction management server 102 may be part of the payment network 114 or the issuer 106. In cases where the transaction management server 102 may be part of the payment network 114, authentication may be performed before contacting the issuer 106 as part of the traditional payment transaction processing (for example, for approval by the issuer 106 of funding the transaction using the buyer's transaction account 108).

[0046] By using multiple application cryptograms, it is possible to increase the security of payment transactions. In addition, in cases where each cryptogram can authenticate separate data, for example, instances where one cryptogram authenticates the mobile device 104 and the other authenticates both the mobile device 104 and the customer 108 (for example, via the customer’s PIN), it can also provide issuer 106 additional data and considerations to use when deciding whether to approve or reject a transaction. For example, if both cryptograms are incorrect (for example, the cryptograms generated by the mobile device 104 do not match 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 the buyer cannot be authenticated, but the mobile device is authenticated, since other available data may indicate that an authorized user, not buyer 108, is using mobile device 104 for a transaction.

[0047] As a result, the use of both cryptograms can provide valuable 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 higher security than traditional contactless or remote payment methods, which can lead to reduced fraud and increased acceptability for buyers 108, issuers 106 and merchants. In cases where the use of two or more cryptograms of applications is generated from payment details that have been safely provided using the RNS messaging methods and systems discussed here and are safely stored using advanced storage keys generated using the methods and systems discussed here, the general security of the system 100 can be significantly increased compared to traditional systems for contactless payments and transaction processing. As a result, system 100 can provide higher security in several aspects of data transmission, storage and processing compared to that provided in traditional contactless payment systems and for other types of remote payment transactions and payment transactions in general, which can use the methods and systems discussed here .

Mobile device

[0048] FIG. 2 shows an embodiment of a mobile device 104 of system 100. Those skilled in the art will appreciate that an embodiment of mobile device 104 of FIG. 2 is provided for illustrative purposes only and may not exhaust all possible configurations of a mobile device 104 suitable for performing the functions discussed herein. For example, the computer system 1700 shown in FIG. 17 and discussed in more detail below may be a suitable configuration for the mobile device 104.

[0049] 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 installed and executed on the mobile device 104, for example, a mobile payment application (MPA), discussed in more detail below. The receiving unit 202 may also receive Remote Notification Service (RNS) messages, for example, messages sent by the transaction management server 102, including RNS messages, which include payment details. The receiving unit 202 may also receive additional data suitable for implementing the traditional functions of the mobile device 104, for example, telephone, cellular, etc. In some cases, the mobile device 104 may include several receiving units 202, for example, individual receiving units 202, each of which is 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 transmissions over the mobile network.

[0050] 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 a mobile device 104 for receiving input from a customer 108, for example, a keyboard, mouse, push wheel, scroll wheel, touch screen, microphone, camera, receiver, etc. The input unit 214 may receive input from the customer 108, which may be processed by the processing unit 204.

[0051] The processing unit 204 may be configured to perform the functions of the mobile device 104 discussed herein. The processing unit 204 may execute program code stored in a mobile device, for example, for an MPA, and may be configured to perform several functions associated with each the application program, among other functions of the mobile device 104. The processing unit 204 may receive input from the buyer 108 via the input unit 214 and perform functions, respectively, for example, by performing ad programs, performing functions in programs, receiving data, transmitting data, displaying data, etc., which will be apparent to those skilled in the art. For example, processing unit 204 may be configured to authenticate RNS messages, generate advanced storage keys, and generate application cryptograms, as discussed in more detail below.

[0052] 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, for example, data transmitted to the display unit 210 for display by the processing unit 204. Display devices may include liquid crystal displays, LED displays, thin film transistor displays, touch screen displays, etc.

[0053] Mobile device 104 may also include a transmission unit 206. Transmission unit 206 may be configured to transmit data over one or more networks via one or more network protocols. Transmission unit 206 may send RNS response messages to transaction management server 102. Transmission unit 206 may also be configured to transmit cryptograms of applications and / or payment details, for example, a point of sale 110, for use in a payment transaction. The transmission unit 206 may be further configured to perform additional functions of the mobile device 104, which will be apparent to those skilled in the art, for example, traditional functions of a mobile communication device for performing cellular communication, etc. In some cases, the mobile device 104 may include several transmission units 206, which may be individually configured to communicate with one or more separate networks, for example, a transmission unit 206, configured to transmit payment details and payment cryptograms via NFC and another transmission unit 206, configured to transmit data over a mobile communication network.

[0054] Mobile device 104 may also include a map database 208. The card database 208, discussed 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 can store payment details related to the transaction account, for example, the transaction management server 102 provided to the mobile device 104 in a secure RNS message, and additional data that can be used to generate application cryptograms, as described in more detail below. In some cases, a database of 208 cards may be stored as part of a mobile payment application.

[0055] Mobile device 104 may further include memory 212. Memory 212, discussed in more detail below, may be configured to store data for mobile device 104 suitable for performing the functions of mobile device 104 discussed herein. For example, in memory 212 data suitable for generating advanced storage keys for encrypting additional data is stored in the mobile device 104, for example, a card database 208, as discussed in more detail below. The memory 212 can also be configured to store program code for application programs executed by processing unit 204, for example, 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 implementing the functions here, etc. The memory 212 can also store data suitable for the implementation of the traditional functions of the mobile device 104, for example, rules and / or algorithms for implementing cellular communications through a mobile network. Additional data stored in memory 212 will be apparent to those skilled in the art.

Mobile Device Card Database

[0056] FIG. 3 shows an embodiment of a card database 208 of a mobile device 104 for storing payment details and other data related to transaction accounts for use in funding payment transactions conducted using the mobile device 108.

[0057] The card database 208 may include one or more of the payment profiles 302 of 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 fund a payment transaction, and may include at least payment details 304, one or more reusable keys 306, a first session key 308, a second session key 310 and application transaction counter 312.

[0058] Payment details 304 may include data associated with the corresponding transaction account, which is used to identify and verify the payment network 114 and / or issuer 106 when processing the payment transaction using the corresponding transaction account. Payment details 304 may include, for example, transaction account number, security code, expiration date, cardholder name, authorized user name, tracking data, card design description data, digital meters, bitmaps, etc.

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

[0060] 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 cryptograms of applications transmitted to the point of sale 110 in the payment transaction order using the mobile device 104. In some embodiments, the first session key 308 can be used to generate the first cryptogram of the application by processing unit 204, for example, using program code, rules or algorithms stored in mobile device memory 212 Property 104. A second session key 310 may be used to generate a second cryptogram of the application.

[0061] In some embodiments, a second session key 310 may be generated by processing unit 204. In such an embodiment, the second session key 310 may be generated using the reusable key 306 and user authentication data, such as a PIN provided by the customer 108 (for example, via an 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 rejected as part of the payment transaction process. Therefore, the second cryptogram of the application can, being generated from the second session key 310, which is generated using the reusable key 306 and the buyer's PIN, serve to authenticate both the mobile device 104 and the buyer 108.

[0062] The personal identification number (PIN) may be a number provided by the buyer 108 (for example, during the registration of the MPA on the mobile device 104 or the registration of the transaction account by the issuer 106 and / or the transaction management server 102), which can be used to authenticate the buyer 108 . When conducting a payment transaction, the buyer 108 or other user of the mobile device 104 may provide a PIN through the block 214 input. In some embodiments, if the provided PIN is incorrect (for example, does not match the PIN provided by the buyer 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 be incorrect, which will lead to a failure to certify the second cryptogram of the application by the transaction management server 102, the issuer 106 and / or the payment network 114, which may provide the issuer 106 with the opportunity to reject the transaction accordingly, or still approve the transaction.

Mobile device memory

[0063] FIG. 4 shows 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 a mobile device 104 and for conducting payment transactions using a mobile device 104. In an illustrative embodiment, the memory 212 may not be a security element .

[0064] 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 an address of the medium access control level , reference number, serial number, identification number, etc. Additional information, which may be regarded as information 402 about the device of the mobile device 104, will be apparent to those skilled in the art.

[0065] 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, for example, receiving and storing payment details, verifying RNS messages, and generating application cryptograms 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, as will be apparent to those skilled in the art.

[0066] 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 directs the processing unit 204 and other components of the mobile device 104 to implement the MPA 404 functions discussed herein. For example, program code 406 may include code suitable for generating application cryptograms, RNS message authentication, etc. 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 will be apparent to those skilled in the art.

[0067] 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 protect data in mobile device 104, such as a card database 208. Thanks to an instance identifier 408 unique to MPA 404, multiple MPA 404s can be installed on mobile device 104, and no MPA 404 is able to access data safely stored by any other MPA 404, which ensures that payment profiles 302 for specific transaction accounts are not available to 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.

[0068] As discussed 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 MPA program code 406 404, and an instance identifier 408 stored in the MPA 404. The value of the diversifier can be used by cryptographic application 410, also stored in memory 212. Cryptographic application 410 may be an application program configured to perform ticipate cryptography on the principle of white-box and / or any other suitable cryptographic function that will be obvious to those skilled in the art.

[0069] 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 to enable the processing unit 204 and other components of the mobile device 104 to perform the cryptographic functions of the cryptographic application 410 discussed herein. Functions may include self 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.

[0070] The cryptographic application 410 may 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 a database of cards 208 and / or any other suitable storage on the mobile device 104, for example, data stored in the MPA 404. In some embodiments, the cryptographic application 410 may be included in the MPA 404. The enhanced storage key may be stored in cryptographic application 410 or MPA 404, or, in some cases, MPA 404 and, if necessary, cryptographic application 410 can be regenerated.

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

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

Transaction management server

[0073] FIG. 5 shows an embodiment of the transaction management server 102 of the system 100. It will be apparent to those skilled in the art that the embodiment of the transaction management server 102 of FIG. 5 is provided for illustrative purposes only and may not exhaust all possible configurations of a transaction management server 102 suitable for performing the functions discussed herein. For example, the computer system 1700 shown in FIG. 17 and discussed in more detail below may be a suitable configuration of a transaction management server 102.

[0074] The transaction management server 102 may include a receiving unit 502. The receiving unit 502 may be configured to receive data over one or more networks via one or more network protocols. The receiving unit 502 may receive data from the mobile device 104, for example, receive or return messages, confirmation messages, transaction notifications, etc., payment network 114, 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 verifying payment details in a payment transaction. Reception unit 502 may also receive transaction account data, for example, from issuer 106, for use in generating payment details for provision to mobile device 104.

[0075] 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 discussed herein, as will be apparent to those skilled in the art. Thus, the processing unit 504 can be configured to generate and encrypt RNS messages and the data included therein, to certify return messages from the mobile device 104, to generate payment details, to generate application cryptograms, to verify application cryptograms, etc., as in more detail discussed below.

[0076] The transaction management server 102 may further include a transfer unit 506. Transmission unit 506 may be configured to transmit data over one or more networks via one or more network protocols. Transmission unit 506 may transmit RNS messages, payment details, application cryptograms, identity notifications, and other data that will be apparent to those skilled in the art. Transmission unit 506 may be configured to transmit data to mobile device 104, for example, via a mobile communication network or the Internet, a payment network 114, an issuer 106, and any other suitable entity.

[0077] The transaction management server 102 may also include an account database 508. The account database 508, discussed in more detail below, can be configured to store account information for multiple transaction accounts. Account information may include data and keys used to generate cryptograms of applications used to verify payment details received during payment transactions carried out using mobile device 104. Account database 508 may also be configured to save transaction data for payment transactions carried out with the participation of the mobile device 104, and other data, for example, data associated with the buyer 108 or other authorized users of the corresponding an invoice account.

[0078] 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 disclosed herein. For example, memory 510 may store rules or algorithms for certifying application cryptograms, rules or algorithms for generating authentication 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 will be apparent to those skilled in the art.

Transaction Management Server Account Database

[0079] FIG. 6 illustrates an embodiment of an account database 508 of a transaction management server 102 for storing data associated with transaction accounts for use in verifying payment details and other transaction data provided when conducting payment transactions including a mobile device 104.

[0080] The account database 508 may include several account profiles 602 shown in FIG. 6 as account profiles 602a, 602b, and 602c. Each account profile 602 may include one or more reusable 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.

[0081] Each account profile 602 may correspond to a payment profile 302 provided to the mobile device 104. Thus, the reusable keys 604 stored in the account profile 602 may correspond to the reusable keys 306 stored in the corresponding payment profile 302 associated with the same transaction account. The data may be similar, whereby 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 accurate and not corrupted, which may allow the payment details provided by the mobile device 104 to be verified.

[0082] In some embodiments, the account profile 602 may include a personal identification number (PIN) that corresponds to the 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 message, for example, a receive message provided by the mobile device 104, discussed in more detail below. In other embodiments, a card master key may be used instead of a PIN, for example, 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 card master 614, which corresponds to the second session key 310 generated by the mobile device 104 using the reusable key 306 and PIN 314 In a number of cases, the second session key 608 may also be based on a corresponding reusable key 604. In such embodiments, the algorithms for generating session keys and / or application cryptograms can ensure that the cryptograms generated by the mobile device 104 and the transaction management server 102 are consistent based on the data used on them.

[0083] The first session key 606 may 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 may 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 of the session keys and / or cryptograms of the applications. Application transaction counter 610 may be a value corresponding to an ongoing payment transaction that is incremented or otherwise changes 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 a valid MPA 404 can have a valid application transaction counter 312 to generate valid session keys and / or cryptogram applications. Additional methods may be used to further enhance the security of the session key and / or generate cryptograms of the application, for example unpredictable numbers and other methods that will be apparent to those skilled in the art.

Processing payment transactions using a mobile device

[0084] FIG. 7 shows a process for processing payment transactions conducted using a mobile device 104 without a security element and using the generation and authentication of two or more cryptograms of applications.

[0085] At step 702, the transaction management server 102 may provide (for example, via the transfer unit 506) payment details 304 and other account data to the mobile device 104, for example, via an RNS message, discussed in more detail below. At step 704, the receiving unit 202 of the mobile device 104 may receive payment details 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 database 208. Account data may include payment details 304, one or more reusable keys 308 and any other suitable data, for example, one or more of the session keys 308 and 310.

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

[0087] After generating the application cryptograms, they, together with the payment details 304, can be transmitted to the issuer 106 through the outlet 110, the acquirer 112 and the payment network 114. Payment details 304 and application cryptograms can be received by the issuer 106 at step 710. At step 712, the transmission unit 206 of the mobile device 104 may transmit the 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. A 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, a transaction notice may include identification information.

[0088] At 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 application cryptograms 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 of the application and / or session key cryptograms may be further based on reusable keys 604, application transaction counter 610, or any other suitable data.

[0089] In step 718, the transfer 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 application cryptograms provided by the mobile device 104 together with the payment details 304 . The authentication of the application cryptograms may include comparing the cryptograms provided by the mobile device 104 with the application cryptograms generated and provided by the transaction management server 102. After the certification is completed, at step 722, the issuer 106 may accordingly process the transaction. Transaction processing may include approving a payment transaction, for example, if one or both of the cryptograms are authenticated, or rejecting the payment transaction, for example, if it is determined that one or both of the cryptograms is invalid.

[0090] At step 724, the transaction notice may be transmitted by the issuer 106 or another entity (eg, payment network 114, acquirer 112, etc.) in the processing order of the payment transaction. A transaction notification may be transmitted to the transaction management server 102 and received by the receiving unit 502, at step 726. A transaction notification may also be received by the receiving unit 202 of the mobile device 104, at step 728. The transaction notification may indicate 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, can perform one or more functions as a result of receiving the 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.

[0091] FIG. 8 shows an alternative payment transaction processing process using mobile device 104.

[0092] At step 802, payment details 304 and other account data may be transmitted to the mobile device 104 by the transmission unit 506 of the transaction management server 102. At step 804, the receiving unit 202 of the mobile device 104 may receive payment details 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 application cryptograms, as discussed above , and can transmit cryptograms, payment details 304, and other suitable data to the issuer 106 (for example, through a point of sale 110).

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

[0094] In step 814, the receiving unit 502 of the transaction management server 102 may receive a cryptogram request. At step 816, the processing unit 504 of the transaction management server 102 may generate two application cryptograms to be used for authentication, as discussed 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 with a processing unit 504 using two newly generated application cryptograms. Identification cryptograms or the verification result in applicable embodiments may be transmitted by the transmission unit 506 to the issuer 106. At step 818, the issuer 106 may receive the authentication cryptograms and / or the verification result.

[0095] At step 820, the issuer 106 may certify 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 reports the authentication result to the issuer 106, step 820 may include identifying the authentication result of each of the two application cryptograms. At step 822, the issuer 106 may process the payment transaction, respectively, based on the result of the certificate. At step 824, transaction notifications received by the respective reception units 502 and 202 at steps 826 and 828 can be transmitted, respectively, to the transaction management server 102 and the mobile device 104.

Remote Alert and Messaging Service

[0096] FIG. 9 shows a process for transmitting and certifying 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 by a remote notification service, such as one that uses a mobile network associated with mobile device 104. RNS messages can be used to provide payment details 304 and other account data to mobile device 104, for example, account data used in processing the board transactions, as discussed above, and other information that can be used to establish a secure connection between the mobile device 104 and the transaction management server 102.

[0097] In step 902, the processing unit 504 of the transaction management server 102 may generate a message. In cases where mutual authentication is established using the mobile device 104, the message may include information suitable for establishing mutual authentication, for example, a session identifier. In other cases, for example, when mutual authentication is established between the transaction management server 102 and the mobile device 104 using, as shown in FIG. 9 and the process discussed here, the generated message may include payment details 304 and account data, may include one or more instructions to be executed by MPA 404 of mobile device 104 (e.g., deleting one-time keys 306 or payment details 304, etc. e.) may be a notice to be presented to the customer 108 (e.g., account balance, payment notices, etc.), or may include other suitable data.

[0098] At step 904, the processing unit 504 may encrypt the generated message. The message can be encrypted using the private key of the private / public key pair, and the mobile device 104 may have a corresponding public key. In some cases, the message may be encrypted using an encryption key associated with a mobile device 104 or MPA 404, for example, an encryption key 414. At 906, 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 obfuscation methods, for example, padding. In some embodiments, a message authentication code may be generated using an encryption key.

[0099] In step 908, the transmission unit 506 of the transaction management server 102 may transmit the combined data message to the mobile device 104. In embodiments where mutual authentication can be performed, the combined 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, for example, generated using methods of the known MPA 404 to verify it. In some cases, for example, when mutual authentication has already been performed, the combined data message may also include a message counter.

[0100] 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 authentication code will correspond to the message authentication code if the message authentication code generated by a trusted source (e.g., transaction management server 102). In embodiments where the message authentication code may be generated using the encryption key, processing unit 204 may generate an authentication reference code using the encryption key 414 stored in memory 212 or another suitable encryption key.

[0101] At step 914, the processing unit 204 can verify the message authentication code included in the received combined data message by comparing it with the generated authentication reference code. If the message counter and message authentication code are authenticated, then the combined data message can be defined as trusted (eg, genuine) upon receipt 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 message identifier by generating a message identifier using a process known to MPA 404 to generate and compare it. In embodiments where the combined data message may include a message counter, processing unit 204 can verify the message counter included in the received combined data message using a reference counter stored in the mobile device 104, for example, in the MPA 404 or in the payment profile 502 .

[0102] At step 916, the processing unit 204 may decrypt the encrypted message included in the received combined data message. The encrypted message can be decrypted using a key, for example, stored in memory 212 (for example, in cryptographic application 410 or MPA 404) or stored in a local encrypted database (for example, 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 actions necessary for mutual authentication using the mobile device 104. In cases where mutual authentication has already been performed, the message may include other information suitable for the implementation disclosed here functions, for example, payment details 404, reusable keys 406, program instructions for MPA 404, etc.

[0103] In some embodiments, the mobile device 104 may be configured to (for example, via the MPA 404) generate and transmit a return message to the transaction management server 102. In some cases, the return message may include data generated in response to actions performed as prescribed in the decrypted message, as discussed above. For example, a return message may indicate the actual receipt and storage of payment details 304 or reusable keys 306. In other cases, the return message may be a notification of receipt and certification of the combined data message. In cases where mutual authentication is first performed, the return message may include a session identifier used to perform mutual authentication.

[0104] FIG. 10A and 10B show a process for generating and transmitting a return message by a mobile device 104 and confirming it with a transaction management server 102.

[0105] 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 taken as indicated in the decrypted combined data message received from the transaction management server 102. For example, a receipt message may include a notification of successful receipt and storage of payment details 304. At step 1004, the processing unit 204 may increment the receipt counter. The receive counter may be a counter indicating the number of receive messages transmitted to the transaction management server 102. The receive counter may be stored in memory 212, such as in the MPA 404, or in a database encrypted using an advanced storage key. Those skilled in the art will appreciate that step 1004 can be an optional step and can only be used when a counter is used to authenticate a data message.

[0106] At 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 it 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 private key in a key pair, the corresponding public key being stored on the transaction management server 102. At step 1008, the processing unit 204 may generate a receipt authentication code based on an encrypted receive message. In some embodiments, the receipt authentication code may be generated using the same rules, algorithms, and / or processes that are used to generate the authentication authentication code illustrated in step 912 discussed above with reference to FIG. 9.

[0107] In step 1010, the transmission 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 network, such as a cellular network, associated with mobile device 104.

[0108] At 1014, the processing unit 504 of the transaction management server 102 may increment a confirmation counter. The confirmation counter may indicate the number of messages received from the mobile device 104 used to authenticate messages received from the mobile device 104. The confirmation counter may be stored in memory 510 of the transaction management server 102 or other suitable data storage. 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 associated with the corresponding transaction account. Those skilled in the art will appreciate that step 1014 may be an optional step, and may not be carried out in cases where the counter may not be used to authenticate return messages.

[0109] At 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 that are used to generate the message authentication code. At 1018, the processing unit 504 can certify the receipt counter included in the receipt notification message by comparing it with the confirmation counter. At step 1020, the processing unit 504 can authenticate the receipt authentication code by comparing it with the message authentication code to ensure that the message comes from an authorized mobile device 104.

[0110] After verifying the counter (for example, if applicable) and the authentication code, 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 can be decrypted to receive a receive message generated by the mobile device 104. At step 1024, the processing unit 504 may take any necessary action 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 the reusable keys 306, the processing unit 204 may activate the corresponding reusable keys 604 in the corresponding account profile 602.

Data Message Identity

[0111] FIG. 11 shows a process 1100 for verifying data messages received by a mobile device 104 from a transaction management server 102.

[0112] 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 their use and application in local storage, for example, in memory 212 or a locally encrypted storage, encrypted using an advanced key storage. 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 shown in FIG. 9 and discussed above. The data message may include at least a message counter, a message authentication code, and an encrypted message.

[0113] 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 increased using an algorithm, such that the reference counter may not be increased using sequential numbers, but by an algorithm known to the mobile device 104 (e.g., via the MPA 404) and transaction management server 102.

[0114] At step 1108, the processing unit 204 may certify a message counter included in the received data message. The identity of the message counter may include comparing the message counter with the value of the reference counter after increasing. A bad credential may indicate that the data message source is not a transaction management server 102, or is not trusted anyway. If the authentication fails, then, at step 1110, the processing unit 204 may perform one or more appropriate actions associated with the failure to receive and / or verify the data message. For example, processing unit 204 may reject the data message, may notify the transaction management server 102, may block the corresponding payment profile 302, or perform other actions that will be apparent to those skilled in the art.

[0115] If the authentication of the message counter is successful, then process 1100 may proceed to step 1112 where the encrypted message may be populated. Filling out the encrypted message may include adding values to the encrypted message or related data. Filling can be used to enhance the security of the message authentication process, as the mobile device 104 and the transaction management server 102 may need to perform another function known to both of them that an unauthorized subject will have to duplicate in order to successfully transmit or receive a data message without authorization. It will be apparent to those skilled in the art that step 1112 may be an optional step. In some embodiments, step 1112 may be applied in a number of cases to process 1110. For example, an encrypted message may be populated with certain increments of the reference counter.

[0116] At step 1114, the processing unit 204 may generate a reference authentication code. An authentication reference code may be generated based on an encrypted message (eg, populated, if applicable) using one or more rules or algorithms, for example, stored in step 1102. In some embodiments, the authentication reference code may be a key or may be a value generated by applying the key to an encrypted message. At step 1116, the processing unit 204 may certify the message authentication code received in the RNS message. The authentication 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 comes from an authorized source (e.g., transaction management server 102).

[0117] If the authentication of the message authentication code fails, process 1100 may proceed to step 1110 where failure processing is performed. If the authentication of the message authentication code is successful, then, at step 1118, the encrypted message included in the received data message can be decrypted by the processing unit 204. The message can be decrypted using one or more encryption / decryption keys, rules and / or algorithms, for example, 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 decrypt the encrypted message . At step 1120, the processing unit 204 may perform one or more appropriate actions based on the contents of the decrypted message. For example, if the decrypted message includes reusable keys 306, the reusable keys 306 can be stored in the appropriate payment profile 302 of the card database 208, which can thus be encrypted using an advanced storage key.

Advanced Storage Key

[0118] 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, for example, payment profiles 302 and other data, providing secure storage and access in a mobile device 104 without the use of security features.

[0119] Device information 402 stored in memory 212 of 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 a mobile device 104. In other cases, one or more pieces of device information 1202 may not be unique to mobile device 104 (e.g., model number), but three pieces of device information 1202 taken together may be unique to mobile device 104 (e.g., a unique combination). Fragments of information about the device 1202 may be data that will not change over the life of the mobile device 104.

[0120] 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. The characteristic of the mobile device 1204 may be a value unique to the mobile device 104, and may be generated using one or more rules or algorithms stored in the memory 212, for example, included in the MPA 404 program code 404. The characteristic of the mobile device 1204 may be e.g. numerical value, hexadecimal value, character string, etc.

[0121] The processing unit 204 may also be configured to generate a diversifier value 1208 using the characteristic 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 characteristic 1204 of the mobile device, instance identifier 408 and the random value 1206 may also be carried out using one or more rules or algorithms, for example, stored in program code 406 MPA 404. Using the identifier 408 of the instance to generate the value of the diversifier can enable secure storage of data associated with zemplyarom MPA 404, thereby, set multiple copies of MPA 404 may not be able to access the data stored in other examples of the MPA 404.

[0122] Then, the processing unit 204 can generate an enhanced storage key 1210 by applying the encryption key 414 stored in the cryptographic application 410 to the diversifier value 1208. In some cases, the 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 the value obtained by encrypting 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.

[0123] After generating the enhanced storage key 1210, 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, part of the memory 212 or another suitable data source. In some cases, the local database 1210 may be part of another database on the mobile device 104, for example, a map database 208. For example, the map database 208 may include several local databases 1212, for example, a separate local database 1212 for each instance of MPA 404 to store associated payment profiles 302. Thus, data obtained that is inaccessible to any other application program internal or external to mobile device 104 can be safely stored in the obtained encrypted local database 1214, except for a specific instance of MPA 404, which includes instance identifier 408. Accordingly, the encrypted local database 1214 may be ideally suited for storing payment details 304, reusable keys 306 and other account data, and can provide secure storage of confidential account information without the use of security elements.

[0124] 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, transmission unit 206 of mobile device 104 may transmit the generated random value 1206 to server 102 transaction management. In some cases, instance identifier 408 may also be transmitted to the transaction management server 102, or may be previously stored on the transaction management server 102, for example during registration of the MPA 404. Then, the transaction management server 102 may generate the advanced storage key 1210 itself, encrypt the data provided to the mobile device 104, for example, payment details 304, reusable keys 306, etc., using the enhanced storage key 1210, and then transmit the encrypted data to the mobile device 104. Then, the mobile device 104 may store the already encrypted data in the encrypted local database 1214.

The first illustrative method of generating payment details in a payment transaction

[0125] FIG. 13 shows a method 1300 for generating payment details in a payment transaction, including the use of two application cryptograms for the safe use of payment details in a mobile device 104 without a security element.

[0126] In step 1302, at least the reusable key (eg, the reusable 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 of insecure items in a mobile communication device (eg, mobile device 104). At 1304, a personal identification number (PIN) may be received by the receiving device (for example, the receiving unit 202 and / or the input unit 214).

[0127] 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 step 1308, a second session key (eg, a second session key 310) may be generated by the processing device 204 based on at least the stored reusable key 306 and the received PIN.

[0128] At step 1310, the first cryptogram of the application can 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 can be generated by the processing device 204 based on at least the second session key 310 .

[0129] In 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, transmission 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, method 1300 may further include storing, in memory 302, the master card key associated with the transaction account, the identification of the first session key 308 including generating, by the processing device 204, the first session key 308 based on at least the saved master key of the card.

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

The second illustrative method of generating payment details in a payment transaction

[0131] FIG. 14 shows a method 1400 for generating payment details in a payment transaction, including the use of two application cryptograms for verifying payment details generated by the mobile device 104 without using a security element.

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

[0133] 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 the at least 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, transfer unit 506) for use in a payment transaction.

[0134] In one embodiment, method 1400 may further include storing, in memory 602, the 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, method 1400 may also include storing, in memory 602, a second card master key (e.g., a second card master key 614) associated with the transaction account, the second session key 608 based on at least the stored The second main key is 614 cards.

[0135] In one embodiment, the method 1400 may further include: receiving, by a receiving device (eg, receiving unit 502), a first corresponding application cryptogram and a second corresponding application cryptogram; certifying, by the processing device, (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 transmitting, by the transmitting device 506, an identity result for use in a payment transaction. In a further 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 another additional embodiment, the result of the certificate may be transferred to a financial institution (eg, issuer 106) associated with a transaction account.

An illustrative way to process a data message

[0136] FIG. 15 shows a method 1500 for processing a data message, for example, a remote notification message received by a remote notification service, including receiving and attesting it by a mobile device 104 without using a security element.

[0137] 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 of insecure items in a mobile communication device (eg, mobile device 104). At 1504, a data message may be received by a receiving device (eg, a receiving unit 202), 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 encrypted message. In some embodiments, the data message may be a remote notification service message received by the remote notification service.

[0138] In step 1506, an authentication reference 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 authentication code generation rules, and an authentication reference code may be generated based on applying the stored one or more authentication code generation rules to a portion of the encrypted message included in the received data message. At step 1508, the received data message can be verified by the processing device 204 based on a check 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 further be verified by the processing device 204 based on a message counter check included in the received data message with respect to the stored reference counter .

[0139] 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 receive the decrypted message. In one embodiment, the decrypted message may include at least one of: a digitized card profile (e.g., payment details 304) and a reusable key (e.g., reusable key 306) for use in a payment transaction. In some embodiments, the method 1500 may also include verifying, by the processing device 204, the data format of the decrypted message based on one or more data formatting rules.

[0140] In one embodiment, method 1500 may further include transmitting, by a transmission device (eg, transmission unit 206), receipt notifications in response to a received data message. In a further embodiment, method 1500 may further include: performing, by the processing device 204, one or more actions based on the decrypted message; generating, by the processing device 204, a return message as a result of or based on one or more actions being performed; encryption, by the processing device 204, of the generated return message using the stored encryption key to receive the encrypted return message; and generating, by the processing device 204, a return authentication code using at least a portion of the encrypted return message, the transmitted receipt notification including an encrypted return message and a return authentication code. In a further embodiment, the memory 212 may further include a return counter, and the transmitted receipt notification may further include a return counter.

[0141] In some embodiments, the method 1500 may also include filling, with processing device 204, an encrypted message included in the received data message using a fill key, the portion of the encrypted message used to generate the authentication authentication code is encrypted filled message. In a further embodiment, the pad key may be an encryption key. In another further embodiment, memory 212 may further include an authentication code padding algorithm, and filling an encrypted message using a padding key may include encrypting a message padding based on applying a padding key to the authentication code padding algorithm.

Illustrative way to build advanced storage key

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

[0143] In step 1602, at least device information (eg, device information 402) associated with a mobile communication device (eg, mobile device 104), program code (eg, program code 406) associated with the first application a program (e.g., mobile payment application 404), and a program code (e.g., program code 412) associated with a second application (e.g., cryptographic application 410) may be stored in a memory (e.g., memory 212) of the mobile communication device 104, wherein 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).

[0144] In some embodiments, the device information 402 may include one or more unique identifiers associated with the mobile communication device 104. In one embodiment, the instance identifier 408 may be unique to the instance of the first application 404. In some embodiments, the second application 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, the program code 412 associated with the second application program 410 may be included in the program code 406 associated with the first application program 404. In further embodiments, the second application program 410 may be an executable function of the first application program 404.

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

[0146] At step 1608, the value of the diversifier (for example, the value 1208 of the diversifier) can be constructed by the processing device 204 based on at least the generated characteristic of the device 1204, the generated random value 1206 and the identifier 408 of the instance included in the program code 406 associated with the first application program 404. At step 1610, the constructed 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 an application program 410, by executing program code 412 associated with the second application program 410 to obtain a storage key (eg, enhanced storage key 1210).

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

[0148] In one embodiment, the method 1600 may also include: transmitting, by a transmission device (eg, a transmission unit 206), at least a random value 1206; receiving, by a receiving device (eg, receiving unit 202), one or more encrypted parameters, each of one or more encrypted parameters being encrypted using a storage key 1210; and storing, in a local database 1212 of the mobile communication device 104, received one or more encrypted parameters. In a further 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 some further embodiments, instance identifier 408 may also be transmitted by transmitting device 206.

Computer system architecture

[0149] FIG. 17 shows a computer system 1700 in which embodiments of the present invention, or parts thereof, may be implemented as computer-readable code. For example, the transaction management server 102 and the mobile device 104 shown in FIG. 1, can be implemented in a computer system 1700 using hardware, software, firmware, non-transient computer-readable media that store instructions, 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 embody modules and components used to implement the methods of FIG. 7, 8, 9A, 9B, 10A, 10B, 11, and 13-16.

[0150] If programmable logic is used, such logic may be executed on a commercially available processing platform or special purpose device. One skilled in the art will appreciate that embodiments of the disclosed invention can be practiced with various computer system configurations, including multi-core multiprocessor systems, minicomputers, universal computers, computers connected or clustered with distributed functions, as well as penetrating or miniature computers, which can be built into almost any device. For example, at least one processor device and memory may be used to implement the above embodiments.

[0151] The processor unit or device discussed 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 medium”, “non-transient computer-readable medium”, and “computer medium” discussed herein are used to mean, in general, physical media, for example, removable storage device 1718, removable storage device 1722, and a hard disk installed in a hard disk drive 1712.

[0152] Various embodiments of the present invention are described with respect to this illustrative computer system 1700. Based on this description, one skilled in the art will be able to understand how to implement the present invention using other computer systems and / or computer architectures. Although operations can be described as a sequential process, some of the operations can actually be carried out in parallel, simultaneously and / or in a distributed environment, moreover, the program code can be stored locally or remotely with access by single or multiprocessor machines. In addition, in some embodiments, the order of operations can be changed without departing from the spirit of the disclosed invention.

[0153] 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, for example, a bus, a message queue, a network, a multi-core messaging circuit, etc. A network may be any network suitable for the functions disclosed herein and may include a local area network (LAN), a wide area network (WAN), a wireless network (eg, WiFi), a mobile communications network, a satellite network, the Internet, optical fiber, and a coaxial cable , infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to those skilled in the art. 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 a removable drive 1714, for example, a floppy disk drive, a magnetic tape drive, an optical disk drive, flash memory, etc.

[0154] Removable storage 1714 may read and / or write removable storage 1718 in a well-known manner. Removable storage device 1718 may include removable storage media on which removable storage 1714 can read and write. For example, if the removable drive 1714 is a floppy disk drive or a universal serial bus port, the removable storage device 1718 may be a floppy disk drive or portable flash drive, respectively. In one embodiment, the removable storage device 1718 may be a non-transient computer-readable recording medium.

[0155] In some embodiments, the secondary memory 1710 may include alternative means for downloading computer programs or other instructions to a computer system 1700, such as a removable storage device 1722 and an interface 1720. Examples of such means may include a software cartridge and a cartridge interface (for example, used video game systems), a removable memory chip (for example, EEPROM, PROM, etc.) and the corresponding connector, and other removable storage units 1722 and interfaces 1720, which will be obvious to experts in this technical field.

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

[0157] The computer system 1700 may also include a communication interface 1724. The communication interface 1724 may be configured to transfer software and data between the computer system 1700 and external devices. Illustrative communication interfaces 1724 may include a modem, a network interface (eg, an Ethernet card), a communication port, a connector, and a PCMCIA card, etc. The software and data carried through the communication interface 1724 may be signals, which may be electronic, electromagnetic, optical, or other signals, which will be apparent to those skilled in the art. The signals can be distributed via communication channel 1726, which can be configured to carry signals and can be implemented using wire, cable, fiber optics, telephone line, cellular telephone line, radio frequency communication line, etc.

[0158] The computer system 1700 may further include a display interface 1702. The display interface 1702 may be configured to provide data transfer between the computer system 1700 and the external display 1730. Illustrative display interfaces 1702 may include a high-definition multimedia interface (HDMI), a digital visual interface (DVI), a video graphics matrix (VGA), etc. The display 1730 may be a display of any suitable type for displaying data transmitted through a display interface 1702 of a computer system 1700, including a cathode ray tube (CRT) display, a liquid crystal display (LCD), a LED display, a touch screen with capacitive sensors, thin-film transistors (TFT), etc.

[0159] A computer program medium and a computer medium may refer to memory blocks, for example, main memory 1708 and secondary memory 1710, which may be a semiconductor memory (eg, DRAM, etc.). These computer program products may be a means for providing software to a 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 allow the computer system 1700 to implement the methods discussed herein. In particular, computer programs, when executed, may enable processor device 1704 to implement the methods illustrated in FIGS. 7, 8, 9A, 9B, 10A, 10B, 11, and 13-16. Accordingly, such computer programs can be represented by controllers of a computer system 1700. When 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 hard disk drive or interface 1712 1724 communications.

[0160] The approaches of 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 authentication of remote notification service messages and the secure storage of data using an advanced storage key. Although various illustrative embodiments of the disclosed systems and method have been described above, it should be understood that they were presented for illustrative purposes only and not limitation. They are not exhaustive and do not limit the invention to the particular form disclosed. Modifications and variations are possible in light of the above principles or can be obtained from the practical application of the invention without going beyond its scope.

Claims (24)

1. A method of constructing an improved storage key, comprising the steps of: storing at least device information associated with a mobile communication device in a memory of a mobile communication device, a program code associated with a first application program, the program code including at least least an instance identifier, and program code associated with a second application program, the program code including a first key; generating by the processing device a characteristic feature of the device associated with the mobile communication device based on the stored information about the device by executing program code associated with the first application program; generating a random value by the processing device by executing program code associated with the first application program; constructing by the processing device the value of the diversifier based on at least the generated characteristic feature of the device, the generated random value and the identifier of the instance included in the program code associated with the first application program; and decrypting the constructed value of the diversifier using the first key stored in the program code associated with the second application program by processing the program code associated with the second application program to obtain the storage key. 2. The method according to claim 1, further comprising stages in which: secure data is stored in a local database of the mobile communication device; and encrypt the secure data stored in the local database using the storage key with the processing device. 3. The method of claim 1, wherein the device information includes one or more unique identifiers associated with a mobile communication device. 4. The method of claim 1, wherein the random value is a random or pseudo-random number. 5. The method of claim 1, wherein the instance identifier is unique to the instance of the first application. 6. The method according to claim 1, in which the second application program is configured to perform cryptography according to the principle of a white box using the first key. 7. The method of claim 1, wherein the first key is a dynamic key. 8. The method according to p. 1, further comprising stages in which: save in memory program data associated with the first application program; and storing the generated random value in program data associated with the first application program. 9. The method of claim 1, wherein the program code associated with the second application program is included in the program code associated with the first application program. 10. The method of claim 9, wherein the second application program is an executable function of the first application program. 11. The method according to p. 1, further comprising stages in which: transmit at least a random value generated by the transmitting device; receiving one or more encrypted parameters by the receiving device, each of one or more encrypted parameters being encrypted using a storage key; and stored in the local database of the mobile communication device, the received one or more encrypted parameters. 12. The method of claim 11, wherein transmitting at least the generated random value further includes transmitting the instance identifier. 13. A system for constructing an improved storage key, comprising: a memory of a mobile communication device configured to store at least device information associated with a mobile communication device, a program code associated with a first application program, the program code including at least least an instance identifier, and program code associated with a second application program, the program code including a first key; and a processing device configured to generate a device characteristic associated with the mobile communication device, based on the stored device information by executing program code associated with the first application program, generate a random value by executing program code associated with the first application program, build the value of the diversifier based on at least the generated characteristic feature of the device generated by random the value and identifier of the instance included in the program code associated with the first application program and decrypt the constructed value of the diversifier using the first key stored in the program code associated with the second application program by executing the program code associated with the second application program to obtain storage key. 14. The system of claim 13, further comprising: a local database of the mobile communication device configured to store secure data, the processing device further configured to encrypt the protected data stored in the local database using a storage key. 15. The system of claim 13, wherein the device information includes one or more unique identifiers associated with a mobile communication device. 16. The system of claim 13, wherein the random value is a random or pseudo-random number. 17. The system of claim 13, wherein the instance identifier is unique to the instance of the first application. 18. The system of claim 13, wherein the second application program is configured to perform cryptography according to the principle of a white box using the first key. 19. The system of claim 13, wherein the first key is a dynamic key. 20. The system of claim 13, wherein the memory is further configured to store program data associated with the first application program, and the processing device is further configured to store a generated random value in program data associated with the first application program. 21. The system of claim 13, wherein the program code associated with the second application program is included in the program code associated with the first application program. 22. The system of claim 21, wherein the second application program is an executable function of the first application program. 23. The system of claim 13, further comprising: a transmitting device configured to transmit the generated random value; and a receiving device configured to receive one or more encrypted parameters, each of one or more encrypted parameters being encrypted using a storage key, and the processing device is further configured to store the received one or more encrypted parameters in a local database of the mobile communication device. 24. The system of claim 23, wherein transmitting the generated random value further includes transmitting an instance identifier.

Images