Method and system for generating an advanced storage key in a mobile device without secure elements.

(54) Title: METHOD AND SYSTEM TO GENERATE AN ADVANCED STORAGE KEY IN A MOBILE DEVICE WITHOUT SECURITY ELEMENTS.

(54) Title: METHOD AND SYSTEM FOR GENERATING AN ADVANCED STORAGE KEY IN A MOBILE DEVICE WITHOUT SECURE ELEMENTS.

(57) Summary

A method of constructing an advanced storage key includes: storing, in a memory of a mobile device, at least (i) device information associated with the mobile device, (i) program code associated with a first program, the code includes an instance identifier and (iii) program code associated with a second program, the code includes a first key; generating a device finger associated with the mobile device based on the device information via execution of the code associated with the first program; generating a random value via execution of the code associated with the first program; constructing a diversifying value based on the generated device footprint, the generated random value, and the instance identifier included in the code associated with the first program; and deciphering the constructed diversifying value using the first key stored in the code associated with the second program via executing the code associated with the second program to obtain a storage key.

(57) Abstract

A method for building an advanced storage key ineludes: storing, in a memory of a mobile device, at least (i) device Information associated with the mobile device, (¡i) program code associated with a first program, the code including an instance identifier, and (iii) program code associated with a second program, the code including a first key; generating a device fingerprint associated with the mobile device based on the device Information via execution of the code associated with the first program; generating a random value via execution of the code associated with the first program; building a diversifier value based on the generated device fingerprint, the generated random value, and the instance identifier included in the code associated with the first program; and decrypting the built diversifier value using the first key stored in the code associated with the second program via execution of the code associated with the second program to obtain a storage key.

METHOD AND SYSTEM TO GENERATE AN ADVANCED STORAGE KEY IN A MOBILE DEVICE WITHOUT SECURITY ELEMENTS

Related requests

This application claims the benefit pursuant to title 35 of the United States Code, section 119 (e), of previously filed provisional patent applications numbers 61 / 910,819 filed on December 2, 2013; 61 / 951,842 filed March 12, 2014; 61 / 955,716 filed March 19, 2014; 61 / 979,132 filed April 14, 2014; and 61 / 980,784 filed on April 17, 2014; 61 / 979,122 filed on April 14, 2014; 61 / 996,665 filed on May 14, 2014; and in particular, Provisional Patent Application No. 61 / 979,113 filed on April 14, 2014, each incorporated herein by reference in its entirety.

Field of the invention

The present description refers to the generation of an advanced storage key to be used in a mobile device without a security element and more specifically, the use of multiple values ​​to build an advanced storage key in a mobile device without a security element. to be used for data security storage on the mobile device.

Background of the invention

Advances in mobile and communication technologies have created enormous opportunities, one of which is to provide the user of a mobile computing device with the ability to initiate and pay for payment transactions using their mobile device. One of these approaches to allow this type of action on a mobile device has been the use of near field communication technology (NFC) to safely transmit payment details from the mobile device to a point of sale terminal. (POS) close without contact. In order to achieve this, mobile phones with security feature hardware, such as a security feature (SE) chip, are used to securely store payment credentials. A security element is a special element that can be included in some near field communication (NFC) enabled devices that is an inviolable platform that can safely house applications and their confidential data.

However, not all mobile devices have security features. Also, some financial institutions may not have access to the security features of mobile devices, even if the mobile device is equipped with such a feature. As a result, many consumers with mobile devices that possess the hardware required to conduct contactless or other types of remote payment transactions may be unable to actually use this capability. Due to these difficulties, there is a need for a technical solution to enable mobile computing devices to initiate and conduct payment transactions without the use of security features.

Some methods and systems for conducting payment transactions using mobile devices that lack security features, or without the use of security features on mobile devices equipped with them, can be found in US 10 patent application number 13 / 827,042 entitled Systems and Methods for Processing Mobile Payments by Provisioning Credentials to Mobile Devices Without Secure Elements, by Mehdi Collinge et al., filed on March 14, 2013, which is incorporated herein by reference in its entirety. While such methods and systems may be suitable for conducting payment transactions using a mobile device without the need for a security feature, many consumers, merchants and financial institutions may be reluctant to participate in such transactions 20 due to a desire for even greater security.

As a result, there is a need for technical solutions to provide even more security for the receipt and storage of payment credentials on a mobile device lacking a security element, as well as to provide greater security in the transmission of payment credentials. I pay a

I 4 point of sale from the mobile device during the completion of a financial transaction. Increased security in these processes can result in greater peace of mind for all entities involved, which can result in increased use of mobile devices for contactless or remote payment transactions, which can provide a large number of benefits to consumers about the methods। traditional payment.

¡

Brief description of the invention

The present description provides a description of the systems and methods for building advanced storage keys.

One method of building an advanced storage key includes: storing, in a memory of a mobile communication device, at least (i) device information associated with the mobile communication device, (ii) program code associated with a first application program, wherein the program code includes the minus one instance identifier and (iii) program code associated with a second application program, wherein the program code includes a first * key; generating, by means of a processing device, a device finger associated with the mobile communication device based on the stored device information via execution of the program code associated with the first application program;

I

II 'generating, by means of the processing device, a random value via execution of the program code associated with the first application program; constructing, by means of the processing device, a diversifying value based on at least the generated device fingerprint, the generated random value and the instance identifier included in the program code associated with the first application program; and decrypting, by the processing device, the diversifying value constructed using the first key stored in the program code associated with the second application program to obtain a storage key.

A system for building an advanced storage key includes a memory of a mobile communication device and a processing device. The memory of a mobile communication device is configured to store at least: device information associated with the mobile communication device; program code associated with a first application program, wherein the program code includes at least one instance identifier; and program code associated with a second application program, wherein the program code includes a first key. The processing device is configured to: generate a device finger associated with the mobile communication device based on the stored device information via execution of the program code associated with the first application program; generating a random value via execution of the program code associated with the first application program; constructing a diversifying value based on at least the generated device footprint, the generated random value, and the instance identifier included in the program code associated with the first application program; and deciphering the constructed diversifying value using the first key stored in the program code associated with the second application program via execution of the program code associated with the second application program to obtain a storage key.

Brief description of the figures

The scope of the present description is better understood from the following detailed description of the example embodiments when read in conjunction with the accompanying drawings. The drawings include the following figures:

FIG. 1 is a block diagram illustrating a high-level system architecture for processing payment transactions with advanced security in the provisioning and storage of payment credentials according to exemplary modalities.

Figure 2 is a block diagram illustrating the mobile device of Figure 1 for processing payment transactions without a security element and secure receipt and storage of payment credentials in accordance with ¡

example modalities.

Figure 3 is a block diagram illustrating the mobile device card database of Figure 2 for storing payment credentials in accordance with exemplary embodiments.

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

Figure 5 is a block diagram illustrating the transaction management server of Figure 1, for processing payment transactions with a mobile device without a security element in accordance with exemplary embodiments.

Figure 6 is a block diagram illustrating the processing server account database of Figure 5, for storing payment credentials and account details in accordance with exemplary modes.

Figure 7 is a flow diagram illustrating a process for the transmission and validation of double application cryptograms for the processing of payment transactions involving a mobile device that lacks a security element according to the modalities of example.

Figure 8 is a flow chart illustrating an alternative process for transmitting and validating the cryptograms of

II: 8 i double applications for the processing of payment transactions that involve a mobile device that lacks a security element according to the example modalities.

i Figure 9 is a flowchart illustrating a process for creating, transmitting and validating a remote notification service or other data message delivered to a mobile device lacking a security element according to modalities of I example.

i

Figures 10A and 10B are a flow chart illustrating a process for creating, transmitting and validating a message returned by a mobile device lacking a security element in accordance with the exemplary embodiments.

Figure 11 is a flow chart illustrating a process for validating a message from the notification service to | 15 distance using the mobile device of Figure 2 according to the example modalities.

Figure 12 is a diagram illustrating the generation of an advanced storage key using the mobile device of Figure 2 according to exemplary embodiments.

Figures 13 and 14 are flow charts illustrating example methods for payment credentials generated in a payment transaction according to the example modalities.

FIG. 15 is a flow chart illustrating an example method for receiving and processing a remote notification service message in accordance with the example embodiments.

Fig. 16 is a flow chart illustrating an example method for constructing an advanced storage key in accordance with the example embodiments.

! FIG. 17 is a block diagram illustrating a computing system architecture in accordance with exemplary embodiments.

Other areas of applicability of the present description will become apparent from the detailed description provided hereinafter. It is to be understood that the detailed description 10 of the exemplary embodiments is for purposes of illustration only and is therefore not intended to necessarily limit the scope of the disclosure.

Detailed description of the invention

Glossary of terms

Payment network - A system or network used for the transfer of money through the use of cash substitutes. Payment networks can use a variety of different protocols and procedures in order to process the money transfer of different types of transactions. Transactions that can be carried out through a payment network may include purchases of products or services, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks can be configured to carry out 25 transactions using cash substitutes, which can include payment cards, letters of credit, checks, transaction accounts, etc. Examples of networks or systems configured to function as payment networks include those operated by MasterCard®, VISA®, Discover®, American Express®, PayPal®, etc. The use of the term payment network in this document can refer to both the payment network as an entity, as well as the physical payment network, such as the equipment, hardware and software that comprise the payment network.

Transaction account - A financial account that can be used to fund a transaction, such as a checking account, savings account, credit account, virtual payment account, etc. A transaction account can be associated with a consumer, which can be any suitable type of entity associated with a payment account, which can include a person, family, business, corporation, government entity, etc. In some cases, a transaction account can be virtual, such as accounts managed by PayPal®, etc.

Payment Card - A card or data associated with a transaction account that can be provided to a merchant for the purpose of financing a financial transaction through the associated transaction account. Payment cards can include credit cards, debit cards, charge cards, stored value cards, prepaid cards, fleet cards, virtual payment numbers, virtual card numbers, controlled payment numbers, etc. A payment card can be a physical card that can be provided to a merchant, or it can be data that represents the associated transaction account (for example, as stored in a communication device, such as a smartphone or computer. ). For example, in some cases, data that includes a payment account number can be considered as a payment card for processing a transaction financed by the associated transaction account. In some cases, a check can be considered a payment card when applicable.

Payment transaction - A transaction between two entities in which money or other financial benefit is exchanged from one entity to the other. The payment transaction may be a transfer of funds, for the purchase of goods or services, for the repayment of a debt, or for any other exchange of financial benefit, as will be apparent to persons having experience in the relevant art. In some cases, payment transactions may refer to transactions financed through a payment card and / or payment account, such as credit card transactions. These payment transactions can be processed through an issuer, the payment network, and the acquirer. The process for processing such a payment transaction can include at least one of authorization, batching, release, settlement, and financing. Authorization may include the provision of payment details by the consumer to a merchant, the provision of transaction details (for example, including payment details) from the merchant to his acquirer, and verification of payment details. with the issuer of the consumer's payment account used to fund the transaction. Batching can refer to storing an authorized transaction in a batch with other authorized transactions for distribution to an acquirer. Release may include sending the transactions in batches from the acquirer to a payment network for processing. Settlement may include debit from the issuer through the payment network for transactions involving the issuer's beneficiaries. In some cases, the issuer may pay the acquirer through the payment network. In other cases, the issuer may pay the acquirer directly. Financing may include payment to the merchant by the acquirer for payment transactions that have been cleared and settled. It will be apparent to persons having experience in the relevant art that the ordering and / or categorization of the steps discussed above are performed as part of the processing of payment transactions.

Point of Sale - A computing device or computer system configured to receive interaction with a user (e.g. a consumer, employee, etc.) to enter transaction data, payment data, and / or other appropriate types data for the purchase and / or payment of goods and / or services. The point of sale can be a physical device (for example, a cash register, kiosk, desktop computer, smartphone, tablet computer, etc.) in a physical location that a customer visits as part of the transaction, such as in a traditional physical store, or it can be virtual in e-commerce environments, such as online retailers that receive customer communications over a network such as the Internet. In cases where the point of sale can be virtual, the computing device operated by the user to initiate the transaction, or the computer system that receives the data as a result of the transaction, can be considered as the point of sale, as applicable.

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

Figure 1 illustrates a system 100 for processing payment transactions using a mobile device without requiring the use of security elements, which may include the secure provision of payment credentials to a mobile device, their secure storage. and its use in the generation of multiple application cryptograms to be used in the validation and processing of the payment transaction.

System 100 may include a transaction management server 102. The transaction management server 102, described in greater detail below, can be one or more computing devices specifically programmed to perform the functions described herein to provide payment credentials to a mobile device 104 using the notification message. remotely transmitted in a secure manner and for the validation of the payment credentials produced by the mobile device 104 as part of a payment transaction. Although it is illustrated and described herein that the transaction management server 102 performs a variety of functions, it will be apparent to those of skill in the relevant art that the transaction management server 102 can be comprised of multiple functions. computing devices, servers and / or computer networks, configured to carry out the functions described herein. Mobile device 104, described in greater detail below, can be any type of mobile computing device suitable to perform the functions described herein, which may include a cell phone, smart phone, smart watch, other computing device. portable or built-in, tablet computer, laptop, etc. In some embodiments, mobile device 104 may lack a security feature. In other embodiments, mobile device 104 may include a security feature, but such an item may not be used in conjunction with the methods and systems discussed herein, or it may be used in conjunction with the methods and systems discussed herein. present document, such as to provide additional security.

Mobile device 104 can communicate with transaction management server 104 using multiple communication channels, such as using dual channel communication. Dual channel communication may include the use of two communication channels in transmitting and receiving data, such as for verification and authentication, in order to ensure greater security in data transmission. Mobile device 104 may include a mobile payment application (MPA) configured to be executed by mobile device 104 in order to carry out the functions of mobile device 104 discussed herein. The mobile payment application (MPA), discussed in greater detail below, can be installed on mobile device 104 and activated using an activation code provided by transaction management server 102 employing methods and systems that will be apparent. for people who have experience in the relevant technique, in such a way that the mobile device 104 and the transaction management server 102 can transmit and receive the communications in a secure manner through one or more communication channels using the shared data.

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

In some embodiments, the payment credentials can be provided to mobile device 104 via a remote notification service message. As discussed in greater detail below, the remote notification service (RNS) message may be a secure message that is transmitted to mobile device 104 and subsequently validated by mobile device 104, such that the data contained in the same can be safe from other devices and users. The mobile payment application (MPA) of mobile device 104 can verify the authenticity of the remote notification service (RNS) receipt message and can decrypt it to obtain the data included therein. The mobile device 104 can then carry out the necessary functions, based on the data (for example, such as by executing the instructions included in the data) and, if applicable, can generate a return message to be sent back. back to the transaction management server 102. In some cases, the return message may be validated by the transaction management server 102.

In some cases, remote notification service (RNS) message validation on mobile device 104, or return message validation on transaction management server 102, may use at least message counters and code authentication. The use of both the counters and the authentication codes can ensure that only the intended mobile device 104 is capable of validating and decrypting the data included in the remote notification service (RNS) message. Furthermore, if the rules and / or algorithms used in generating the authentication code are included in the mobile payment application (MPA), then only one mobile device 104, which also includes a specific instance of the application program, can be Able to validate the remote notification service (RNS) message, also resulting in increased security. In cases where the remote notification service (RNS) message may include the payment credentials, this can ensure that the payment credentials are only available on the appropriate mobile device 104 and only if the mobile payments application (MPA ) used to access them is an appropriate and authorized application.

Payment credentials provided to mobile device 104 can be securely stored in mobile device storage 104, such as a card database, as discussed in greater detail below. In some embodiments, mobile device 104 may be configured to generate an advanced storage key for use in storing data in a secure manner, such as payment credentials, in a database or memory of mobile device 104. Generating an advanced storage key, as discussed in more detail below, can use unique device information, unique mobile payment application (MPA) information, and randomly generated information to identify a Secure storage key that can be used to store data securely on mobile device 104. As a result, payment credentials or other confidential data can be securely stored in mobile device 104 without the use of a security element, which may result in mobile device 104 being able to initiate and perform the transaction of payment without the use of a security feature, increasing availability for issuers 106 and consumers 108, while maintaining a high level of security.

Once mobile device 104 has the payment credentials for a transaction account received, validated, and securely stored therein, a consumer 108 can take mobile device 104 to a point of sale 110 in a store, to carry out a payment transaction. Consumer 108 may select the goods or services for purchase, may initiate a payment transaction for purchase with a merchant, and may use mobile device 104 to transmit payment credentials to be used in financing the transaction of payment. The transmission of the payment credentials to the point of sale 110 may include the transmission of two or more application cryptograms. The use of two or more application cryptograms may result in a higher level of security for transactions processed employing the methods and systems discussed herein than is available in traditional contactless and remote transactions, including led transactions. performed using a mobile device 104 having a security feature.

The application cryptograms can each be generated by mobile device 104 using separate session keys and additional data, which are described in more detail below. The application cryptograms, generated using the data stored in the mobile device 104, such as in the storage secured by means of the advanced storage key and associated with the mobile payment application (MPA), can ensure that the application cryptograms authenticate the mobile device 104 and the specific instance of the mobile payment application (MPA). In some cases, one of the cryptograms and / or session keys used to generate the cryptograms may use the information provided by the consumer 108, such as a personal identification number (PIN). The use of the consumer's personal identification number (PIN) or other authentication information may enable a cryptogram to authenticate both the consumer 108 and the mobile device 104. In such a case, the cryptograms generated by mobile device 104 may include one that authenticates mobile device 104 and a second that authenticates both mobile device 104 and consumer 108.

The cryptograms may be received by the point of sale 110 as part of the completion of the payment transaction, such as via near field communication (NFC). The application cryptograms can accompany additional payment information, as may be required in the context of any suitable type of payment transaction, such as a contactless transaction, a remote transaction, a secure remote payment transaction, a magnetic stripe transaction and a transaction with Μ / EMV Chip and can be transmitted to the point of sale 110 using any suitable method according to the same, as will be apparent to persons having experience in the relevant art. The cryptograms can be transmitted to an acquirer 112, which may be a financial institution, such as an acquirer bank, associated with the merchant. The acquirer 112, for example, may issue a transaction account to the merchant, which is used to receive payment of funds from the consumer 108 for the payment transaction. The acquirer 112 may present the cryptograms and additional details of the transaction to a payment network 114 employing methods and systems that will be apparent to those of skill in the relevant art. For example, the transaction details and application cryptograms can be included in an authorization request submitted to the payment network 114 in the payment lanes.

In some embodiments, the two application cryptograms can be included in a single transaction message. For example, mobile device 104 and / or point of sale 110 may include both application cryptograms in the data fields inherited from a traditional transaction message in order to transmit both application cryptograms using payment systems and hardware. existing. In some cases, the transaction management server 102 may be configured to use Track 2 data for validation of application cryptograms, such as in a magnetic stripe transaction. In such cases, if the transaction message includes the Track 1 data, the transaction management server 102 may be configured to convert I the Track 1 data to Track 2 data, which may also include the conversion Track 1 or Track 2 data modified into Track 1 or Track 2 data unmodified (for example, original, reconstructed, etc.), respectively. By performing these functions and by including the application cryptograms in the legacy data fields, the transaction management server 102 can be configured to process and validate remote and contactless payment transactions using a mobile device 104 with a higher level of security, without the need to use a security element in the mobile device 104 and without modifications to traditional payment systems.

Payment network 114 may process the payment transaction employing methods and systems that will be apparent to those of skill in the relevant art. As part of the processing, the payment network 114 may transmit the application cryptograms to the sender 106 for verification. In some embodiments, the verification can be performed by the payment network 114. The sender 106 or the payment network 114 can communicate with the transaction management server 102. In some embodiments, the application cryptograms can be transmitted to the transaction management server 102 and can be verified by generating the validation of the application cryptograms using the transaction management server 102, which can be generated using locally stored payment credentials. In other modalities, the issuer 106 or the payment network 114 may request the application cryptograms from the transaction management server 102, which can generate them and return the cryptograms to the issuer 106 or the payment network 114 for validation against the cryptograms produced by mobile device 104.

Because the transaction management server 102 owns the payment credentials and other data used by the mobile device 104 to generate the application cryptograms, the validation of the payment credentials produced by the mobile device 104 to fund the payment transaction This can be done by comparing the application cryptograms generated by the mobile device 104 and those generated by the transaction management server 102. In some embodiments, the transaction management server 102 may be a part of the payment network 114 or the sender 106. In cases where the transaction management server 102 may be part of the payment network 114, validation may be performed prior to contacting the issuer 106 as part of the traditional processing of the payment transaction (for example, to approval of financing the transaction using the consumer's transaction account 108 with the issuer 106).

By using multiple application cryptograms, the security of payment transactions can be increased. Furthermore, in cases where each cryptogram can authenticate the separate data, such as cases where one cryptogram authenticates mobile device 104 and the other authenticates both mobile device 104 and consumer 108 (for example, via number personal identification (PIN) code), additional data and considerations may also be provided to the issuer 106 to be used in the decision to approve or deny a transaction. For example, if the two cryptograms are incorrect (for example, the cryptograms generated by mobile device 104 do not correspond to those generated by transaction management server 102), the transaction may be denied. If one cryptogram is correct and the other is incorrect, the transaction may be denied for security reasons, or it may be approved, such as based on a decision of the issuer 106. For example, issuer 106 may approve a transaction where consumer authentication fails, but mobile device authentication passes, because other available data may indicate that an authorized user, but not consumer 108, is using the mobile device. 104 for the transaction.

As a result, the use of both cryptograms can provide valuable data that can be used by payment networks 114 and issuers 106 in processing payment transactions. Additionally, the use of two or more cryptograms can provide greater security than traditional contactless or remote payment methods, which can result in less fraud and greater acceptance from consumers 108, issuers 106, and merchants. In cases where the use of two or more application cryptograms are generated from the payment credentials that have been provided in a secure way using the messaging methods of the remote notification service (RNS) and the systems discussed in the present and that have been safely stored by means of advanced storage keys generated using the methods and systems discussed in this document, the overall security of the system 100 can be greatly increased over traditional systems for processing contactless transactions and payments. As a result, the system 100 can provide greater security in various aspects of data transmission, storage and processing than that provided for traditional contactless payment systems and for other types of remote payment transactions and for remote payment transactions. general payment that may use the methods and systems discussed herein.

Mobile device

Figure 2 illustrates one embodiment of the mobile device 104 of the system 100. It will be apparent to those of skill in the relevant art that the embodiment of the mobile device 104 illustrated in Figure 2 is provided for illustration only and is not necessarily exhaustive. for all possible configurations of mobile device 104 suitable for carrying out the functions as discussed herein. For example, the computer system 1700 illustrated in Figure 17 and discussed in greater detail below may be a suitable configuration of mobile device 104.

Mobile device 104 may include reception unit 202. Receiver unit 202 may be configured to receive data over one or more networks by means of one or more network protocols. Receiving unit 202 may receive, for example, program data for one or more application programs to be installed on and run by mobile device 104, such as a mobile payment application (MPA) discussed in greater detail below. . The receiving unit 202 can also receive messages from the remote notification service (RNS), such as the messages transmitted by the transaction management server 102, including the messages from the remote notification service (RNS) that include the credentials of payment. The receiving unit 202 may also receive additional data suitable for performing the traditional functions of a mobile device 104, such as telephone communications, cellular communications, etc. In some cases, mobile device 104 may include a plurality of receiver units 202, such as separate receiver units 202, each configured to communicate with one or more separate networks via appropriate protocols. For example, mobile device 104 may include a first receiving unit 202 for receiving data for near field communication (NFC) transactions and a second receiving unit 202 for receiving communications over a mobile communication network.

Mobile device 104 may also include input unit 214. Input unit 214 may be configured to communicate with one or more input devices that connect internally or externally to mobile device 104 to receive input from consumer 108, such as such as a keyboard, mouse, click wheel, scroll wheel, touch screen, microphone, camera, receiver, etc. Input unit 214 can receive input from consumer 108, which can be processed by processing unit 204.

The processing unit 204 may be configured to carry out the functions of the mobile device 104 discussed herein. The processing unit 204 can execute the program code stored in the mobile device, such as for the mobile payment application (MPA), and can be configured to carry out a plurality of functions associated with each application program, in addition to others. mobile device features 104. Processing unit 204 may receive input from consumer 108 via input unit 214 and perform functions accordingly, such as by executing application programs, performing functions in programs, receiving data, transmitting data, displaying data, etc., as will be apparent to persons having experience in the relevant art. For example, the processing unit 204 can be configured to validate the remote notification service (RNS) messages, generate the advanced storage keys, and generate the application cryptograms, as discussed in more detail below.

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

Mobile device 104 may also include a transmission unit 206. Transmission unit 206 can be configured to transmit the data over one or more networks by means of one or more network protocols. The transmission unit 206 can transmit response messages from the remote notification service (RNS) to the transaction management server 102. Transmission unit 206 can also be configured to transmit application cryptograms and / or payment credentials, such as to a point of sale 110, for use in a payment transaction. Transmission unit 206 may be further configured to perform additional functions of mobile device 104, as will be apparent to those of skill in the relevant art, such as the traditional functions of a mobile communication device for transmission of cellular communications. , etc. In some cases, mobile device 104 may include a plurality of transmission units 206, which may be separately configured to communicate with one or more separate networks, such as a transmission unit 206 configured to transmit payment credentials and cryptograms. near field communication (NFC) payment method and another transmission unit 206 configured to transmit the data via a mobile communication network.

Mobile device 104 may also include a database for card 208. Database for card 208, described in greater detail below, may be the data storage on mobile device 104 that is configured to store the data. associated with one or more transaction accounts and / or payment cards. The card database 208 can store the payment credentials associated with the transaction account, such as those supplied to the mobile device 104 by the transaction management server 102 in a secure remote notification service (RNS) message. and additional data that can be used in generating the application cryptograms, as discussed in more detail below. In some cases, the card database 208 may be stored as part of the mobile payment application.

Mobile device 104 may further include memory 212. Memory 212, which is described in greater detail below, may be configured to store data for mobile device 104 suitable for performing the functions of mobile device 104 discussed. at the moment. For example, memory 212 may store data suitable for generating advanced storage keys for encryption of additional data on mobile device 104, such as card database 208, as discussed in greater detail below. . Memory 212 may also be configured to store program code for application programs executed by processing unit 204, such as an operating system, program code to receive data via input unit 214, and to display the data by means of the display unit 210, the rules and / or the algorithms to perform the functions discussed herein, etc. Memory 212 can also store data suitable for performing the traditional functions of a mobile device 104, such as the rules and / or algorithms for the transmission and reception of cellular communications via a mobile network. Additional data stored in memory 212 will be apparent to those of skill in the relevant art.

Mobile device card database

Figure 3 illustrates one modality of the database of the card 208 of the mobile device 104 to store the payment credentials and other data associated with the transaction accounts to be used in the financing of the payment transactions made with the mobile device 108 .

Card database 208 may include one or more payment profiles 302, illustrated in FIG. 3 as payment profiles 302a, 302b, and 302c. Each payment profile 302 can be associated with a transaction account that can be used to fund a payment transaction and can include at least the payment credentials 304, one or more one-time keys 306, a first session key 308, a second session key 310, and an application transaction counter 312.

Payment credentials 304 may include data associated with the related transaction account that is used for identification and validation by the payment network 114 and / or the issuer 106 in processing a payment transaction using the transaction account. related. Payment credentials 304 can include, for example, a transaction account number, security code, expiration date, cardholder name, authorized user name, tracking data, card design description data , digit count, bitmaps, etc.

The single-use keys 306 can be payment tokens valid for a single payment transaction, which can be used by the processing unit 204 of the mobile device 104 to generate one or more of the application cryptograms used in the payment transaction. . In some embodiments, a one-time 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 different application transaction counter 312, which may not be included separately in the payment profile 302. The different settings of the data stored in the payment profile 302 for used in performing the functions described herein will be apparent to those of skill in the relevant art. In some cases, the single-use key 306 may include, or may be comprised of, a key that is used to generate the one or more application cryptograms. In some embodiments, the first session key 308 and the second session key 310 can be included in a one-time key 306 provided to the mobile device 104 and / or generated using the data included in the one-time key 306.

The first session key 308 and the second session key 310 may be additional keys that are used by the processing unit 204 in the generation of the application cryptograms transmitted to the point of sale 110 as part of performing a transaction of payment using mobile device 104. In some embodiments, the first session key 306 may be used in the generation of a first application cryptogram by the processing unit 204, such as using program code, rules, or algorithms stored in memory 212 of the mobile device 104. The second session key 310 can be used in generating a second cryptogram of the application.

In some embodiments, the second session key 310 can be generated by the processing unit 204. In that embodiment, the second session key 310 can be generated using a one-time key 306 and user authentication data, such as as a personal identification number (PIN) provided by consumer 108 (eg, via input unit 214). In this embodiment, the second session key 310 cannot be stored in the payment profile 302 and instead can be generated, used and discarded as part of the payment transaction process. The second cryptogram of the application, therefore, when generated from the second session key 310 that is generated using the one-time key 306 and the consumer's personal identification number (PIN), serves to authenticate both the mobile device 104 and consumer 108.

The personal identification number (PIN) can be a number supplied by the consumer 108 (for example, during the registration of the mobile payment application (MPA) on the mobile device 104 or during the registration of the account of transactions with the sender 106 and / or transaction management server 102) that can be used to authenticate consumer 108. When conducting a payment transaction, the consumer 108 or another user of the mobile device 104 can supply a personal identification number (PIN) via the input unit 214. In some embodiments, if the supplied personal identification number (PIN) is incorrect (for example, it does not match the consumer's personal identification number (PIN) 108 during registration), then the processing unit 204 can continue to generate the second session key 310 and subsequently generate the second application cryptogram. If the personal identification number (PIN) provided is incorrect, then the second cryptogram of the application will therefore be incorrect, resulting in a failed validation of the second cryptogram of the application by the transaction management server 102, issuer 106 and / or payment network 114, which may provide issuer 106 with an opportunity to decline the transaction accordingly, or to still approve the transaction.

Mobile device memory

Figure 4 illustrates a modality of the memory 212 of the mobile device 104 for the storage of application programs and other data to be used in the secure storage of the data in the mobile device 104 and for carrying out payment transactions using the device. mobile 104. In an exemplary embodiment, memory 212 cannot be a security feature.

Memory 212 may include information from device 402.

Information from device 402 may include one or more data items associated with mobile device 104 that, in some cases, may be unique to mobile device 104. For example, information from device 402 may include an access control address to the media, a reference number, a serial number, an identification number, etc. Additional information that may be considered information from device 402 of a mobile device 104 will be apparent to those of skill in the relevant art.

Memory 212 may also include a mobile payment application (MPA) 404. Mobile payment application (MPA) 404 may be an application program configured to perform the functions of mobile device 104 described herein, such as receiving and storing payment credentials, validating messages. of the remote notification service (RNS) and the generation of application cryptograms to be used in carrying out payment transactions. Additional features of the Mobile Payment Application (MPA) 404 may include traditional features of a digital wallet or other similar application program, as will be apparent to those with experience in the relevant art.

Mobile payment application (MPA) 404 may include program code 406. Program code 406 may be code, executed by processing unit 204 of mobile device 104, that causes processing unit 204 and other components of the mobile device 104 carry out the functions of the Mobile Payment Application (MPA) 404, as discussed herein. For example, program code 406 may include code suitable for generating application cryptograms, for validating Remote Notification Service (RNS) messages, and so on. Program code 406 may also include program code suitable for generating a random value, which can be used in generating an advanced storage key. The random value can be a random or pseudo-random number, which can be generated employing methods and systems that will be apparent to persons having experience in the relevant art.

The Mobile Payment Application (MPA) 404 may also include an Instance Identifier 408. The Instance Identifier 408 may be a unique value for the Mobile Payment Application (MPA) specifies 404, which can be used in the generation of the key. advanced storage device that is used to secure data on mobile device 104, such as the database on card 208. By having the unique instance identifier 408 for the mobile payment application (MPA) 404, multiple mobile payment applications (MPA) 404 can be installed on the mobile device 104, without any mobile payment application (MPA) 404 being able to access the data that is stored in a secure way by any other mobile payment application (MPA) 404, which can thus ensure that payment profiles 302 for specific transaction accounts are not accessible to other programs. Instance identifier 408 can be a number, an alphanumeric value, a hexadecimal value, or any suitable value that may be unique to a mobile payment application (MPA) 404.

As discussed in more detail below, the processing unit 204 of the mobile device 104 may be configured to generate a diversification value using the information from the device 402, the random value generated using the program code 406 of the mobile payment application. (MPA) 404 and instance identifier 408 stored in mobile payment application (MPA) 404. The diversification value can be used by a cryptographic application 410 also stored in memory 212. The cryptographic application 410 can be an application program configured to perform white-box cryptography and / or any other suitable cryptographic function that will be apparent. for people who have experience in the relevant technique.

Cryptographic application 410 may include program code 412. Program code 412 may be executed by processing unit 204 of mobile device 104 to enable processing unit 204 and other components of mobile device 104 to perform the tasks. cryptographic functions of the cryptographic application 410 that is discussed herein. Features may include generating an advanced storage key. The advanced storage key can be generated using the diversification value generated by the mobile payment application 404 and an encryption key 414 included in the cryptographic application 410. In some embodiments, the diversification key can be decrypted using the encryption key from 414 to get the advanced storage key.

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

Memory 212 may also include additional data stored in mobile device 104 suitable for performing the functions described herein, as well as any additional functions of mobile devices. For example, memory 212 may include program code for an operating system, code, rules, or algorithms for the reception and transmission of mobile communications, such as telephone calls, etc.

In some embodiments, the mobile device 104 can also be configured to receive the already encrypted data using the advanced storage key, which can be stored in the encrypted local storage of the mobile device 104, such as in memory 212, the database. card 208 data, or other suitable storage. In this mode, the mobile device 104 can be configured to transmit the generated random value to the transaction management server 102 or another trusted entity, which can generate the advanced storage key using the same methods and systems that use the random value. generated and the data provided to the mobile device 104 can be encrypted. The mobile device 104, therefore, can receive the already encrypted data using the advanced storage key, for local storage in the mobile device 104.

Transaction management server

FIG. 5 illustrates one embodiment of the transaction management server 102 of system 100. It will be apparent to those of skill in the relevant art that the embodiment of the transaction management server 102 illustrated in FIG. 5 is provided only as illustration and is not necessarily exhaustive for all possible configurations of the transaction management server 102 suitable for carrying out the functions as discussed herein. For example, the computer system 1700 illustrated in FIG. 17 and discussed in greater detail below, may be a suitable configuration of the transaction management server 102.

The transaction management server 102 may include a receiving unit 502. The receiving unit 502 may be configured to receive the data over one or more networks by means of one or more network protocols. Receiver unit 502 may receive data from mobile device 104, such as receive or return messages, confirmation messages, transaction notifications, etc., from payment network 114, sender 106, or another suitable entity. . The receiving unit 502 may receive the notifications of transactions or requests for cryptograms, such as to initiate the generation of the application cryptograms to be used in validating the payment credentials in a payment transaction. Receiving unit 502 may also receive transaction account data, such as from sender 106, to be used in generating payment credentials to be provided to mobile device 104.

The transaction management server 102 may also include a processing unit 504. The processing unit 504 may be configured to carry out the functions of the transaction management server 102 discussed herein, as will be apparent to those who have relevant art experience. The processing unit 504 can thus be configured to generate and encrypt remote notification service (RNS) messages and the data included therein, validate return messages from mobile device 104, generate payment credentials, generate cryptograms of applications, validate application cryptograms, etc., as discussed in more detail later.

The transaction management server 102 may further include a transmission unit 506. The transmission unit 506 may be configured to transmit the data over one or more networks by means of one or more network protocols. Transmission unit 506 may transmit remote notification service (RNS) messages, payment credentials, application cryptograms, validation notifications, and other data that will be apparent to those of skill in the relevant art. Transmission unit 506 may be configured to transmit the data to mobile device 104, such as through a mobile communication network or the Internet, payment network 114, sender 106, and any other suitable entity.

The transaction management server 102 may also include an account database 508. The account database 508, which is described in greater detail below, may be configured to store account information for a plurality of transaction accounts. The account information may include data and keys used for the generation of the application cryptograms used in the validation of the payment credentials received during the payment transactions carried out using the mobile device 104. Account database 508 can also be configured to store transaction data for payment transactions performed involving mobile device 104 and other data, such as data associated with consumer 108 or other authorized users of the account. related transactions.

The transaction management server 102 may also include a memory 510. The memory 510 may be configured to store additional data for use by the transaction management server 102 in performing the functions described herein. For example, memory 510 can store rules or algorithms for the validation of application cryptograms, rules or algorithms for the generation of validation notifications, algorithms for the generation of session keys and application cryptograms, encryption keys for encryption and decryption of remote notification service (RNS) data and messages, etc. Additional data that can be stored in memory 510 will be apparent to those of skill in the relevant art.

Transaction management server account database

FIG. 6 illustrates one mode of account database 508 of transaction management server 102 for storing data related to transaction accounts for use in validating payment credentials and other transaction data provided in the completion of payment transactions, including mobile device 104.

Account database 508 may include a plurality of account profiles 602, illustrated in FIG. 6 as account profiles 602a, 602b, and 602c. Each account profile 602 may include one or more single-use 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, an account profile 602 may further include a master key from the second card 614.

Each account profile 602 may correspond to a payment profile 302 provided to a mobile device 104. As such, single-use keys 604 stored in an account profile 602 may correspond to single-use keys 306 stored in the corresponding payment profile 302 in relation to the same transaction account. The data can be similar, such that when an application cryptogram is generated by the transaction management server 102 or mobile device 104, the application cryptograms must match if the data is accurate and has not been tampered with, which can make possible the validation of the payment credentials presented by the mobile device 104.

In some embodiments, an account profile 602 may include a personal identification number (PIN) that corresponds to the personal identification number (PIN) 314 stored in the corresponding payment profile 302. In this embodiment, the personal identification number (PIN) 314 may be provided to the reception unit 202 of the transaction management server 102 in a secure message, such as a reception message provided by the mobile device 104, which is described in more detail later. In other embodiments, a card master key may be used in place of the personal identification number (PIN), such as the first card master key 612. In this mode, the processing unit 504 of the transaction management server 102 may be configured to generate a second session key 608 based on the master key of the second card 614 that corresponds to the second session key 310 generated by the device. mobile 104, using the single-use key 306 and the personal identification number (PIN) 314. In some cases, the second session key 608 may also be based on the corresponding one-time key 604. In these modalities, the algorithms for the generation of session keys and / or application cryptograms can ensure that the cryptograms generated by the mobile device 104 and the transaction management server 102 are corresponding, based on the data used therein. .

The first session key 606 can be used by the processing unit 504 of the transaction management server 102 to generate a first cryptogram of the application and the second session key 608 can be used to generate a second cryptogram of the application. In some embodiments, application transaction counter 610 can be used in generating one or more of the application session keys and / or cryptograms. The application transaction counter 610 may be a value corresponding to the payment transaction to be made, which is incremented or otherwise modified during each transaction. The application transaction counter 610 may correspond to the application transaction counter 312 stored in the corresponding payment profile 302 on the mobile device 104, such that its use can ensure that only one mobile payment application (MPA) 404 valid can possess the correct application transaction counter 312 to generate valid session keys and / or application cryptograms. Additional techniques may be employed to further enhance the security of the generation of the session key and / or the application cryptogram, such as unpredictable numbers and other techniques that will be apparent to those of skill in the relevant art.

Processing of payment transactions using the mobile device

Figure 7 illustrates a process for processing payment transactions carried out using mobile device 104 without a security element and using the generation and validation of two or more application cryptograms.

In step 702, transaction management server 102 may provide (for example, via transmission unit 506) the payment credentials 304 and other account data to mobile device 104, such as via a message. Remote Notification Service (RNS) is discussed in more detail later. In step 704, the receiving unit 202 of the mobile device 104 may receive the payment credentials 304 and other account data. In step 706, the processing unit 204 of the mobile device 104 may store the data in a payment profile 302 in the card database 208. The account data may include the payment credentials 304, one or more single-use keys 308 and any other suitable data, such as one or more of session keys 308 and 310.

At step 708, processing unit 204 may generate two application cryptograms to be used in conducting a payment transaction. In some embodiments, step 708 may be initiated by consumer 108, such as by prompting via input unit 214, placing mobile device 104 near point of sale 110 to initiate the transaction via communication of near field, or other suitable method. Generating the application cryptograms may include generating a first application cryptogram using the first session key 308 stored in the payment profile 302. The second application cryptogram can be generated using a second session key 310, It can be generated using a 306 one-time key and a 314 personal identification number (PIN). In some cases, consumer 108 may enter a personal identification number (PIN) code into mobile device 104 (eg, via input unit 214) prior to step 708 or during the initiation of step 708. In some cases modalities, one or both of the application cryptograms may also be generated using application transaction counter 312.

Once the application cryptograms have been generated, they, along with the payment credentials 304, can be transmitted to the issuer 106 via the point of sale 110, the acquirer 112 and the payment network 114. The payment credentials 304 and the application cryptograms may be received by sender 106 in step 710. In step 712, the transmission unit 206 of the mobile device 104 can transmit a transaction notification to the transaction management server 102. In step 714, the reception unit 502 of the transaction management server 102 can receive the notification of the transaction. The transaction notification may notify the transaction management server 102 that the mobile device 104 has initiated a payment transaction using the payment profile 302. In some cases, the transaction notification may include identifying information.

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

In step 718, the transmission unit 506 of the transaction management server 102 can transmit the generated application cryptograms to the sender 106, which can receive the cryptograms in step 718. In step 720, the sender 106 can validate the application cryptograms provided by mobile device 104 accompanying payment credentials 304.

The validation of the application cryptograms may include comparing the cryptograms supplied by the mobile device 104, with the application cryptograms generated and supplied by the transaction management server 102. Once the validation is carried out, then, in step 722, issuer 106 can process the transaction accordingly. Transaction processing may include approval of the payment transaction, for example, if one or both of the cryptograms are validated, or denial of the payment transaction, for example, if one or both of the cryptograms are determined to be invalid.

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

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

In step 802, payment credentials 304 and other account data can be transmitted to mobile device 104 by transmission unit 506 of transaction management server 102. In step 804, mobile device reception unit 202 104 can receive the payment credentials 304 and other account data, which can be stored in a payment profile 302 in step 806. In step 808, the processing unit 204 of the mobile device 104 can generate the two cryptograms from the applications, as discussed above, and can transmit the cryptograms, payment credentials 304, and other suitable data to the sender 106 (for example, by point of sale 110).

In step 810, the sender 106 may receive the cryptograms of the applications and any other suitable data that can be used by the sender 106 to validate the transaction data and / or the approval or denial process of the transaction. In step 812, sender 106 may submit a request for validation cryptograms to transaction management server 102. In some embodiments, the request may include the payment credentials 304 or other suitable data to be used by the transaction management server 102 in identifying the account profile 602 that will be used to generate the validation cryptograms. In one embodiment, the request may further include the two application cryptograms generated by mobile device 104 for validation.

In step 814, the reception unit 502 of the transaction management server 102 can receive the request for the cryptogram. In step 816, the processing unit 504 of the transaction management server 102 may generate the two applications of cryptograms to be used for validation, 10 as discussed above. In embodiments where the cryptogram request also includes the two cryptogram applications generated by the mobile device 104, step 816 may also include validation of the two cryptograms by the processing unit 504 using the two cryptograms from the 15 applications just recently. generated. The validation cryptograms, or the result of the validation in applicable modes, can be transmitted by the transmission unit 506 to the sender 106. In step 818, sender 106 can receive the validation cryptograms and / or the validation result.

In step 820, the sender 106 can validate the application cryptograms provided by the mobile device 104 using the application cryptograms generated by the transaction management server 102. In embodiments the transaction management server 102 provides a result 25 of the validation to the sender 106, step 820, the identification of the result of the validation of each of the two cryptograms of the applications can be included. In step 822, issuer 106 may process the payment transaction accordingly based on the result of the validation. In step 824, transaction notifications can be transmitted to transaction management server 102 and mobile device 104, received by respective receiving units 502 and 202 in steps 826 and 828, respectively.

Remote notification and data messaging service

Figure 9 illustrates a process for the transmission and validation of remote notification service (RNS) messages and other data messages transmitted from the transaction management server 102 to the mobile device 104. The notification service messages Remotely (RNS) can be transmitted by means of a remote notification service, such as one that uses a mobile communication network associated with mobile device 104. Remote Notification Service (RNS) messages can be used for payment disposition credentials 304 and other account data to mobile device 104, such as account data used in processing payment transactions, as shown discussed above and other information that can be used in establishing a secure connection between mobile device 104 and transaction management server 102.

In step 902, the processing unit 504 of the transaction management server 102 may generate a message. In cases where mutual authentication with mobile device 104 has been established, the message may include information suitable for establishing mutual authentication, such as a session identifier. In other cases, such as when mutual authentication has been established between transaction management server 102 and mobile device 104 using the process illustrated in Figure 9 and discussed herein, the generated message may include the credentials of the Payment 304 and account data may include one or more commands to be executed by the mobile payment application (MPA) 404 of the mobile device 104 (for example, the removal of one-time keys 306 or payment credentials 304, etc.), may be notifications to be presented to the consumer 108 (eg, account balances, payment notifications, etc.), or include other suitable data.

In step 904, processing unit 504 may encrypt the generated message. The message can be encrypted using a private key from a private / public key pair, where the mobile device 104 can possess a corresponding public key. In some cases, the message may be encrypted using an encryption key associated with mobile device 104 or mobile payment application (MPA) 404, such as key encryption 414. At step 906, processing unit 504 may generate an authentication code for the message. The message authentication code can be generated by the encrypted message and can be a key that is generated using one or more specially configured rules and / or algorithms. For example, the message authentication code can be generated using one or more encryption and obfuscation methods, such as padding. In some embodiments, the message authentication code can be generated using the encryption key.

In step 908, the transmission unit 506 of the transaction management server 102 may transmit a combined data message to the mobile device 104. In embodiments where mutual authentication may be in progress, the combined data message may be a message from the remote notification service transmitted to the mobile device 104 via the remote notification service. The combined data message may be received by the receiving unit 202 of the mobile device 104 at step 910 and may include the message authentication code and the encrypted message. In some cases, the combined data message may also include an additional identifier, such as one generated using the methods known to the mobile payment application (MPA) 404 for verification thereof. In some cases, such as when mutual authentication has already been performed, the combined data message may also include a message counter.

In step 912, the processing unit 204 may generate a reference authentication code. The reference authentication code can be generated using the received encrypted message and can be generated using the same rules and algorithms as the transaction management server 102 used to generate the message authentication code, such that the authentication code of The generated reference would correspond to the message authentication code, if the message authentication code is generated by a trusted source (for example, the transaction management server 102). In the embodiments in which the message authentication code can be generated using the encryption key, the processing unit 204 may generate the reference authentication code using the encryption of key 414 stored in memory 212 or another encryption key. adequate.

In step 914, the processing unit 204 may validate the message authentication code included in the received combined data message by comparing it against the generated reference authentication code. If both the message counter and the authentication code of the message are validated, then the combined data message can be determined to be trustworthy (eg, authentic) as from the transaction management server 102. In cases where the combined data message may include a message identifier, the processing unit 204 may also validate the message identifier by generating a message identifier using a process known to the mobile payment application (MPA). 404 for their generation and comparison. In embodiments in which the combined data message may include a message counter, the processing unit 204 may validate the message counter included in the received combined data message with a reference counter stored in the mobile device 104, such as as in the mobile payments application (MPA) 404 or in a payment profile 502.

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

In some embodiments, mobile device 104 may be configured (for example, via mobile payments application (MPA) 404) to generate and send a message back to transaction management server 102. In some cases, the Return message may include data generated in response to actions performed as indicated in the decrypted message, as discussed above. For example, a return message may indicate the valid receipt and storage of payment credentials 304 or single-use keys 306. In other cases, the response message may be a receipt and validation notification of the combined data message. In cases where mutual authentication is performed first, the return message may include the session identifier used to perform mutual authentication.

Figures 10A and 10B illustrate a process for the generation and transmission of a response message by the mobile device 104 and the validation thereof by the transaction management server 102.

In step 1002, the processing unit 204 of the mobile device 104 may generate a receive message. The receive message can be generated from the program code 406 stored in the mobile payment application (MPA) 404 and can further be based on the actions carried out as indicated in a decrypted combined data message received from the payment server. transaction management 102. For example, the receipt message may include a payment credential receipt and storage notification 304. In step 1004, processing unit 204 may increment a receipt counter. The reception counter may be a counter indicative of the number of transmission confirmation messages to the transaction management server 102. The reception counter can be stored in memory 212, as in mobile payment application (MPA) 404, or in an encrypted database using the advanced storage key. It will be apparent to those of skill in the relevant art that step 1004 may be an optional step and can only be used in cases where a counter is used for the validation of a data message.

In step 1006, processing unit 204 may encrypt the receive message. The confirmation message can be encrypted using encryption key 414 stored in cryptographic application 410, or else it can be stored in mobile payment application (MPA) 404 or in a locally encrypted database. The encryption key used to encrypt the receiving message may be a private key as part of a key pair, with the transaction management server 102 having a corresponding public key. In step 1008, the processing unit 204 may generate a reception authentication code based on the encryption confirmation message. In some embodiments, the receipt authentication code can be generated using the same rules, algorithms, and / or processes, that are used to generate the reference authentication code that is illustrated in step 912 of Figure 9, discussed above. .

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 receipt unit 502 of the receipt management server. transactions 102 and may include at least the receipt authentication code, the encryption confirmation message, and the receipt counter. In some embodiments, the receipt notification message can be transmitted to the transaction management server 102 using a mobile communication network, such as a cellular network, associated with the mobile device 104.

In step 1014, the processing unit 504 of the transaction management server 102 may increment a confirmation counter. The confirmation counter may be indicative of the number of messages received from the mobile device 104, which is used for validation of the messages received from the mobile device 104. The confirmation counter may be stored in memory 510 of the management server. transactions 102 or other suitable data stores. For example, in some embodiments, the confirmation counter may be stored in an account profile 602 associated with the mobile device 104. In one example, each profile account 602 may include a confirmation counter (eg and / or a counter of messages) to be used for messages transmitted to / from the transaction management server 102 and the mobile device 104 in connection with the corresponding transaction account. It will be apparent to those skilled in the art that step 1014 may be an optional step and cannot be performed in cases where a counter cannot be used for validation of the return messages.

At step 1016, processing unit 504 may generate a confirmation authentication code. The confirmation authentication code can be generated based on the encryption confirmation message included in the receipt notification message and can be generated using the same rules, algorithms and / or processes used to generate the message authentication code. In step 1018, the processing unit 504 may validate the reception counter included in the reception notification message by comparison with the confirmation counter. In step 1020, the processing unit 504 can validate the receipt authentication code by comparing it to the message authentication code, to ensure that the message originated from an authorized mobile device 104.

Once the counter (eg, if applicable) and the authentication code have been validated, then, in step 1022, the processing unit 504 can decrypt the encrypted message included in the receipt notification message. The encrypted message can be decrypted using a stored encryption key or other suitable decryption method. The encrypted message can be decrypted to obtain the received message generated by the mobile device 104. In step 1024, the processing unit 504 can take all appropriate actions as necessary based on the data included in the receive message. For example, if the receipt message includes a successful one-time key 306 receipt and storage indication, the processing unit 204 may activate the corresponding one-time keys 604 in a corresponding account profile 602.

Data message validation

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

In step 1102, the processing unit 204 of the mobile device 104 can store the encryption keys, the authentication generation keys and the rules and / or algorithms for the use and application of the same in local storage, such as memory. 212 or encrypted storage locally encrypted using an advanced storage key. In step 1104, the receiving unit 202 of the mobile device 104 may receive a data message from the transaction management server 102. In some embodiments, the data message may be received from the transaction management server 102 following the establishing mutual authentication between the two devices, such as using the process illustrated in Figure 9 and discussed above. The data message may include at least a message counter, a message authentication code, and an encrypted message.

At step 1106, processing unit 204 may increment a reference counter. The reference counter can be stored in memory 212 or other local storage and can be used to indicate the number of messages received from the transaction management server 102. In some cases, the reference counter may be incremented by an algorithm, so that the reference counter cannot be incremented using consecutive numbers, but by means of an algorithm known to the mobile device 104 (for example, by means of the mobile payment application (MPA) 404) and the transaction management server 1 02.

In step 1108, the processing unit 204 may validate the message counter that is included in the received data message. The validation of the message counter may include comparing the message counter to the reference value counter after it has been incremented. The validation error may indicate that the source of the data message is not the transaction management server 102 or is otherwise not trusted. If the validation fails, then, in step 110, the processing unit 204 may perform one or more appropriate actions associated with a failed data receipt and / or validation message. For example, the processing unit 204 may discard the data message, it may notify the transaction management server 102, it may block the associated payment profile 302, or other action that will be apparent to those of skill in the relevant art.

If the message counter validation passes, then process 1100 can proceed to step 1112, where the encrypted message can be filled out. The padding of the encrypted message may include the addition of values ​​for the encrypted message or associated data thereof. Padding can be used to increase the security of the message validation process, because there may be another function that must be performed by mobile device 104 and transaction management server 102 known to each, which would have to be replicated. by an unauthorized entity for the purpose of successfully transmitting or receiving a data message without authorization. It will be apparent to those of skill in the relevant art that step 1112 may be an optional step. In some embodiments, step 1112 may be applied in some instances of the 1110 process. For example, the encrypted message may be aligned in certain reference counter increments.

In step 1114, processing unit 204 may generate a reference authentication code. The reference authentication code can be generated based on the encrypted message (eg, as padding, if applicable) by one or more rules or algorithms, such as stored in step 1102. In some embodiments, the authentication code The reference may be a key or it may be a value generated by the application of a key to the encrypted message. In step 1116, the processing unit 204 may validate the authentication code of the receive message in the remote notification service (RNS) message. Validation of the message authentication code may include comparing the code with the generated reference authentication code, as another method of identifying whether the received data message originated from an authorized source (for example, the server transaction management 102).

If the validation of the message authentication code fails, the process 1100 can proceed to step 1110 where the failure processing is performed. If validation of the message authentication code passes later in 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, as stored in mobile device 104 at step 1102. For example, encryption of key 414 stored in the application can be used. cryptographic 410 of memory 212 to decrypt the encrypted message. In step 1120, processing unit 204 may perform one or more actions, as appropriate depending on the content of the decrypted message. For example, if the decrypted message includes one-time keys 306, the one-time keys 306 can be stored in the appropriate payment profile 302 of the card database 208, which can therefore be encrypted using the advanced storage key.

Advanced storage keys

Figure 12 illustrates the generation and use of the advanced storage key by mobile device 104 for the secure storage of data on mobile device 104, such as payment profiles 302 and other data that can be safely stored. and to access the mobile device 104 without the use of security features.

Device information 402 stored in memory 212 of mobile device 104 may include three or more pieces of device information 1202, which is illustrated in FIG. 12 as device information 1202a, 1202b, and 1202c. Each piece of information from device 1202 may be associated with mobile device 104. In some cases, each piece of information from device 1202 may be unique to mobile device 104. In other cases, one or more of the pieces of information from device 1202 may not be unique to mobile device 104 (eg, a model number), but the three pieces of information from device 1202 when taken together may be unique. for mobile device 104 (eg, a unique combination). The pieces of information in device 1202 may be data that will not change for the life of mobile device 104.

Processing unit 204 of mobile device 104 may generate a fingerprint of mobile device 1204 based on the three pieces of device information 1202a, 1202b, and 1202c. The fingerprint of the mobile device 1204 can be a unique value for the mobile device 104 and can be generated from one or more rules or algorithms stored in the memory 212, as included in the code of the program 406 of the payment application mobile (MPA) 404. The mobile fingerprint device 1204 can be, for example, a numeric value, a hexadecimal value, a character string, etc.

The processing unit 204 can also be configured to generate a diversification value 1208 using the fingerprint of the mobile device 1204. The diversification value can be generated by combining the fingerprint of the mobile device 1204 with the identifier of the instance 408 of the mobile payment application (MPA) 404, as well as a random value 1206. Random value 1206 may be a random or pseudo-random number generated by processing unit 204. In some cases, random value 1206 may be generated in accordance with one or more rules or algorithms stored in memory 212. The combination of the fingerprint of the mobile device 1204, the identifier of the instance 408 and the random value 1206 can also be performed using one or more rules or algorithms, such as that stored in the code of the program 406 of the mobile payment application ( MPA) 404. Using the instance identifier 408 to generate the diversified value can result in the ability to securely store the data associated with one instance of the mobile payments application (MPA) 404 such that multiple installations of the application Mobile Payment Application (MPA) 404 may be unable to access data stored by other instances of the Mobile Payment Application (MPA) 404.

The processing unit 204 may then generate an advanced storage key 1210 by applying the encryption of key 414 stored in the cryptographic application 410 to the diversification value 1208. In some cases, the advanced storage key 1210 may be generated by the decryption of the diversification value 1208 using the encryption key 414. In other cases, the advanced storage key 1210 may be a value resulting from the encryption of the diversification value 1208 using the key encryption 414. In some embodiments, the advanced storage key 1210 may be generated as the result of performing the cryptography of white-box using encryption key 414 and diversification value 1208.

Once the advanced storage key 1210 has been generated, the processing unit 204 may use the advanced storage key 1210 to encrypt a local database 1210. The local database 1210 may be composed of, for example, the card database 208, one or more payment profiles 302, part of memory 212, or other suitable data source. In some cases, the local database 1210 may be a part of another database on the mobile device 104, such as the card database 208. For example, the card database 208 may include a plurality of of local databases 1212, such as a separate local database 1212 for each instance of the mobile payment application (MPA) 404 to store the payment for the same associated profiles 302. The resulting encrypted local database 1214 can securely store data that is inaccessible by any other internal or external application program of the mobile device 104, except the specific instance of the mobile payment application (MPA). 404 that includes the 408 instance identifier. Consequently, the local encrypted database 1214 can be ideal for storing payment credentials 304, one-time keys 306 and other account data and can provide secure storage of sensitive account information without the use of items of security.

In some embodiments, the storage key can also be used by the transaction management server 102 to provide encrypted data to the mobile device 104 for storage in the encrypted local database 1214. For example, the device's transmission unit 206 mobile 104 can transmit the generated random value 1206 to transaction management server 102. In some cases, instance identifier 408 may also be transmitted to transaction management server 102, or may be previously owned by transaction management server 102, such as during mobile payment application (MPA) registration. 404. The transaction management server 102 can then generate the advanced storage key 1210 by itself, encrypt the data to be provided to the mobile device 104, such as payment credentials 304, one-time keys 306, etc. using advanced key storage 1210 and then transmitting the encrypted data to mobile device 104. Mobile device 104 can then store the already encrypted data in encrypted local database 1214.

First example method to generate payment credentials in a payment transaction

Figure 13 illustrates a method 1300 for the generation of payment credentials in a payment transaction, including the use of two application cryptograms for the secure use of the payment credentials in a mobile device 104 without a security element.

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

At step 1306, a first session key (eg, first session key 308) may be identified by a processing device (eg, processing unit 204). At step 1308, a second session key (eg, second session key 310) may be generated by processing device 204 based on at least usage of the stored individual key 306 and personal identification number ( PIN) received.

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

In step 1314, at least the first application cryptogram and the second application cryptogram can be transmitted by a transmission device (eg, transmission unit 206) for use in a payment transaction. In some embodiments, the first application cryptogram and the second application cryptogram may be transmitted to a point of sale device (eg, point of sale 110). In one embodiment, method 1300 may include, in addition to storing, in memory 302, a key from the main card associated with the transaction account, wherein the identification of the first session key 308 includes generation, by the device processing 204, the first session key 308 based on at least the master key of the stored card.

In some embodiments, the method 1300 may include in addition to storage, in memory 302, an application transaction counter (eg, application transaction counter 312), wherein the identification of the first session key 308 includes generating, by processing device 204, the first session key 308 based on at least the storage transaction application counter 312. In one embodiment, method 1300 may further include validating, by processing device 204, the personal identification number (PIN) received prior to generating second session key 310. In a further embodiment, processing device 204 is You can configure to generate a second invalid session key 310 if validation of the received personal identification number (PIN) fails.

Second example method to generate payment credentials in a payment transaction

Figure 14 illustrates a method 1400 for the generation of the payment credentials in a payment transaction, including the use of two validations of the application cryptograms of the payment credentials generated by a mobile device 104 without the use of an element of security.

In step 1402, at least one card master key (eg, first card master key 612) may be stored in memory (eg, profile account 602) associated with a 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 master card key 612 stored. At step 1406, a second session key (eg, second session key 608) may be generated by processing device 504.

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

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

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

Example method to process a data message

Figure 15 illustrates a method 1500 for processing a data message, such as a remote notification message received by means of a remote notification service, including receiving and validating the same by a mobile device 104 without use a security item.

In step 1502, at least one encryption key can be stored in a memory (eg, memory 212). In some embodiments, memory 212 may be an insecure memory element of a mobile communication device (eg, mobile device 104). In step 1504, a data message may be received by a receiving device (eg, receiving unit 202), wherein the data message may include at least one encrypted message and a message authentication code, wherein the message authentication code is generated using at least a portion of the encrypted message. In some embodiments, the data message may be a remote notification service message received by means of a remote notification service.

In step 1506, a reference authentication code can 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, the memory 212 may further include one or more authentication code generation rules and the reference authentication code may be generated based on applying the one or more stored authentication code generation rules to the part of the encrypted message included in the received data message. At step 1508, the received data message may be validated by processing device 204 based on a check of the authentication code of the message included in the received data message against the generated reference authentication code. In some embodiments, the memory may further include a reference counter, the received data message may further include a message counter, and the received data message may be further validated by processing device 204 based on a check of the counter. messages included in the data message received at the stored reference counter.

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

In one embodiment, method 1500 may further include transmitting, by a transmitting device (eg, transmitting unit 206), a receipt notification in response to the received data message. In a further embodiment, process 1500 may even further include: performing, by processing device 204, one or more actions based on the decrypted message; generating, via processing device 204, a response message as a result of or based on the one or more actions performed; encrypting, by processing device 204, the generated return message using the stored encryption key to obtain an encrypted response message; and generating, by means of the processing device 204, a return authentication code using at least a part of the encrypted response message, wherein the transmission receipt notification includes the encrypted return message and the return authentication code. . In a still further embodiment, memory 212 may further include a return counter and the transmitted receipt notification may further include the return counter.

In some embodiments, method 1500 may also include padding, via processing device 204, the encrypted message included in the received data message using a padding key, wherein the portion of the encrypted message used to generate the authentication code reference is the padding of the encrypted message. In a further embodiment, the fill key can be the encryption key. In yet another form of embodiment, memory 212 may further include a padding authentication code algorithm and padding of the encrypted message using the padding key may include padding of the encrypted message based on the application of the padding key to the authentication code padding algorithm.

Example method for building an advanced storage key

Figure 16 illustrates a method 600 for constructing an advanced storage key for secure encryption and storage of local data in a mobile device 104 without using a security element.

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

In some embodiments, the device 402 information 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 an instance of the first application program 404. In some embodiments, the second application program 410 may be configured to perform white-box cryptography using the first key. In one embodiment, the first key can 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 additional embodiments, the second application program 410 may be an executable function of the first application program 404.

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

At step 1608, a diversification value (eg, diversification value 1208) can be constructed by processing device 204 based on at least the fingerprint generated by device 1204, generated random value 1206, and the instance identifier 408 included in the code program 406 associated with the first application program 404. At step 1610, the constructed diversification value 1208 can be decrypted by processing device 204 using the first key stored in program code 412 associated with the second application program.

410 by executing the program code 412 associated with the second application program 410 to obtain a storage key (eg, advanced storage key 1210).

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

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

Computer system architecture

Figure 17 illustrates a computer system 1700 wherein the embodiments of the present disclosure, or portions thereof, may be implemented as computer-readable code. For example, the transaction management server device 102 and mobile 104 of FIG. 1 can be implemented in the computer system 1700 using hardware, software, firmware, computer instructions having non-transient readable media stored therein, or a combination thereof and can be implemented in one or more computer systems or other processing systems. Hardware, software, or any combination thereof can incorporate modules and components used to implement the methods of Figures 7, 8, 9A, 9B, 10A, 10B, 11 and 13 to 16.

If programmable logic is used, such logic can be run on a commercially available processing platform or special purpose device. One of ordinary skill in the art may appreciate that the modalities of the subject matter described can be practiced with various computer system configurations, including multiprocessor multi-core systems, minicomputers, mainframes, linked or clustered computers with distributed functions, as well as penetrating or miniature computers that can be embedded in virtually any device. For example, at least one processor device and memory can be used to implement the modalities described above.

A processor unit or memory device, as discussed herein, can be a single processor, a plurality of processors, or combinations thereof. Processor devices can have one or more processor cores. The terms computer program medium, non-transient computer-readable medium, and usable equipment medium as discussed herein are used to refer generally to tangible media, such as a removable storage drive 1718, a removable storage drive 1722 and a hard drive installed in hard drive 1712.

The various embodiments of the present disclosure are described in terms of this example 1700 computer system. After reading this description, it will become apparent to one of skill in the relevant art how to implement the present disclosure using other computer systems and / or computer architectures. . Although the transactions can be described as a sequence process !, some of the transactions, in reality, can be carried out concurrently and / or in a distributed environment and with parallel code, program stored locally or remotely for access of individual machines or multiple processors. Furthermore, in some modalities the order of transactions can be reordered without departing from the spirit of the disclosed matter.

Processor device 1704 may be a general purpose or special purpose processor device. Processor device 1704 may be connected to a communication infrastructure 1706, such as a bus, message queue, the network, multi-core message passing scheme, etc. The network can be any network suitable to carry out the functions as described herein and can include a local area network (LAN), a wide area network (WAN), a wireless network (eg, WiFi) , a mobile communication network, a satellite network, the Internet, fiber optics, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to those of skill in the relevant art. The computer system 1700 may also include a main memory 1708 (eg, random access memory, read-only memory, etc.) and may also include a secondary memory 1710. Secondary memory 1710 may include hard drive 1712 and removable storage drive 1714, such as floppy drive, magnetic tape drive, optical disc drive, flash memory, and so on.

Removable storage unit 1714 can read and / or write to removable storage unit 1718 in a well known manner. Removable storage drive 1718 may include removable storage media that can be read by and written to removable storage drive 1714. For example, if removable storage drive 1714 is a floppy drive or universal serial bus port, removable storage drive 1718 can be a floppy or portable flash drive, respectively. In one embodiment, removable storage drive 1718 may be a non-transient computer-readable recording medium.

In some embodiments, secondary memory 1710 may include alternative means to allow computer programs or other instructions to be loaded into computing system 1700, for example, removable storage unit 1722 and an interface 1720. Examples of such media may include a cartridge and program cartridge interface (eg, as found in video game systems), a removable memory chip (eg, EEPROM, PROM, etc.), and the associated plug. and other removable storage units 1722 and interfaces 1720, as will be apparent to those skilled in the relevant art.

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

The computer system 1700 may also include a communication interface 1724. The communication interface 1724 may be configured to allow software and data to be transferred between the computer system 1700 and external devices. Examples of 1724 communications interfaces may include a modem, a network interface (for example, an Ethernet card), a communications port, a PCMCIA slot and card, and so on. The software and data transferred via the communications interface 1724 can be in the form of signals, which can be electronic, electromagnetic, optical, or other signals, as will be apparent to those with experience in the relevant art. The signals can travel via a communications path 1726, which can be configured to carry the signals and can be implemented using wire, cable, fiber optics, a telephone line, a cellular telephone link, a radio frequency link, etc.

The 1700 computer system may further include a display interface 1702. The 1702 display interface can be configured to allow data to be transferred between the 1700 computer system and the 1730 external display. Example 1702 may include High Definition Multimedia Interface (HDMI), Digital Visual Interface (DVI), Video Graphics Matrix (VGA), etc. The 1730 display can be any type of display suitable for displaying data transmitted via the 1700 computer system display interface 1702, including a cathode ray tube (CRT), liquid crystal display (LCD), and light emitting diodes (LEDs), capacitive touch screen, thin film transistor (TFT), etc.

Computer program medium and computer usable medium may refer to memories, such as main memory 1708 and secondary memory 1710, which may be memory semiconductors (eg, DRAM, etc.). These computer program products can be means of providing software to the 1700 computer system. Computer programs (eg, computer control logic) can be stored in main memory 1708 and / or memory 1710. Secondary computer programs can also be received via communications interface 1724. Such programs Computer systems, when run, can allow the 1700 computer system to implement the present methods as discussed herein. In particular, computer programs, when run, may allow processor device 1704 to implement the methods illustrated by Figures 7, 8, 9A, 9B, 10A, 10B, 11, and 13 through 16, as discussed herein. document. Consequently, such computer programs can represent the controllers of the 1700 computer system. When the present disclosure is implemented using software, the software may be stored in a computer program product and loaded into the 1700 computer system using the 1714 removable storage unit, 1720 interface, and 1712 hard disk drive, or communications interface 1724.

The techniques in accordance with what is provided in this disclosure, among other characteristics, the systems and methods for the processing of payment transactions using a mobile device without the need to use a security element, including the transmission and validation of messages from the service of remote notification and secure data storage using an advanced storage key. While different embodiment examples of the disclosed system and method have been described above, it should be understood that they have been presented for purposes of example only, not limitations. It is not exhaustive and does not limit the disclosure to the precise manner described. Modifications and variations are possible in light of the above teachings or may be acquired from the practice of the disclosure, without departing from the scope or scope of application.