Method and system for secure tranmission of remote notification service messages to mobile devices without secure elements
18 claims: 11 independent, 7 dependent
- 1データメッセージを受信および処理するための方法であって、 少なくとも暗号鍵をメモリに格納することと、 暗号化されたメッセージと、当該暗号化されたメッセージの一部を少なくとも使用して生成されたメッセージ認証コードとを少なくとも有するデータメッセージを受信装置により受信することと、 前記受信されたデータメッセージに含まれている前記暗号化されたメッセージの前記一部を少なくとも使用して参照認証コードを処理装置により生成することと、 前記受信されたデータメッセージに含まれている前記メッセージ認証コードの前記生成された参照認証コードに対するチェックに基づいて前記受信されたデータメッセージを前記処理装置により検証することと、 前記受信されたデータメッセージの検証が成功した場合に、前記受信されたデータメッセージの検証の成功した直後に、復号されたメッセージを取得するために前記格納された暗号鍵を使用して、前記受信されたデータメッセージに含まれている前記暗号化されたメッセージを前記処理装置により復号することと、 前記復号されたメッセージに基づいて一つ以上のアクションを前記処理装置により実行することと、 前記実行された一つ以上のアクションの、または、に基づく結果であるリターンメッセージを前記処理装置により生成することと、 暗号化されたリターンメッセージを取得するために前記格納された暗号鍵を使用して前記生成されたリターンメッセージを前記処理装置により暗号化することと、 前記暗号化されたリターンメッセージの一部を少なくとも使用して前記処理装置によりリターン認証コードを生成することと、 前記受信されたデータメッセージに応答して受信通知を送信装置により送信することと、を有し、 前記送信される受信通知は前記暗号化されたリターンメッセージと前記リターン認証コードとを有し、 前記暗号化されたメッセージの前記一部は、前記暗号化されたメッセージの復号の前に、前記参照認証コードを生成するために使用され 、 前記データメッセージは遠隔通知サービスを介して受信される遠隔通知サービスメッセージであり、 前記方法は、さらに、 パディング鍵を使用して、前記受信された遠隔通知サービスメッセージに含まれている前記暗号化されたメッセージを前記処理装置によりパディングすることを有し、 前記参照認証コードを生成するために使用される前記暗号化されたメッセージの前記一部は、前記パディングされた、暗号化されたメッセージであり、 前記パディング鍵は前記暗号鍵である、 方法。
- 2請求項1に記載の方法であって、 前記メモリは、参照カウンタを格納するようにさらに構成されており、 前記受信されたデータメッセージを検証することは、前記格納されている参照カウンタに対して前記受信されたデータメッセージに含まれているメッセージカウンタをチェックすることをさらに有する、方法。
- 3請求項1に記載の方法であって、 前記メモリはさらにリターンカウンタを有し、 前記送信される受信通知は前記リターンカウンタをさらに有する、方法。
- 4請求項1に記載の方法であって、 前記メモリはさらに一つ以上の認証コード生成ルールを有し、 前記参照認証コードは、前記格納されている一つ以上の認証コード生成ルールを、前記受信されたデータメッセージに含まれている前記暗号化されたメッセージの前記一部に対して適用することに基づいて生成される、方法。
- 5請求項 1 に記載の方法であって、 前記メモリはさらに認証コードパディングアルゴリズムを有し、 前記パディング鍵を使用して前記暗号化されたメッセージをパディングすることは、前記認証コードパディングアルゴリズムに対して前記パディング鍵を適用することに基づいて前記暗号化されたメッセージをパディングすることを有する、方法。
- 6請求項1に記載の方法であって、さらに、 一つ以上のデータフォーマット化ルールに基づいて前記復号されたメッセージのデータフォーマットを前記処理装置によりチェックすることをさらに有する、方法。
- 7請求項1に記載の方法であって、前記復号されたメッセージは、支払取引に使用されるデジタル化されたカードプロファイルと使い捨て鍵とのうち少なくとも一つを有する、方法。
- 8請求項1に記載の方法であって、前記参照認証コードは、さらに、前記格納された暗号鍵を使用して生成される、方法。
- 9請求項1に記載の方法であって、前記メモリは、移動通信装置内の非セキュアエレメントメモリである、方法。
- 10データメッセージを受信および処理するためのシステムであって、 プロセッサに接続され、暗号鍵を少なくとも格納するように構成されたメモリと、 暗号化されたメッセージと、当該暗号化されたメッセージの一部を少なくとも使用して生成されたメッセージ認証コードとを少なくとも有するデータメッセージを受信するように構成された受信機と、 前記受信されたデータメッセージに含まれている前記暗号化されたメッセージの前記一部を少なくとも使用して参照認証コードを生成し、 前記受信されたデータメッセージに含まれている前記メッセージ認証コードの前記生成された参照認証コードに対するチェックに基づいて前記受信されたデータメッセージを検証し、 前記受信されたデータメッセージの検証が成功した場合に、前記受信されたデータメッセージの検証の成功した直後に、復号されたメッセージを取得するために前記格納された暗号鍵を使用して前記受信されたデータメッセージに含まれている前記暗号化されたメッセージを復号し、 前記復号されたメッセージに基づいて一つ以上のアクションを実行し、 前記実行された一つ以上のアクションの、または、に基づく結果であるリターンメッセージを生成し、 暗号化されたリターンメッセージを取得するために前記格納された暗号鍵を使用して前記生成されたリターンメッセージを暗号化し、 前記暗号化されたリターンメッセージの一部を少なくとも使用してリターン認証コードを生成するように構成された前記プロセッサと、 前記受信されたデータメッセージに応答して受信通知を送信するように構成された送信装置と、を有し、 前記受信通知は前記暗号化されたリターンメッセージと前記リターン認証コードとを有し、 前記暗号化されたメッセージの前記一部は、前記暗号化されたメッセージの復号の前に、前記参照認証コードを生成するために使用され 、 前記データメッセージは遠隔通知サービスを介して受信される遠隔通知サービスメッセージであり、 前記プロセッサは、パディング鍵を使用して、前記受信された遠隔通知サービスメッセージに含まれている前記暗号化されたメッセージをパディングするようにさらに構成され、 前記参照認証コードを生成するために使用される前記暗号化されたメッセージの前記一部は、前記パディングされた、暗号化されたメッセージであり、 前記パディング鍵は前記暗号鍵である、 システム。
- 11請求項 10 に記載のシステムであって、 前記メモリは、参照カウンタを格納するようにさらに構成されており、 前記受信されたデータメッセージを検証することは、前記格納されている参照カウンタに対して前記受信されたデータメッセージに含まれているメッセージカウンタをチェックすることをさらに有する、システム。
- 12請求項 10 に記載のシステムであって、 前記メモリはさらにリターンカウンタを有し、 前記送信される受信通知は前記リターンカウンタをさらに有する、システム。
- 13請求項 10 に記載のシステムであって、 前記メモリはさらに一つ以上の認証コード生成ルールを有し、 前記参照認証コードは、前記格納されている一つ以上の認証コード生成ルールを、前記受信された遠隔通知サービスメッセージに含まれている前記暗号化されたメッセージの前記一部に対して適用することに基づいて生成される、システム。
- 14請求項 10 に記載のシステムであって、 前記メモリはさらに認証コードパディングアルゴリズムを有し、 前記パディング鍵を使用して前記暗号化されたメッセージをパディングすることは、前記認証コードパディングアルゴリズムに対して前記パディング鍵を適用することに基づいて前記暗号化されたメッセージをパディングすることを有する、システム。
- 15請求項 10 に記載のシステムであって、前記プロセッサは、一つ以上のデータフォーマット化ルールに基づいて前記復号されたメッセージのデータフォーマットをチェックするようにさらに構成されている、システム。
- 16請求項 10 に記載のシステムであって、前記復号されたメッセージは、支払取引に使用されるデジタル化されたカードプロファイルと使い捨て鍵とのうち少なくとも一つを有する、システム。
- 17請求項 10 に記載のシステムであって、前記参照認証コードは、さらに、前記格納された暗号鍵を使用して生成される、システム。
- 18請求項 10 に記載のシステムであって、前記メモリは、移動通信装置内の非セキュアエレメントメモリである、システム。
Independent claims18
144 paragraphs, as filed
The disclosure of the present application relates to the secure transmission of a remote notification service message to a mobile device without the use of a secure element, in particular for the secure transmission, reception and processing of a remote notification service message without the use of a secure element. Regarding encryption and the use of authorization codes.
Advances in mobile phone and communication technologies have created enormous opportunities. One is that users of mobile computing devices can use their mobile devices to initiate and pay payment transactions. One such method that enables such operation on mobile devices is near field communication, which secures payment details and sends them from mobile devices to nearby point-of-sale POS (POS) terminals. To use (NFC) technology. To achieve this, mobile phones with secure element hardware such as secure element (SE) chips are used to secure and store payment certificates. A secure element is a special element that may be included in some NFC-enabled devices and is a tamper resistant platform that may secure and host applications and their sensitive data.
However, not all mobile devices have secure elements. In addition, some financial institutions do not have access to the secure element on the mobile device, even if the mobile device implements the secure element. As a result, many consumers with mobile devices with the hardware needed to perform contactless or other types of remote payment transactions may not actually be able to use the feature. Such problems require technical solutions that allow mobile computing devices to initiate and execute payment transactions without the use of secure elements.
Several methods and systems for performing payment transactions without secure elements on mobile devices that do not have secure elements or implement secure elements are described by Mehdi Collinge et al., March 14, 2013. It can be found in US Patent Application No. 13 / 827,042, "Systems and Methods for Processing Mobile Payments by Provisioning Credentials to Mobile Devices Without Secure Elements," which was filed on the same day and which is incorporated herein by reference in its entirety. Such methods and devices may be suitable for performing payment transactions via mobile devices without the use of secure elements, as many consumers, traders and financial institutions require greater security. You may be wary of participating in such transactions.
Therefore, there is a technical solution that enhances the security of receiving and storing payment certificates on mobile devices that do not have a secure element, and enhances the security of sending payment certificates from mobile devices to POS while conducting financial transactions. Needed. By improving security in their processing, you can increase the peace of mind of all the entities involved, resulting in increased use of mobile devices for non-contact or remote payment transactions, more than traditional payment methods. Profit can be provided to consumers.
The disclosure of the present application provides a description of systems and methods for processing remote notification service messages.
A method for receiving and processing data messages, at least storing the encryption key in memory, and the encrypted message and the message generated using at least a portion of the encrypted message. A data message having at least an authentication code is received by the receiving device, and a reference authentication code is generated by the processing device using at least a part of the encrypted message contained in the received data message. The processing device verifies the received data message based on the check of the generated reference authentication code of the message authentication code included in the received data message, and decrypts the data message. The processing device decrypts the encrypted message contained in the received data message by using the stored encryption key in order to acquire the message.
A system for receiving and processing data messages, which includes a memory, a receiving device, and a processing device. The memory is configured to store at least the encryption key. The receiving device is configured to receive a data message having at least an encrypted message and a message authentication code generated using at least a portion of the encrypted message. The processing device generates a reference authentication code by using at least a part of the encrypted message contained in the received data message, and the message authentication included in the received data message. The received data message is verified using the stored encryption key to retrieve the decrypted message based on the check of the code against the generated reference authentication code. It is configured to decrypt the contained encrypted message.
The scope of the invention is best understood by reading the following detailed description of exemplary embodiments in connection with the accompanying drawings. The figures included in the drawings are shown below.<figref num="1">FIG. 1 is a block diagram showing a higher-level system architecture for processing payment transactions with a high degree of security in providing and storing payment certificates according to an exemplary embodiment.</figref><figref num="2">FIG. 2 is a block diagram showing a mobile device of FIG. 1 that processes payment transactions and secures payment certificates to receive and store payment certificates without using the secure element according to the exemplary embodiment.</figref><figref num="3">FIG. 3 is a block diagram showing a card database of the mobile device of FIG. 2 that stores payment certificates according to an exemplary embodiment.</figref><figref num="4">FIG. 4 is a block diagram showing the memory of the mobile device of FIG. 2 which stores the data used for the generation of the advanced storage key and the generation of the application cipher according to the exemplary embodiment.</figref><figref num="5">FIG. 5 is a block diagram showing a transaction management server of FIG. 1 that processes a payment transaction with a mobile device that does not have a secure element according to an exemplary embodiment.</figref><figref num="6">FIG. 6 is a block diagram showing an account database of the processing server of FIG. 5 that stores payment certificates and account details according to an exemplary embodiment.</figref><figref num="7">FIG. 7 is a flowchart showing a process of transmitting and verifying two application ciphers to process a payment transaction involving a mobile device without a secure element according to an exemplary embodiment.</figref><figref num="8">FIG. 8 is a flow chart showing another process of transmitting and verifying two application ciphers to process a payment transaction involving a mobile device without a secure element according to an exemplary embodiment.</figref><figref num="9">FIG. 9 is a flow chart illustrating a process of creating, transmitting and validating a remote notification service message or other data message provided to a mobile device without a secure element according to an exemplary embodiment. ..</figref><figref num="10A">FIG. 10A is a flowchart showing a process of creating, transmitting, and verifying a message returned by a mobile device without a secure element according to an exemplary embodiment.</figref><figref num="10B">FIG. 10B is a flowchart showing a process of creating, transmitting, and verifying a message returned by a mobile device that does not have a secure element according to an exemplary embodiment.</figref><figref num="11">FIG. 11 is a flowchart showing a process of verifying the remote notification service message using the mobile device of FIG. 2 according to the exemplary embodiment.</figref><figref num="12">FIG. 12 is a diagram showing the generation of an advanced storage key using the mobile device of FIG. 2 according to an exemplary embodiment.</figref><figref num="13">、</figref><figref num="14">13 and 14 are flowcharts illustrating an exemplary method of generating a payment certificate in a payment transaction according to an exemplary embodiment.</figref><figref num="15">FIG. 15 is a flowchart illustrating an exemplary method of receiving and processing a remote notification service message according to an exemplary embodiment.</figref><figref num="16">FIG. 16 is a flowchart illustrating an exemplary method of creating an advanced storage key according to an exemplary embodiment.</figref><figref num="17">FIG. 17 is a block diagram showing a computer system architecture according to an exemplary embodiment.</figref>
Further scope of the present invention will become apparent from the detailed description provided below. It should be understood that the detailed description of the exemplary embodiments is for illustration purposes only and is not necessarily intended to limit the scope of the invention.
Glossary Payment Network ... A system or network used for remittances using cash substitutes. Payment networks may use different protocols and procedures to process remittances for different transactions. Transactions that may be performed via the payment network may include purchases of products or services, credit purchases, debit transactions, fund transfers, account withdrawals, and the like. The payment network may be configured to execute transactions via a cash substitute that may include payment cards, letters of credit, checks, trading accounts, and the like. Examples of networks or systems configured to run as payment networks include those operated by MasterCard (R), VISA (R), Discover (R), American Express (R), PayPal (R), etc. The use of the term "payment network" herein may refer to both a payment network as an entity and a physical payment network such as equipment, hardware and software, including payment networks.
Trading account ... A financial account that may be used to fund a transaction, such as a checking account, savings account, credit account, virtual payment account, etc. The trading account may be associated with a consumer, which may be any suitable type of entity associated with the payment account, which may include individuals, families, companies, businesses, government entities, and the like. In some examples, the trading account may be virtual, such as an account operated by PayPal (R) or the like.
Payment Card ... A card or data associated with a trading account that may be provided to a trader to fund a financial transaction through the relevant trading account. Payment cards may include credit cards, debit cards, charge cards, stored value cards, prepaid cards, fleet cards, virtual payment numbers, virtual card numbers, virtual credit card numbers and the like. The payment card may be a physical card that may be provided to the vendor, or may be data representing a related trading account (eg, stored in a communication device such as a smartphone or computer). For example, in some examples, the data, including the payment account number, may be considered a payment card for processing transactions funded by the relevant trading account. In some examples, checks may be considered as payment cards as appropriate.
Payment Transactions ... Transactions between two entities in which money or other monetary gain is exchanged from one entity to the other. A payment transaction may be a transfer of funds for the purchase of goods or services, the repayment of debt, or any other exchange of monetary gain that will be apparent to those skilled in the art. In some examples, payment transactions may refer to transactions funded through payment cards and / or payment accounts, such as credit card transactions. Such payment transactions may be processed via issuers (card issuers), payment networks and acquirers (merchant managers). The process of processing such payment transactions may include at least one of authorization, batching, clearing, settlement and funding. Permits are for the consumer to provide the payment details to the vendor, for the vendor to submit the transaction details (including payment details) to the acquirer, and for the consumer used to fund the transaction. It may include matching the issuer of the payment account with the payment details. Batching may indicate that the authorized transaction is stored together with other authorized transactions for distribution to the acquirer. Clearing may include sending batched transactions from the acquirer to the payment network for processing. Settlement may include withdrawing from the issuer through the payment network for transactions involving the issuer's recipient. In some examples, the issuer may pay the acquirer via a payment network. In another example, the issuer may pay the acquirer directly. Funding may include payments from the acquirer to the vendor for payment transactions that have been cleared and closed. It will be apparent to those skilled in the art that the sequence and / or classification of the steps described above will be performed as part of the payment transaction process.
POS ... with users (eg consumers, employees, etc.) to enter transaction data, payment data and / or other appropriate types of data for the purchase and / or payment of goods and / or services. A computing device or computing system that is configured to receive a conversation with. The POS may be a physical device (eg, cash register, kiosk, desktop computer, smartphone, tablet computer, etc.) in a physical location such as a "brick and mortar" store visited by consumers as part of a transaction, or It may be virtual in an electronic commerce environment such as an online retailer that receives communications from consumers via a network such as the Internet. If the POS may be virtual, the computing device operated by the user to initiate the transaction or the computing system that receives the data as a result of the transaction may be considered as appropriate to be the POS.
<u style="single">A system that processes payment transactions using mobile devices that do not have secure elements</u> FIG. 1 shows a system 100 that uses a mobile device to process payment transactions without the need for the use of secure elements. It is used to provide payment certificates to mobile devices in a secure manner, to store them in a secure manner, and to generate multiple application ciphers used to validate and process payment transactions. Can include things to do.
System 100 may include a transaction management server 102. The transaction management server 102, described in more detail below, provides the mobile device 104 with a payment certificate using a remote notification message transmitted in a secure manner, as well as as part of the payment transaction. It may be one or more computing devices specifically programmed to perform the functions described herein to validate the payment certificate generated by. Although shown and described herein as the transaction management server 102 performs various functions, the transaction management server 102 is a plurality of computing devices and servers configured to perform the functions described herein. It will be apparent to those skilled in the art that it may consist of and / or computing networks. The mobile device 104, described in more detail below, may be any type of mobile computing device suitable for performing the functions described herein, such as mobile phones, smartphones, smart watches, and others. It may include wearable or embedded computing devices, tablet computers, laptop computers and the like. In some embodiments, the mobile device 104 does not have to have a secure element. In other embodiments, the mobile device 104 may include secure elements, which may not be used in connection with the methods and systems described herein, or provide additional security. It may be used in connection with the methods and systems described herein, and the like.
The mobile device 104 may communicate with the transaction management server 104 using a plurality of communication channels, such as by using dual channel communication. Dual channel communication may include the use of two communication channels in the transmission and reception of data for verification and authentication, etc., in order to ensure enhanced security in the transmission of data. The mobile device 104 may include a mobile payment application (MPA) configured to be performed by the mobile device 104 to perform the functions of the mobile device 104 described herein. The MPA described in more detail below may be installed on the mobile device 104 and is invoked using the activation code provided by the transaction management server 102 using methods and systems that will be apparent to those skilled in the art. Alternatively, the mobile device 104 and the transaction management server 102 may use shared data to secure and send and receive communications across two or more communication channels.
System 100 may further include Issuer 106. Issuer 106 may be a financial institution such as an issuing bank that issues a payment card or certificate of payment to consumer 108 associated with a trading account. Issuer 106 may provide the transaction management server 102 with payment details associated with the transaction account and / or payment card. The payment statement may include, for example, a trading account number, the name of the account holder, an expiration date, a security code, and the like. As will be further described below, the transaction management server 102 may store data in the account database. The transaction management server 102 may further provide a payment certificate to the mobile device 104. As used herein, the term "payment certificate" is used in the transmission and verification of payment information used in payment transactions using the methods and systems described herein. It may show some data including, but not limited to, payment details, payment certificates, disposable keys, session keys, application ciphers, card master keys, etc. used by the transaction management server 102.
In some embodiments, the payment certificate may be provided to the mobile device 104 via a remote notification service message. As described in more detail below, the Remote Notification Service (RNS) message may be a secure message that is sent to the mobile device 104 and then verified by the mobile device 104, and is therefore included therein. The data may be secured from other devices and users. The MPA of the mobile device 104 may prove that the received RNS message is legitimate, or may decrypt it in order to obtain the data contained therein. The mobile device 104 may then perform any necessary function based on the data (eg, by executing an instruction contained in the data) and a return message sent to the transaction management server 102. May be appropriately generated. In some examples, the reply message is validated by the transaction management server 102.
In some examples, at least a message counter and an authentication code may be used to validate the RNS message on the mobile device 104 or the reply message on the transaction management server 102. By using both the counter and the authentication code, it may be guaranteed that only the designated mobile device 104 can verify and decrypt the data contained in the RNS message. In addition, if the MPA contains the rules and / or algorithms used to generate the authorization code, only the mobile device 104, which further contains a particular instance of the application program, may be able to validate the RNS message, as a result. Security is further improved. If the RNS message may include a payment certificate, this means payment certificate only on the appropriate mobile device 104 and if the MPA used to access the payment certificate is the appropriate authorized application. May be guaranteed to be usable.
The payment certificate provided to the mobile device 104 may be securely stored in a storage device in the mobile device 104, such as a card database, which will be described in more detail below. In some embodiments, the mobile device 104 is configured to generate an advanced storage key used to securely store data such as payment certificates in a database or memory within the mobile device 104. You may. As described in more detail below, advanced storage key generation is unique device information, unique to identify a secure storage key that can be used to secure and store data in mobile device 104. MPA information and randomly generated information may be used. Thereby, the payment certificate or other sensitive data may be securely stored in the mobile device 104 without using the secure element, so that the mobile device 104 makes the payment transaction without using the secure element. It can be started and run, making it easier for issuers 106 and consumers 108 to use while maintaining a high degree of security.
When the mobile device 104 receives, verifies, and stores the payment certificate for the trading account, the consumer 108 takes the mobile device 104 to the vendor's POS110 and executes the payment transaction. Consumer 108 may select a product or service to purchase, initiate a payment transaction for that purchase with a vendor, and communicate a payment certificate used to fund the payment transaction. A mobile device 104 may be used. Propagation of payment certificate to POS110 may include sending two or more application ciphers. As a result of using two or more application ciphers, transactions processed using the methods and systems described herein are conventional, including transactions performed using a mobile device 104 with a secure element. The security level may be higher than that of contactless remote transactions.
Each application cipher may be generated by the mobile device 104 using a separate session key and additional data described in more detail below. An application cipher generated using data stored on a mobile device 104, such as a storage device that is secured via an advanced storage key and associated with an MPA, is a specific instance of the mobile device 104 and the MPA. May be guaranteed to authenticate. In some examples, one of the ciphers and / or the session key used to generate the cipher may use information provided by consumer 108, such as a personal identification number (PIN). .. By using a PIN or other consumer credentials, the cipher may be able to authenticate both consumer 108 and mobile device 104. In such cases, the cipher generated by the mobile device 104 may include a cipher that authenticates the mobile device 104 and a second cipher that authenticates both the mobile device 104 and the consumer 108.
The cipher may be received by the POS 110 via short-range wireless communication or the like as part of the execution of the payment transaction. Application cryptography is an additional payment as required for any suitable type of payment transaction such as contactless transactions, remote transactions, secure remote payment transactions, magnetic stripe transactions and M / Chip EMV transactions. The information may be accompanied and, as will be apparent to those skilled in the art, may be transmitted to the POS 110 using any suitable method as appropriate. The code may be transmitted to the acquirer 112, which may be a financial institution such as a merchant bank associated with the vendor. For example, the acquirer 112 may issue a trading account to a trader that is used to receive payment of funds from consumer 108 for a payment transaction. The acquirer 112 may submit cryptographic and additional transaction details to the payment network 114 using methods and systems that will be apparent to those skilled in the art. For example, transaction details and application cryptography may be included in the authorization request submitted to payment network 114 on payment rails.
In some embodiments, both application ciphers may be included in a single transaction message. For example, mobile devices 104 and / or POS110 may include both application ciphers in existing data fields of traditional transaction messages in order to use existing payment systems and hardware to send both application ciphers. In some examples, the transaction management server 102 may be configured to use track 2 data for verification of application cryptography, such as in transactions with magnetic stripes. In such an example, if the transaction message contains track 1 data, the transaction management server 102 may be configured to convert the track 1 data to track 2 data, which may be modified track 1 data or track 2. It may further include converting the data into track 1 data or track 2 data (eg, original data, reconstructed data, etc.) before the change, respectively. By performing these functions and including the application cipher in the existing data fields, the transaction management server 102 does not need to use the secure element on the mobile device 104 and does not modify the existing payment system. , Remote contact payment transactions using mobile device 104 may be configured to process and verify at a high level of security.
Payment network 114 may process payment transactions using methods and systems that will be apparent to those skilled in the art. As part of the process, payment network 114 may send application ciphers to issuer 106 for verification. In some embodiments, matching may be performed by payment network 114. Issuer 106 or payment network 114 may communicate with transaction management server 102. In some embodiments, the application cipher may be sent to the transaction management server 102 or collated by using the transaction management server 102 to generate a verification application cipher. It may be generated using a locally stored payment certificate. In other embodiments, the issuer 106 or payment network 114 may request the transaction management server 102 for an application cipher, which in turn generates the application cipher and validates it against the cipher generated by the mobile device 104. You may return the cipher to issuer 106 or payment network 114 to do so.
Since the transaction management server 102 has the payment certificate and other data that the mobile device 104 uses to generate the application cipher, the verification of the payment certificate generated by the mobile device 104 to fund the payment transaction is , The application cipher generated by the mobile device 104 may be executed by comparing the application cipher generated by the transaction management server 102. In some embodiments, the transaction management server 102 may be part of the payment network 114 or issuer 106. If the transaction management server 102 may be part of the payment network 114, validation may be performed prior to contacting issuer 106 as part of the traditional processing of payment transactions (eg, with issuer 106). To approve funding for transactions using the consumer 108 trading account).
By using multiple application ciphers, the security of payment transactions can be improved. In addition, each cipher authenticates separate data, such as when one cipher authenticates the mobile device 104 and the other authenticates both the mobile device 104 and the consumer 108 (eg, via the consumer PIN). If so, additional data and considerations used in deciding whether to approve or reject the transaction may be further provided to Issuer 106. For example, if both ciphers are incorrect (eg, the cipher generated by the mobile device 104 does not match the cipher generated by the transaction management server 102), the transaction may be rejected. If one cipher is correct and the other is incorrect, the transaction may be denied for security reasons or may be approved based on issuer 106's decision or the like. For example, the issuer 106 can be used otherwise if the consumer authentication fails but the mobile device authentication succeeds, if a non-consumer 108 but authorized user is using the mobile device 104 for a transaction. Data may be shown, so the transaction may be approved.
As a result, the use of both ciphers may provide useful data that the payment network 114 and issuer 106 can use when processing payment transactions. In addition, the use of two or more ciphers may provide more security than traditional non-contact or remote payment methods, resulting in reduced fraud and more widespread acceptance by consumers 108, issuers 106 and vendors. May be done. The use of two or more application ciphers is generated from a payment certificate provided securely using the RNS message sending method and system described herein and the method and system described herein. When stored securely via an advanced storage key generated using, the security of the entire system 100 against contact payment transaction processing can be significantly improved over traditional systems. As a result, System 100 may be more secure than traditional contactless payment systems in multiple aspects of data transmission, storage and processing, or may use the methods and systems described herein. Other types of good remote payment transactions and payment transactions in general may be provided.
<u style="single">Mobile device</u> FIG. 2 shows an embodiment of the mobile device 104 of the system 100. The embodiment of the mobile device 104 shown in FIG. 2 is provided by way of example only and may not include all possible configurations of the mobile device 104 suitable for performing the functions described herein. It will be clear to those skilled in the art. For example, the computer system 1700 shown in FIG. 17 and described in more detail below may be an appropriate configuration of the mobile device 104.
The mobile device 104 may include a receiver 202. The receiver 202 may be configured to receive data over one or more networks by one or more network protocols. The receiver 202 may receive program data for one or more application programs installed and executed on a mobile device 104, such as a mobile payment application (MPA), which will be described in more detail below, for example. The receiver 202 may further receive an RNS message, such as a message sent by the transaction management server 102, including a remote notification service (RNS) message including a payment certificate. The receiver 202 may further receive additional data suitable for performing the conventional functions of the mobile device 104 such as telephone communication, cellular communication and the like. In some examples, the mobile device 104 may include multiple receivers 202, such as separate receivers 202, each configured to communicate with one or more separate networks by appropriate protocols. For example, the mobile device 104 may include a first receiver 202 that receives data for NFC transactions and a second receiver 202 that receives communications over the mobile communication network.
The mobile device 104 may further include an input unit 214. The input unit 214 is one or more internally or externally connected to a mobile device 104 to receive input from a consumer 108 such as a keyboard, mouse, click wheel, scroll wheel, touch screen, microphone, camera, receiver, etc. It may be configured to communicate with the input device. The input unit 214 may receive input from the consumer 108, which may be processed by the processing unit 204.
The processing unit 204 may be configured to perform the function of the mobile device 104 described herein. The processing unit 204 may execute the program code stored in the mobile device for MPA or the like, and is configured to execute a plurality of functions related to each application program in addition to the other functions of the mobile device 104. May be good. The processing unit 204 receives the input from the consumer 108 via the input unit 214, and as understood by those skilled in the art, the processing unit 204 executes the application program, executes the functions in the program, receives the data, transmits the data, The corresponding function may be executed by displaying data or the like. For example, processing unit 204 may be configured to validate RNS messages, generate advanced storage keys, and generate application ciphers, as described in more detail below.
The mobile device 104 may further include a display unit 210. The display unit 210 communicates with one or more display devices internally or externally connected to the mobile device 104 to display data such as data transmitted by the processing unit 204 to the display unit 210 for display. It may be configured in. The display device may include a liquid crystal display, a light emitting diode display, a thin film transistor display, a touch screen display, and the like.
The mobile device 104 may further include a transmitter 206. The transmitter 206 may be configured to transmit data over one or more networks by one or more network protocols. The transmitter 206 may send an RNS response message to the transaction management server 102. The transmitter 206 may be further configured to transmit the application cipher and / or payment certificate to POS110 or the like for use in payment transactions. The transmitter 206 may be further configured to perform additional functions of the mobile device 104 that will be apparent to those skilled in the art, such as conventional functions of the mobile communication device such as transmission of cellular communications. In some examples, the mobile device 104 is a transmitter 206 configured to send payment certificates and payment ciphers over NFC and another configured to send data over a mobile communication network. The transmitter 206 may include a plurality of transmitters 206 that may be individually configured to communicate with one or more separate networks, such as the transmitter 206 of the.
The mobile device 104 may further include a card database 208. The card database 208, described in more detail below, may be a data storage device on a mobile device 104 configured to store data associated with one or more trading accounts and / or payment cards. The card database 208 includes payment certificates associated with the transaction account, such as payment certificates provided by the transaction management server 102 to the mobile device 104 in a secure RNS message, and application cryptography as described in more detail below. May be stored with additional data that may be used in generating the. In some examples, the card database 208 may be stored as part of a mobile payment application.
The mobile device 104 may further include a memory 212. The memory 212, described in more detail below, may be configured to store data for the mobile device 104 suitable for performing the functions of the mobile device 104 described herein. For example, the memory 212 may store data suitable for generating a sophisticated storage key for encrypting further data in a mobile device 104 such as a card database 208, as described in more detail below. Good. The memory 212 is a program code for an application program executed by a processing unit 204 of an operating system or the like, a program code for receiving data via an input unit 214 and displaying data via a display unit 210, and the present specification. It may be further configured to store rules and / or algorithms and the like for performing the functions described herein. The memory 212 may further store data suitable for performing conventional functions of the mobile device 104, such as rules and / or algorithms for transmitting and receiving cellular communications over the mobile network. Further data stored in memory 212 will be apparent to those skilled in the art.
<u style="single">Mobile device card database</u> FIG. 3 is an embodiment of card database 208 of mobile device 104 that stores payment certificates and other data related to payment transactions used to fund payment transactions performed using mobile device 108. Is shown.
The card database 208 may include one or more payment profiles 302 shown as payment profiles 302a, 302b and 302c in FIG. Each payment profile 302 may be associated with a trading account that may be used to fund a payment transaction, at least a payment certificate 304, one or more disposable keys 306, a first session key 308, a first. It may include two session keys 310 and an application transaction counter 312.
The payment certificate 304 may include data related to the relevant trading account used for identification and verification by the payment network 114 and / or issuer 106 in the processing of payment transactions using the associated trading account. The payment certificate 304 may include, for example, a trading account number, a security code, an expiration date, a cardholder's name, an authorized user name, tracking data, card layout description data, a digital count, a bitmap, and the like.
The disposable key 306 is a payment token valid for a single payment transaction that may be used by the processing unit 204 of the mobile device 104 to generate one or more of the application ciphers used in the payment transaction. There may be. In some embodiments, the disposable key 306 may include one or more of the other data elements contained in the payment profile 302. For example, each disposable key 306 may include a separate application transaction counter 312, which may not be separately included in profile 302. Different configurations of the data stored in payment profile 302 used to perform the functions disclosed herein will be apparent to those of skill in the art. In some examples, the disposable key 306 may include or consist of a key used to generate one or more application ciphers. In some embodiments, the first session key 308 and the second session key 310 may be contained in the disposable key 306 provided to the mobile device 104 and / or use the data contained in the disposable key 306. May be generated.
The first session key 308 and the second session key 310 are further used by the processor 204 in generating the application cipher to be sent to the POS 110 as part of the execution of a payment transaction using the mobile device 104. It may be a key. In some embodiments, the first session key 308 is used when the processing unit 204 generates the first application cipher using a program code, rule, algorithm, etc. stored in the memory 212 of the mobile device 104. May be used. The second session key 310 may be used in generating the second application cipher.
In some embodiments, the second session key 310 may be generated by the processing unit 204. In one such embodiment, the second session key 310 is generated using a disposable key 306 and user authentication data such as a PIN provided by consumer 108 (eg, via input 214). May be good. In one such embodiment, the second session key 310 does not have to be stored in the payment profile 302 and may instead be generated, used and discarded as part of the payment transaction process. Therefore, when generated from a second session key 310 generated using the disposable key 306 and the consumer PIN, the second application cipher is used to authenticate both the mobile device 104 and the consumer 108. Will be done.
A personal identification number (PIN) is provided by consumer 108, which may be used to authenticate consumer 108 (eg, when registering an MPA on a mobile device 104 or issuer 106 and / or transaction management server 102. It may be a number (when registering a trading account with). When executing a payment transaction, the consumer 108 or another user of the mobile device 104 may provide the PIN via input 214. In some embodiments, if the provided PIN is incorrect (eg, does not match the PIN provided by consumer 108 at registration), processor 204 proceeds to generate a second session key 310 and then. , A second application cipher may be generated. If the PIN provided is incorrect, the second application cipher is inaccurate, and as a result, the verification of the second application cipher by Transaction Management Server 102, Issuer 106 and / or Payment Network 114 fails and it Issuer 106 may be provided with the opportunity to refuse or still approve the transaction in accordance with.
<u style="single">Mobile device memory</u> FIG. 4 shows a mobile device 104 that stores application programs and other data used to secure and store data in the mobile device 104 and to execute payment transactions using the mobile device 104. An embodiment of the memory 212 is shown. In one exemplary embodiment, the memory 212 does not have to be a secure element.
The memory 212 may include device information 402. The device information 402 may include one or more data related to the mobile device 104, which may be specific to the mobile device 104 in some examples. For example, the device information 402 may include a medium access control address, a reference number, a serial number, an identification number, and the like. Further information that may be considered device information 402 for mobile device 104 will be apparent to those skilled in the art.
The memory 212 may further include a mobile payment application (MPA) 404. The MPA404 is to perform the functions of the mobile device 104 described herein, such as receiving and storing payment certificates, validating RNS messages, and generating application ciphers used when performing payment transactions. It may be a configured application program. As will be apparent to those skilled in the art, additional features of the MPA404 may include the traditional features of a digital wallet or other similar application program.
MPA404 may include program code 406. The program code 406 may be code executed by the processing unit 204 of the mobile device 104 and the processing unit 204 of the mobile device 104 that causes other components to execute the functions of the MPA 404 described herein. For example, the program code 406 may include a code suitable for generating an application cipher, verifying an RNS message, and the like. Program code 406 may further include program code suitable for generating random values that may be used in generating advanced storage keys. Random numbers may be random numbers or pseudo-random numbers that may be generated using methods and systems that will be apparent to those skilled in the art.
MPA404 may further include instance identifier 408. The instance identifier 408 may be a specific MPA404-specific value that may be used in generating advanced storage keys used to secure data in a mobile device 104 such as a card database 208. .. By having the instance identifier 408 specific to the MPA404, multiple MPA404s may be installed on the mobile device 104 without access to the data stored secure by any MPA404, thereby. Other programs can guarantee that they will not have access to the payment profile 302 for a particular payment account. The instance identifier 408 may be a number, alphabetic value, hexadecimal number, or any suitable value that may be unique to MPA404.
As described in more detail below, the processing unit 204 of the mobile device 104 uses device information 402, a random number generated using program code 406 of MPA404, and an instance identifier 408 stored in MPA404. It may be configured to generate a diversifier value. The variegated values may be used by cryptographic applications 410, which are also stored in memory 212. Cryptographic application 410 may be an application program configured to perform white box cryptography and / or any other suitable cryptographic function that will be apparent to those skilled in the art.
Cryptographic application 410 may include program code 412. Program code 412 is executed by the processing unit 204 of the mobile device 104 to allow the processing unit 204 of the mobile device 104 and other components to perform the cryptographic functions of the cryptographic application 410 described herein. May be good. The function may include the generation of advanced storage keys. The advanced storage key may be generated using the various values generated by the mobile payment application 404 and the cryptographic key 414 included in the cryptographic application 410. In some embodiments, the multi-key (vari-value) may be decrypted using the encryption key 414 to obtain a sophisticated storage key.
Cryptographic application 410 may be further configured to use a sophisticated storage key to encrypt storage on the mobile device 104. In some embodiments, encryption may be performed using one or more white box encryption techniques. The encrypted storage may be the card database 208 and / or some other suitable storage in the mobile device 104 such as data stored in the MPA404. In some embodiments, the cryptographic application 410 may be included as part of the MPA404. The advanced storage key may be stored in the cryptographic application 410 or MPA404, or in some cases, may be regenerated by the cryptographic application 410 and the cryptographic application 410 if necessary.
The memory 212 may further include some additional data stored in the mobile device 104 and suitable for performing some of the functions described herein and any further function of the mobile device. For example, memory 212 may include program code to the operating system, code for sending and receiving mobile communications such as telephone calls, rules or algorithms, and the like.
In some embodiments, the mobile device 104 may be further configured to receive data that has already been encrypted using a sophisticated storage key, such as memory 212, card database 208 or other. It may be stored in an encrypted local storage device within the mobile device 104, such as a suitable storage device. In one such embodiment, the mobile device 104 may be configured to send the generated random value to the transaction management server 102 or other trusted entity, which is the transaction management server 102 or other trusted entity. , The generated random values may be used to generate advanced storage keys using the same methods and systems, or the data provided to the mobile device 104 may be encrypted. Thus, the mobile device 104 may receive data that has already been encrypted using an advanced storage key for local storage on the mobile device 104.
<u style="single">Transaction management server</u> FIG. 5 shows an embodiment of the transaction management server 102 of the system 100. The embodiment of transaction management server 102 shown in FIG. 5 is provided by way of example only and does not include all possible configurations of transaction management server 102 suitable for performing the functions described herein. It will be clear to those skilled in the art that it is good. For example, the computer system 1700 shown in FIG. 17 and described in more detail below may be an appropriate configuration of the transaction management server 102.
The transaction management server 102 may include a receiver 502. The receiver 502 may be configured to receive data over one or more networks by one or more network protocols. Receiver 502 may receive data such as received or reply messages, confirmation messages, transaction notifications, etc. from mobile devices 104, payment networks 114, issuers 106 or other suitable entities. The receiver 502 may receive a transaction notice or cryptographic request, such as to initiate the generation of an application cipher used in verifying a payment certificate in a payment transaction. The receiving unit 502 may further receive the trading account data used in generating the payment certificate provided to the mobile device 104 from the issuer 106 or the like.
The transaction management server 102 may further include a processing unit 504. As will be apparent to those skilled in the art, processing unit 504 may be configured to perform the functions of transaction management server 102 described herein. Therefore, as described in more detail below, the processing unit 504 generates and encrypts the RNS message and the data contained therein, verifies the reply message from the mobile device 104, generates a payment certificate, and applies the application encryption. May be configured to generate and verify the application cipher.
The transaction management server 102 may further include a transmitter 506. The transmitter 506 may be configured to transmit data over one or more networks by one or more network protocols. Transmitter 506 may transmit RNS messages, payment certificates, application ciphers, verification notices, and other data that will be apparent to those skilled in the art. The transmitter 506 may be configured to transmit data to the mobile device 104, the payment network 114, the issuer 106 and some other suitable entity via a mobile communication network or the Internet or the like.
The transaction management server 102 may further include an account database 508. As described in more detail below, the account database 508 may be configured to store account information for multiple trading accounts. Account information may include data and keys used to generate application ciphers used in validating payment certificates received during payment transactions performed using mobile device 104. .. The account database 508 is intended to store transaction data for payment transactions performed in connection with the mobile device 104, as well as other data such as data related to consumer 108 or other authorized users of the associated trading account. May be further configured.
The transaction management server 102 may further include a memory 510. The memory 510 may be configured to store additional data used by the transaction management server 102 in performing the functions disclosed herein. For example, memory 510 encrypts and decrypts rules or algorithms for validating application ciphers, rules or algorithms for generating validation notifications, algorithms for generating session keys and application ciphers, data and RNS messages. An encryption key or the like for the purpose may be stored. Further data that may be stored in memory 510 will be apparent to those skilled in the art.
<u style="single">Transaction management server account database</u> FIG. 6 is a transaction management server 102 that stores data related to the trading account used when validating payment certificates and other transaction data provided when performing payment transactions including the mobile device 104. An embodiment of the account database 508 of
The account database 508 may include a plurality of account profiles 602 shown as account profiles 602a, 602b and 602c in FIG. Each account profile 602 may include one or more disposable keys 604, a first session key 606, a second session key 608, an application transaction counter 610 and a first card master key 612. In some embodiments, the account profile 602 may further include a second card master key 612.
Each account profile 602 may correspond to a payment profile 302 provided on the mobile device 104. Therefore, the disposable key 604 stored in the account profile 602 may correspond to the disposable key 306 stored in the corresponding payment profile 302 associated with the same trading account. If the application cipher is generated by the transaction management server 102 or the mobile device 104, the data may be similar so that the application cipher matches if the data is accurate and has not been tampered with, thereby the mobile device. It may be possible to verify the payment certificate presented by 104.
In some embodiments, the account profile 602 may include a personal identification number (PIN) corresponding to PIN 314 stored in the corresponding payment profile 302. In one such embodiment, the PIN 314 may be provided to the receiver 202 of the transaction management server 102 in a secure message such as a received message provided by the mobile device 104 described in more detail below. In other embodiments, a card master key, such as the first card master key 612, may be used in place of the PIN. In one such embodiment, the processing unit 504 of the transaction management server 102 uses the disposable key 306 and PIN 314 to provide a second session key 608 corresponding to the second session key 310 generated by the mobile device 104. It may be configured to be generated based on a second card master key 614. In some examples, the second session key 608 may be further based on the corresponding disposable key 604. In such embodiments, the algorithms for generating session keys and / or application ciphers are based on the ciphers generated by the mobile device 104 and the ciphers generated by the transaction management server 102 based on the data used in them. It may be guaranteed to correspond.
The first session key 606 may be used by the processing unit 504 of transaction management server 102 to generate the first application cipher, and the second session key 608 is to generate the second application cipher. May be used. In some embodiments, the application transaction counter 610 may be used in generating one or more session keys and / or application ciphers. The application transaction counter 610 may be a value corresponding to the payment transaction being executed and is incremented or changed during each transaction. The application transaction counter 610 may correspond to the application transaction counter 312 stored in the corresponding payment profile 302 in the mobile device 104, by which only a valid MPA404 has the correct application transaction counter 312. However, it may be guaranteed that a valid session key and / or application cipher may be generated. Additional techniques may be used that further enhance the security of session key and / or application cipher generation, such as unpredictable numbers and other techniques that will be apparent to those of skill in the art.
<u style="single">Processing payment transactions using mobile devices</u> FIG. 7 shows the process of processing a payment transaction performed using a mobile device 104 without a secure element and using the generation and verification of two or more application ciphers.
In step 702, the transaction management server 102 may provide the payment certificate 304 and other account data to the mobile device 104 (eg, via transmitter 506) by means of an RNS message or the like described in more detail below. .. In step 704, the receiver 202 of the mobile device 104 may receive the payment certificate 304 and other account data. In step 706, the processing unit 204 of the mobile device 104 may store the data in the payment profile 302 in the card database 208. Account data may include payment certificate 304, one or more disposable 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 ciphers used in executing payment transactions. In some embodiments, step 708 directs via input 214, places the mobile device 104 in the vicinity of the POS 110 to initiate a transaction via short-range wireless communication, or is otherwise suitable. It may be initiated by consumer 108 by method or the like. The generation of the application cipher may include generating the first application cipher using the first session key 308 stored in the payment profile 302. A second application cipher may be generated using a second session key 310, which may be generated using the disposable key 306 and PIN 314. In some examples, the consumer 108 may enter the PIN into the mobile device 104 before step 708 or at the beginning of step 708 (eg, via input 214). In some embodiments, one or both of the application ciphers may be generated using the application transaction counter 312.
Once the application cipher is generated, it may be sent via the POS 110 to the issuer 106, acquirer 112 and payment network 114 along with the payment certificate 304. At step 710, the payment certificate 304 and the application cipher may be received by the issuer 106. In step 712, the transmitter 206 of the mobile device 104 may transmit the transaction notification to the transaction management server 102. In step 714, the receiver 502 of the transaction management server 102 may receive the transaction notification. The transaction notification may notify the transaction management server 102 that the mobile device 104 has started a payment transaction using the payment profile 302. In some examples, the transaction notice may include identifying information.
In step 716, the processing unit 504 of transaction management server 102 may identify the account profile 602 corresponding to payment profile 302 and may use the data contained therein to generate two application ciphers. The first application cipher may be generated using the first session key 606, which may be generated using the first card master key 612. The second application cipher may be generated using the second session key 608. In some embodiments, one or both of the application encryption and / or session key may be further based on the disposable key 604, the application transaction counter 610 or some other suitable data.
In step 718, the transmitter 506 of the transaction management server 102 may transmit the generated application cipher to the issuer 106, and the issuer 106 may receive the cipher in step 718. In step 720, the issuer 106 may verify the application cipher with the payment certificate 304 provided by the mobile device 104. Verification of the application cipher may include comparing the cipher provided by the mobile device 104 with the application cipher generated and provided by the transaction management server 102. Once the validation is performed, in step 722, issuer 106 may process the transaction as appropriate. Processing a transaction involves approving a payment transaction if one or both of the ciphers are confirmed, or rejecting a payment transaction if one or both of the ciphers are determined to be invalid, etc. But it may be.
At step 724, the transaction notification may be sent by the issuer 106 or other entity (eg, payment network 114, acquirer 112, etc.) as part of the processing of the payment transaction. In step 726, the transaction notification may be transmitted to the transaction management server 102 and received by the receiver 502. In step 728, the transaction notification may be further received by the receiver 202 of the mobile device 104. The transaction notice may be an instruction to approve or reject the payment transaction. The processing unit 204 of the mobile device 104 and the processing unit 504 of the transaction management server 102 may each execute one or more functions as a result of the received transaction notification. For example, if the transaction is approved and successfully processed, the application transaction counters 310 and 610 in the respective profiles may be updated accordingly.
FIG. 8 shows another process of processing a payment transaction using the mobile device 104.
In step 802, the payment certificate 304 and other account data may be transmitted to the mobile device 104 by the transmitter 506 of the transaction management server 102. In step 804, the receiver 202 of the mobile device 104 may receive the payment certificate 304 and other account data, and in step 806 they may be stored in the payment profile 302. In step 808, the processing unit 204 of the mobile device 104 may generate the two application ciphers as described above, or may send the cipher, payment certificate 304 and other suitable data to the issuer 106 (eg,). , Via POS110).
At step 810, the issuer 106 may receive application cryptography and some other suitable data that may be used by the issuer 106 to validate the transaction data and / or process the approval or denial of the transaction. At step 812, issuer 106 may submit a request for cryptographic verification to transaction management server 102. In some embodiments, the request may include a payment certificate 304 and other data suitable for use by the transaction management server 102 in identifying the account profile 602 used to generate the verification cipher. .. In one embodiment, the request may further include two application ciphers generated by the mobile device 104 for verification.
In step 814, the receiver 502 of the transaction management server 102 may receive the encryption request. In step 816, processing unit 504 of transaction management server 102 may generate two application ciphers used for verification, as described above. In an embodiment in which the cryptographic request further comprises two application ciphers generated by the mobile device 104, step 816 verifies the two ciphers by the processor 504 using the two newly generated application ciphers. Further may be included. The verification cipher or the verification result in the corresponding embodiment may be transmitted to the issuer 106 by the transmission unit 506. At step 818, the issuer 106 may receive the verification cipher and / or the verification result.
In step 820, the issuer 106 may use the application cipher generated by the transaction management server 102 to validate the application cipher provided by the mobile device 104. In an embodiment in which transaction management server 102 provides verification results to issuer 106, step 820 may include identifying the verification results for each of the two application ciphers. At step 822, issuer 106 may process payment transactions as appropriate according to the results of the validation. In step 824, the transaction notification may be transmitted to the transaction management server 102 and the mobile device 104, received by the receiver 502 in step 826, and received by the receiver 202 in step 828.
<u style="single">Remote notification service / send data message</u> FIG. 9 shows the process of sending and validating a remote notification service (RNS) message and other data messages sent from the transaction management server 102 to the mobile device 104. The RNS message may be transmitted via a remote notification service using a mobile communication network or the like associated with the mobile device 104. The RNS message is secured between the payment certificate 304, other account data such as the account data used when processing the payment transaction as described above, and the mobile device 104 and the transaction management server 102. It may be used to provide the mobile device 104 with other information that may be used in establishing the connection.
In step 902, the processing unit 504 of the transaction management server 102 may generate a message. When establishing mutual authentication with the mobile device 104, the message may include information suitable for establishing mutual authentication, such as a session identifier. In other cases, such as when mutual authentication between the transaction management server 102 and the mobile device 104 has been established using the process described herein as shown in FIG. 9, the generated message is a payment. It may include certificate 304 and account data, and may include one or more commands executed by MPA404 on mobile device 104 (eg, removal of disposable key 306 or payment certificate 304) for consumer 108. It may be the notification presented (eg, account balance, payment notification, etc.) or may include other suitable data.
In step 904, the processing unit 504 may encrypt the generated message. The message may be encrypted using the private key of the private / public key pair, in which case the mobile device 104 may have the corresponding public key. In some examples, the message may be encrypted using a mobile device 104, such as encryption key 414, or an encryption key associated with MPA404. In step 906, the processing unit 504 may generate a message authentication code. The message authentication code may be generated using an encrypted message or a key generated using one or more specially configured rules and / or algorithms. For example, the message authentication code may be generated using one or more encryption / obfuscation methods such as padding. In some embodiments, the message authentication code may be generated using an encryption key.
In step 908, the transmitter 506 of the transaction management server 102 may send a composite data message to the mobile device 104. In embodiments where mutual authentication may be in progress, the composite data message may be a remote notification service message transmitted to the mobile device 104 via the remote notification service. The composite data message may be received by the receiver 202 of the mobile device 104 in step 910 and may include a message authentication code and an encrypted message. In some examples, the composite data message may further include additional identifiers, such as identifiers generated using the methods MPA404 recognizes for verification. In some cases, such as when mutual authentication has already been performed, the composite data message may further include a message counter.
In step 912, the processing unit 204 may generate a reference authentication code. The reference verification code may be generated using the encrypted message received, and the reference verification code generated when the message verification code is generated by a trusted source (eg, transaction management server 102) is the message. Corresponding to the authentication code, it may be generated using the same rules and algorithms that the transaction management server 102 used to generate the message authentication code. In an embodiment in which the message authentication code may be generated using an encryption key, the processing unit 204 generates a reference authentication code using the encryption key 414 stored in the memory 212 or another suitable encryption key. May be good.
In step 914, the processing unit 204 may verify the message authentication code included in the received composite data message by comparing it with the generated reference authentication code. If both the message counter and the message authentication code are confirmed, the composite data message may be determined to be reliable (for example, genuine) because it was sent from the transaction management server 102. When the composite data message may include a message identifier, the processing unit 204 further generates the message identifier by generating the message identifier using the processing recognized by MPA404 for generating and comparing the message identifier. You may verify. In an embodiment in which the composite data message may include a message counter, the processing unit 204 uses a reference counter stored in a mobile device 104 such as MPA404 or payment profile 502 to set the message counter included in the received composite data message. You may verify.
In step 916, the processing unit 204 may decrypt the encrypted message contained in the received composite data message. Encrypted messages are decrypted using a key such as a key stored in memory 212 (eg cryptographic application 410 or MPA404) or a locally encrypted database (eg encrypted using a highly stored key). It may be decrypted, or it may be decrypted by another suitable decoding method. In step 918, the processing unit 204 may perform one or more appropriate actions based on the data decrypted from the encrypted message. In the example shown in FIG. 9, the mobile device 104 may execute mutual authentication with the transaction management server 102 by using a session identifier or the like that includes an encrypted message and is decrypted by the processing unit 204. In step 920, the transaction management server 102 may receive the session identifier and perform some further action required for mutual authentication with the mobile device 104. If mutual authentication has already been performed, the message may include other information suitable for performing the functions disclosed herein, such as payment certificate 404, disposable key 406, program instructions for MPA404, etc. Good.
In some embodiments, the mobile device 104 may be configured to generate a reply message and submit it to the transaction management server 102 (eg, via MPA404). In some examples, the reply message may include data generated in response to the actions commanded and executed in the decrypted message as described above. For example, the reply message may indicate the valid receipt and storage of payment certificate 304 or disposable key 306. In another example, the reply message may be a notification of receipt and validation of a composite data message. If mutual authentication is performed first, the reply message may include the session identifier used to perform mutual authentication.
10A and 10B show a process in which the mobile device 104 generates and sends a reply message, and the transaction management server 102 verifies it.
In step 1002, the processing unit 204 of the mobile device 104 may generate a received message. The received message may be generated based on the program code 406 stored in the MPA 404, or may be further based on the action directed and executed in the composite data message received and decrypted from the transaction management server 102. For example, the incoming message may include a notification of successful receipt and storage of payment certificate 304. In step 1004, the processor 204 may increment the receive counter. The reception counter may be a counter indicating the number of received messages sent to the transaction management server 102. The reception counter may be stored in a memory 212 such as MPA404, or may be stored in a database encrypted using an advanced storage key. It will be apparent to those skilled in the art that step 1004 may be an optional step and may only be used if the counter is used to validate the data message.
In step 1006, the processing unit 204 may encrypt the received message. The received message may be encrypted using the encryption key 414 stored in the encryption application 410. Alternatively, the encryption key may be stored in MPA404 or a locally encrypted database. The encryption key used to encrypt the received message may be a private key that is part of a key pair, and the transaction management server 102 has a corresponding public key. In step 1008, the processing unit 204 may generate a reception authentication code based on the encrypted received message. In some embodiments, the receive authorization code is generated using the same rules, algorithms and / or processes that were used to generate the reference authorization code shown in step 912 of FIG. 9 above. You may.
In step 1010, the transmitter 206 of the mobile device 104 may send a receipt notification message to the transaction management server 102. The reception notification message may be received by the reception unit 502 of the transaction management server 102, or may include at least a reception authentication code, an encrypted reception message, and a reception counter. In some embodiments, the receipt notification message may be transmitted to the transaction management server 102 using a mobile communication network such as a cellular network associated with the mobile device 104.
In step 1014, the processing unit 504 of the transaction management server 102 may increment the confirmation counter. The confirmation counter indicates the number of messages received from the mobile device 104 and may be used to verify the messages received from the mobile device 104. The confirmation counter may be stored in memory 510 of transaction management server 102 or other suitable data storage device. For example, in some embodiments, the confirmation counter may be stored in the account profile 602 associated with the mobile device 104. In one example, each account profile 602 is a confirmation counter (and / or, for example, a message counter) used for messages sent between the transaction management server 102 and the mobile device 104 associated with the corresponding trading account. May include. It will be apparent to those skilled in the art that step 1014 may be an optional step and may not be performed if the counter does not have to be used to validate the reply message.
In step 1016, the processing unit 504 may generate a confirmation authentication code. The verification authorization code may be generated based on the encrypted incoming message contained in the inbound notification message and uses the same rules, algorithms and / or processes that were used to generate the message authorization code. May be generated. In step 1018, the processing unit 504 may verify the reception counter included in the reception notification message by comparing with the confirmation counter. In step 1020, the processing unit 504 may verify the received authentication code by comparing it with the message authentication code to ensure that the message was sent from the authorized mobile device 104.
After the counter (eg, if applicable) and the authentication code have been verified, in step 1022, processing unit 504 may decrypt the encrypted message contained in the received notification message. The encrypted message may be decrypted using a stored encryption key or other suitable decryption method. The encrypted message may be decrypted to retrieve the received message generated by the mobile device 104. In step 1024, processing unit 504 may perform some appropriate action, if necessary, based on the data contained in the received message. For example, if the received message contains instructions for successful reception and storage of disposable key 306, processing unit 204 may enable the corresponding disposable key 604 in the corresponding account profile 602.
<u style="single">Data message validation</u> FIG. 11 shows a process 1100 that verifies a data message received from the transaction management server 102 by the mobile device 104.
In step 1102, the processing unit 204 of the mobile device 104 encrypted the encryption key, the authentication generation key, and the rules and / or algorithms for using and applying them using memory 212 or advanced storage key. It may be stored in a local storage device such as a locally encrypted storage device. In step 1104, the receiver 202 of the mobile device 104 may receive a data message from the transaction management server 102. In some embodiments, the data message may be received from the transaction management server 102 after establishing mutual authentication between the two devices using the process described above as shown in FIG. The data message may include at least a message counter, a message authentication code and an encrypted message.
In step 1106, processing unit 204 may increment the reference counter. The reference counter may be stored in memory 212 or other local storage device and may be used to indicate the number of messages received from transaction management server 102. In some examples, the reference counter may be incremented using an algorithm, in which case the reference counter is not incremented using a serial number, but on mobile device 104 (eg, via MPA404) and It may be incremented via an algorithm known to the transaction management server 102.
In step 1108, the processing unit 204 may verify the message counter included in the received data message. Verification of the message counter may include comparing the value of the message counter with the value of the reference counter after the increment. If the validation fails, this may indicate that the source of the data message is not Transaction Management Server 102 or an untrusted source. If the verification fails, at step 1110, processing unit 204 may perform one or more appropriate actions related to the failure to receive and / or verify the data message. For example, the processing unit 204 may discard the data message, notify the transaction management server 102, lock the associated payment profile 302, or perform other actions that will be apparent to those skilled in the art. You may.
If the message counter validation is successful, process 1100 may proceed to step 1112 and the encrypted message may be padded. The padding of an encrypted message may include adding a value to the encrypted message or its associated data. Padding must be performed by a mutually aware mobile device 104 and transaction management server 102 and must be reproduced in order for an unauthorized entity to successfully send or receive a data message without authentication. It may be another function with, so it may be used to enhance the security of the message verification process. It will be apparent to those skilled in the art that step 1112 may be an optional step. In some embodiments, step 1112 may be applied in some examples of process 1110. For example, encrypted messages may be padded when the reference counter is incremented by a certain value.
At step 1114, processing unit 204 may generate a reference authentication code. The reference authorization code may be generated based on an encrypted message (eg, padded where applicable) using one or more rules or algorithms, such as the rules or algorithms stored in step 1102. .. In some embodiments, the reference authentication code may be a key or a value generated by applying the key to an encrypted message. In step 1116, the processing unit 204 may verify the message authentication code received in the RNS message. As an alternative to identifying whether a received data message was sent from an authorized source (eg, Transaction Management Server 102), message verification code validation compares the message verification code with the generated reference verification code. May include doing.
If the verification of the message authentication code fails, process 1100 may proceed to step 1110, and the failure process is executed. If the verification of the message authentication code is successful, the encrypted message included in the received data message may be decrypted by the processing unit 204 in step 1118. The message may be decrypted using one or more encryption / decryption keys, rules and / or algorithms, such as those stored in mobile device 104 in step 1102. For example, the encryption key 414 stored in the encryption application 410 in memory 212 may be used to decrypt the encrypted message. In step 1120, processing unit 204 may appropriately perform one or more operations based on the content of the decrypted message. For example, if the decryption message includes a disposable key 306, the disposable key 306 may be stored in the appropriate payment profile 302 of the card database 208, which may be encrypted using an advanced storage key.
<u style="single">Advanced memory key</u> FIG. 12 shows the generation and use of advanced storage keys by the mobile device 104 to secure and store data in the mobile device 104, such as payment profile 302, and the security protection in the mobile device 104 without the use of secure elements. Indicates other data that may be stored and accessed.
The device information 402 stored in the memory 212 of the mobile device 104 may include three or more device information 1202 shown as device information 1202a, 1202b and 1202c in FIG. Each device information 1202 may be associated with a mobile device 104. In some examples, each device information 1202 may be specific to the mobile device 104. In another example, one or more of the device information 1202 does not have to be specific to the mobile device 104 (eg, model number), but is specific to the mobile device 104 when the three device information 1202s are combined. It may be (eg, a unique combination). The device information 1202 may be data that does not change during the period of use of the mobile device 104.
The processing unit 204 of the mobile device 104 may generate the fingerprint 1204 of the mobile device based on the three device information 1202a, 1202b, 1202c. The mobile device fingerprint 1204 may be a value specific to the mobile device 104, even if it is generated using one or more rules or algorithms stored in memory 212, such as in program code 406 of MPA404. Good. The fingerprint 1204 of the mobile device may be, for example, a numerical value, a hexadecimal number, a character string, or the like.
The processing unit 204 may be further configured to generate a variety of values 1208 using the fingerprint 1204 of the mobile device. The various values may be generated by combining the fingerprint 1204 of the mobile device, the instance identifier 408 of the MPA404, and the random number 1206. The random number value 1206 may be a random number or a pseudo-random number generated by the processing unit 204. In some examples, the random number 1206 may be generated according to one or more rules or algorithms stored in memory 212. The combination of the mobile device fingerprint 1204, instance identifier 408 and random number 1206 may be further performed using one or more rules or algorithms stored in program code 406 of MPA404 and the like. Secure the data associated with an instance of MPA404 so that multiple MPA404 installations cannot access the data stored by other instances of MPA404 by using the instance identification 408 to generate a variety of values. It may be possible to store it.
After that, the processing unit 204 may generate the advanced storage key 1210 by applying the encryption key 414 stored in the encryption application 410 to the various values 1208. In some examples, the advanced storage key 1210 may be generated by decrypting the multi-valued 1208 using the encryption key 414. In another example, the advanced storage key 1210 may be the value obtained as a result of encrypting the multivalued 1208 with the encryption key 414. In some embodiments, the advanced storage key 1210 may be generated as a result of performing white box encryption with encryption key 414 and a variety of values 1208.
Once the advanced storage key 1210 is generated, processing unit 204 may use the advanced storage key 1210 to encrypt the local database 1210. The local database 1210 may consist of, for example, a card database 208, one or more payment profiles 302, a portion of memory 212, or other suitable data source. In some examples, the local database 1210 may be part of another database within the mobile device 104, such as the card database 208. For example, the card database 208 may include multiple local databases 1212, such as a separate local database 1212 for each instance of MPA404 for storing payment profiles 302 associated with MPA404. Therefore, the resulting encrypted local database 1214 is secured so that it cannot be accessed by any other application program inside or outside the mobile device 104 other than a specific instance of MPA404, which contains an instance identification value of 408. Data may be stored. Therefore, the encrypted local database 1214 may be ideal for storing payment certificates 304, disposable keys 306 and other account data, and secures sensitive account information without the use of secure elements. And store it.
In some embodiments, the storage key may be further 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 transmission unit 206 of the mobile device 104 may transmit the generated random number value 1206 to the transaction management server 102. In some examples, the instance identifier 408 may be further transmitted to the transaction management server 102, or may be previously possessed by the transaction management server 102, such as when registering the MPA404. After that, the transaction management server 102 generates the advanced storage key 1210 itself, encrypts the data such as the payment certificate 304 and the disposable key 306 provided to the mobile device 104 using the advanced storage key 1210, and moves the data. Encrypted data may be transmitted to the device 104. The mobile device 104 may store the already encrypted data in the encrypted local database 1214.
<u style="single">The first exemplary method of generating a payment certificate in a payment transaction</u> FIG. 13 shows a method 1300 of generating a payment certificate in a payment transaction involving the use of two application ciphers to secure and use the payment certificate on a mobile device 104 without a secure element.
In step 1302, at least the disposable key (eg, disposable key 306) may be stored in the memory associated with the trading account (eg, payment profile 302). In some embodiments, the memory 302 may be a non-secure element memory within a mobile communication device (eg, mobile device 104). In step 1304, a personal identification number (PIN) may be received by a receiver (eg, receiver 202 and / or input 214).
In step 1306, the first session key (eg, first session key 308) may be identified by a processor (eg, processor 204). In step 1308, the second session key (eg, the second session key 310) may be generated by the processor 204 based on at least the stored disposable key 306 and the received PIN.
In step 1310, the first application cipher may be generated by the processor 204 based on at least the first session key 308. In step 1312, a second application cipher may be generated by the processor 204 based on at least the second session key 310.
At step 1314, at least the first application cipher and the second application cipher may be transmitted by a transmitter (eg, transmitter 206) for use in payment transactions. In some embodiments, the first application cipher and the second application cipher may be transmitted to a POS device (eg, POS110). In one embodiment, method 1300 may further include storing the card master key associated with the trading account in memory 302, in which case identifying the first session key 308 is at least the stored card master. It involves generating a first session key 308 by the processor 204 based on the key.
In some embodiments, method 1300 may further include storing an application transaction counter (eg, application transaction counter 312) in memory 302, in which case identifying the first session key 308 may include. It involves generating a first session key 308 by the processor 204 based on at least the stored application transaction counter 312. In one embodiment, method 1300 may further include verifying the received PIN with processing device 204 before generating the second session key 310. In a further embodiment, the processing device 204 may be configured to generate an invalid second session key 310 if the verification of the received PIN fails.
<u style="single">A second exemplary method of generating a payment certificate in a payment transaction</u> FIG. 14 shows method 1400 for generating a payment certificate in a payment transaction involving the use of two application cryptographic validations of the payment certificate generated by the mobile device 104 without the use of secure elements.
In step 1402, at least the card master key (eg, the first card master key 612) may be stored in the memory associated with the trading account (eg, account profile 602). In step 1404, the first session key (eg, first session key 606) may be generated by the processor (eg, processor 504) based on at least the stored card master key 612. In step 1406, a second session key (eg, a second session key 608) may be generated by the processor 504.
In step 1408, the first application cipher may be generated by the processor 504 based on at least the first session key 606. In step 1410, a second application cipher may be generated by the processor 504 based on at least the second session key 608. In step 1412, at least the first application cipher and the second application cipher may be transmitted by the transmitter (eg, transmitter 506) for use in the payment transaction.
In one embodiment, method 1400 may further include storing the trading account sequence number associated with the trading account in memory 602, in which case the first session key is further based on the stored trading account sequence number. .. In some embodiments, method 1400 may further include storing a second card master key associated with the trading account (eg, second card master key 614) in memory 602, in which case the first. The second session key 608 is based on at least the stored second card master key 614.
In one embodiment, method 1400 receives the first corresponding application cipher and the second corresponding application cipher by the receiving device (eg, receiver 502) and (i) the first received by the processing device. Validate the corresponding application cipher in based on the generated first application cipher and (ii) verify and pay for the received second corresponding application cipher based on the generated second application cipher. It may further include transmitting the result of the verification by the transmitter 506 for use in the transaction. In a further embodiment, the first corresponding application cipher and the second corresponding application cipher may be received from a POS device (eg, POS110). In another further embodiment, the verification results may be sent to the financial institution associated with the trading account (eg, Issuer 106).
<u style="single">An exemplary way to handle a data message</u> FIG. 15 shows a method 1500 for processing a data message, such as a remote notification message, received via a remote notification service, including receiving and verifying by the mobile device 104 without using a secure element.
In step 1502, at least the encryption key may be stored in memory (eg, memory 212). In some embodiments, the memory 212 may be a non-secure element memory within a mobile communication device (eg, mobile device 104). In step 1504, the data message is received by a receiving device (eg, receiver 202), in which case the data message may include at least an encrypted message and a message authentication code, the message authentication code including at least a portion of the encrypted message. Generated using. In some embodiments, the data message may be a remote notification service message received via the remote notification service.
In step 1506, a reference authentication code may be generated by a processing device (eg, processing unit 204) using at least a portion of the encrypted message contained in the received data message. In one embodiment, the memory 212 may further include one or more authentication code generation rules, where the reference authentication code is one or more authentication codes stored for a portion of the cryptographic message contained in the received data message. It may be generated based on applying a generation rule. In step 1508, the received data message may be verified by the processor 204 based on (checking) checking the generated reference authentication code for the message authentication code contained in the received data message. 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 is a reference containing the message counter contained in the received data message. It may be further verified by the processor 204 based on checking against the counter.
In step 1510, the encrypted message included in the data message may be decrypted by the processing device 204 using the stored encryption key, and the decrypted message may be acquired. In one embodiment, the decryption message may include at least one of a digitized card profile (eg, payment certificate 304) and a disposable key (eg, disposable key 306) used in a payment transaction. .. In some embodiments, the method 1500 may further include checking the data format of the decrypted message by the processor 204 based on one or more data formatting rules (data formatting rules).
In one embodiment, the method 1500 may further include transmitting a reception notification in response to the received data message by a transmitting device (eg, transmitting unit 206). In a further embodiment, the method 1500 performs one or more operations by the processing device 204 based on the decrypted message and one or more as a result of or as a result of performing the one or more operations. The operation-based reply message is generated by the processing device 204, and the generated reply message is encrypted by the processing device 204 using the stored encryption key in order to obtain the encrypted reply message. And may further include generating a reply authorization code by the processor 204 using at least a portion of the encrypted reply message, in which case the incoming notification sent will be the encrypted reply message and reply. Includes verification code. In yet another embodiment, the memory 212 may further include a reply counter, and the received notifications transmitted may further include a reply counter.
In some embodiments, method 1500 may further include padding the encrypted message contained in the received data message with the processing device 204 using the padding key, in which case a reference authentication code is generated. A portion of the encrypted message used for this is a padded encrypted message. In a further embodiment, the padding key may be an encryption key. In another further embodiment, the memory 212 may further include an authentication code padding algorithm, and padding an encrypted message using a padding key is based on applying the padding key to the authentication code padding algorithm. It may include padding an encrypted message.
<u style="single">An exemplary way to create an advanced storage key</u> FIG. 16 shows a method 600 of creating an advanced storage key for securing, encrypting, and storing local data on a mobile device 104 without the use of secure elements.
In step 1602, at least device information (eg, device information 402) related to the mobile communication device (eg, mobile device 104), program code (eg, program) related to the first application program (eg, mobile payment application 404). The code 406) and the program code (eg, program code 412) associated with the second application program (eg, cryptographic application 410) may be stored in the memory of the mobile communication device 104 (eg, memory 212). If the program code 406 associated with the first application program 404 includes at least an instance identifier (eg, instance identifier 408) and the program code 412 associated with the second application program 410 contains at least the first key (eg, encryption). Includes key 414).
In some embodiments, device information 402 may include one or more unique identifiers associated with mobile communication device 104. In one embodiment, the instance identifier 408 may be specific to an instance of the first application program 404. In some embodiments, the second application program 410 may be configured to use the first key to perform white box encryption. In one embodiment, the first key may be a dynamic key. In some embodiments, the program code 412 associated with the second application program 410 may be included in the program code 406 associated with the first application program 404. In a further embodiment, the second application program 410 may be an executable function of the first application program 404.
In step 1604, the fingerprint of the device associated with the mobile communication device 104 (eg, the fingerprint of the mobile device 1204) is stored in device information 402 by executing program code 406 associated with the first application program 404. Based on this, it may be generated by a processing device (for example, processing unit 204). In step 1606, a random number value (eg, random number value 1206) may be generated by the processor 204 by executing program code 406 associated with the first application program 404. In some embodiments, the random number 1206 may be a random number or a pseudo-random number.
In step 1608, a variety of values (eg, a variety of values 1208) are included in at least the fingerprint 1204 of the generated device, the generated random number 1206, and the instance identifier 408 in the program code 406 associated with the first application program 404. It may be created by the processing apparatus 204 based on the above. In step 1610, the created diversified value 1208 is the first key stored in the program code 412 associated with the second application program 410 by executing the program code 412 associated with the second application program 410. The storage key (eg, advanced storage key 1210) may be obtained by being decrypted by the processing device 204 using.
In some embodiments, the method 1600 uses the storage key 1210 to store the protection data in the local database of the mobile communication device 104 (eg, the local database 1212) and the protection data stored in the local database 1212. It may further include encrypting with the processing device 204. In one embodiment, method 1600 stores the program data associated with the first application program 404 in memory 212 and stores the generated random number 1206 in the program data associated with the first application program 404. It may further include things.
In one embodiment, method 1600 transmits at least a random number 1206 by a transmitter (eg, transmitter 206) and one or more encryption parameters, each encrypted using storage key 1210. Receiving by a receiving device (eg, receiving device 202) may further include storing one or more received encryption parameters in the local database 1212 of the mobile communication device 104. In a further embodiment, the storage key 1210 may be transmitted to a third party (eg, transaction management server 102), and one or more encryption parameters may be received from the third party 102. In some further embodiments, the instance identifier 408 may be transmitted by the transmitter 206.
<u style="single">Computer system architecture</u> FIG. 17 shows a computer system 1700 in which an embodiment of the present invention or a part thereof may be realized as computer readable code. For example, the transaction management server 102 and mobile device 104 of FIG. 1 may be implemented in computer system 1700 using non-transitory computer-readable media containing hardware, software, firmware, instructions, or a combination thereof. , May be implemented in one or more computer systems or other processing systems. Hardware, software, or any combination thereof, modules and configurations used to implement the methods of FIGS. 7, 8, 9A, 9B, 10A, 10B, 11 and 13-16. Elements may be realized.
If programmable logic is used, such logic may be performed on a commercially available processing platform or dedicated equipment. Embodiments of the invention include multicore multiprocessor systems, minicomputers, mainframe computers, computers linked or clustered with distributed capabilities, and pervasive or small computers that may be embedded in virtually any device. It will be appreciated by those skilled in the art that it can be implemented using a variety of computer system configurations, including. For example, at least one processor device and memory may be used to implement the embodiments described above.
The processor units or devices described herein may be a single processor, a plurality of processors, or a combination thereof. The processor device may have one or more processor "cores". The terms "computer program medium," "non-temporary computer-readable medium," and "computer-enabled medium" described herein are installed on removable storage 1718, removable storage 1722, and hard disk drive 1712. It is used to generally indicate a tangible medium such as a hard disk.
Various embodiments of the present invention will be described with respect to the computer system 1700 of this example. Reading this description will reveal to those skilled in the art how to achieve the present invention using other computer systems and / or computer architectures. Operations may be described as a series of operations, but some of the operations may actually be performed in parallel and simultaneously and / or in a distributed environment and are accessed by a single processor machine or a multiprocessor machine. It may be executed using program code stored locally or remotely. Further, in some embodiments, the order of operations may be rearranged without departing from the spirit of the present invention.
The processor device 1704 may be a dedicated or general purpose processor device. Processor unit 1704 may be connected to communication infrastructure 1706 such as buses, message queues, networks, and multi-core message passing schemes. The network may be any network suitable for performing the functions disclosed herein, including local area networks (LANs), wide area networks (WANs), wireless networks (eg, WiFi), and mobile. It may include a body communication network, satellite network, internet, fiber optics, coaxial cable, infrared, radio frequency (RF) or any combination thereof. Other suitable network types and configurations will be apparent to those skilled in the art. The computer system 1700 may further include main memory 1708 (eg, random access memory, read-only memory, etc.) and may further include auxiliary memory 1710. The auxiliary memory 1710 may include a hard disk drive 1712 and a removable storage device drive 1714 such as a floppy disk drive, a magnetic tape drive, an optical disk drive, or a flash memory.
The removable storage drive 1714 may read and / or write to and from the removable storage 1718 in a known manner. The removable storage device 1718 may include a removable storage medium that may be read and written by the removable storage device drive 1714. For example, if the removable storage drive 1714 is a floppy disk drive or a universal serial bus port, the removable storage 1718 may be a floppy disk or a portable flash drive, respectively. In one embodiment, the removable storage device 1718 may be a non-temporary computer-readable recording medium.
In some embodiments, the auxiliary memory 1710 may include other means such as a removable storage device 1722 and interface 1720 that allow a computer program or other instruction to be loaded into the computer system 1700. As will be apparent to those of skill in the art, examples of such means include program cartridges and cartridge interfaces (eg, found in video game systems), removable memory chips (eg EEPROM, PROM, etc.) and associated sockets. It may also include other removable storage devices 1722 and interface 1720.
Data stored in computer system 1700 (eg, main memory 1708 and / or auxiliary memory 1710) can be stored in optical storage (eg, compact discs, digital multipurpose discs, Blu-ray discs, etc.) or magnetic tape storage (eg, hard disk drives). ) Etc. may be stored on a suitable computer-readable medium of some kind. The data may be configured in any kind of suitable database configuration such as relational database, structured query language (SQL) database, distributed database, object database and so on. Appropriate configurations and types of storage devices will be apparent to those skilled in the art.
Computer system 1700 may further include communication interface 1724. Communication interface 1724 may be configured to allow software and data to be transferred between the computer system 1700 and an external device. Examples of communication interface 1724 may include modems, network interfaces (eg, Ethernet cards), communication ports, PCMCIA slots / cards, and the like. The software and data transferred via the communication interface 1724 may be in the form of an electrical signal, an electromagnetic signal, an optical signal or any other signal that will be apparent to those skilled in the art. The signal travels through a communication path 1726 which may be configured to carry the signal and may be implemented using wires, cables, fiber optics, telephone lines, cell phone links, radio frequency links and the like. You may.
Computer system 1700 may further include display interface 1702. The display interface 1702 may be configured to allow data to be transferred between the computer system 1700 and the external display 1730. Examples of display interface 1702 may include high definition multimedia interface (HDMI), digital visual interface (DVI), video graphic array (VGA) and the like. The display 1730 was transmitted via the display interface 1702 of computer system 1700, which includes a cathode line tube (CRT) display, a liquid crystal display (LCD), a light emitting diode (LED) display, a capacitive touch display, a thin film transistor (TFT) display, and the like. It may be any suitable type of display that displays data.
The computer program medium and the computer-usable medium may refer to memories such as main memory 1708 and auxiliary memory 1710, which may be memory semiconductors (eg, DRAM, etc.). These computer program products may be a means of providing software to the computer system 1700. Computer programs (eg, computer-controlled logic) may be stored in main memory 1708 and / or auxiliary memory 1710. Computer programs may be further received via communication interface 1724. Such computer programs, when executed, may allow the computer system 1700 to perform the methods described herein. In particular, when a computer program is executed, the processor device 1704 describes the method described herein by reference to FIGS. 7, 8, 9A, 9B, 10A, 10B, 11 and 13-16. May be realized. Therefore, such a computer program may represent the control of computer system 1700. When the present invention is realized using software, the software is stored in a computer program product and computer system 1700 using removable storage drive 1714, interface 1720 and hard disk drive 1712 or using communication interface 1724. May be loaded into.
A technique consistent with the present invention provides secure elements, among other features, including sending and validating remote notification service messages and using advanced storage keys to secure and store data. Provide systems and methods for processing payment transactions using mobile devices without use. Although various exemplary embodiments of the disclosed systems and methods have been described above, it should be understood that they are presented only for illustration and not limitation. This is not exhaustive and does not limit the invention to the exact form disclosed. Modifications and modifications are possible in view of the above teachings, or may be obtained from practicing the invention without departing from the scope of the invention.
This application is filed under 35 USC 119 (e), provisional patent applications 61 / 979,113 (filed April 14, 2014), 61 / 910,819 (filed December 2, 2013) 61 / 951,842 (2014). March 12, 2014), 61 / 955,716 (filed March 19, 2014), 61 / 979,132 (filed April 14, 2014), 61 / 980,784 (filed April 17, 2014), and above all , Provisional patent applications 61 / 979,122 (filed April 14, 2014), 61 / 996,665 (filed April 14, 2014), which are incorporated herein by reference.
18 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| JP2010026949A | Cites | Japan |
| JP2013090046A | Cites | Japan |
| JP2003006582A | Cites | Japan |
| JP2006019824A | Cites | Japan |
| JP2011091494A | Cites | Japan |
| JP2013081028A | Cites | Japan |
| JP2011130012A | Cites | Japan |
| JP2011004079A | Cites | Japan |
124 members in 18 offices
Priority claims32
| Document | Office | Kind | Date |
|---|---|---|---|
| 201361910819 | United States of America | P | |
| 201361910819 | United States of America | P | |
| 61910819 | United States of America | – | |
| 201461951842 | United States of America | P | |
| 201461951842 | United States of America | P | |
| 61951842 | United States of America | – | |
| 201461955716 | United States of America | P | |
| 201461955716 | United States of America | P | |
| 61955716 | United States of America | – | |
| 201461979113 | United States of America | P | |
| 201461979113 | United States of America | P | |
| 201461979122 | United States of America | P | |
| 201461979122 | United States of America | P | |
| 201461979132 | United States of America | P | |
| 201461979132 | United States of America | P | |
| 61979113 | United States of America | – | |
| 61979122 | United States of America | – | |
| 61979132 | United States of America | – | |
| 201461980784 | United States of America | P | |
| 201461980784 | United States of America | P | |
| 61980784 | United States of America | – | |
| 201461996665 | United States of America | P | |
| 201461996665 | United States of America | P | |
| 61996665 | United States of America | – | |
| US201361910819P | – | – | – |
| US201461951842P | – | – | – |
| US201461955716P | – | – | – |
| US201461979113P | – | – | – |
| US201461979122P | – | – | – |
| US201461979132P | – | – | – |
| US201461980784P | – | – | – |
| US201461996665P | – | – | – |
Members124
| Document | Office | Kind | |
|---|---|---|---|
| US2015154595A1 | United States of America | A1 | |
| US2015154596A1 | United States of America | A1 | |
| US2015156176A1 | United States of America | A1 | |
| CA2932105A1 | Canada | A1 | |
| CA2932346A1 | Canada | A1 | |
| WO2015084755A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO2015084797A1 | World Intellectual Property Organization (WIPO) | A1 | |
| CA2933336A1 | Canada | A1 | |
| WO2015160385A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AU2014357343A1 | Australia | A1 | |
| AU2014357381A1 | Australia | A1 | |
| AU2014391256A1 | Australia | A1 | |
| SG11201604876YA | Singapore | A | |
| IL245958A0 | Israel | A0 | |
| IL245958D0 | Israel | D0 | |
| IL245965A0 | Israel | A0 | |
| IL245965D0 | Israel | D0 | |
| IL246109A0 | Israel | A0 | |
| IL246109D0 | Israel | D0 | |
| KR20160091418A | Republic of Korea | A | |
| KR20160106059A | Republic of Korea | A | |
| CN106031207A | China | A | |
| EP3077972A1 | European Patent Office (EPO) | A1 | |
| EP3078220A1 | European Patent Office (EPO) | A1 | |
| CN106062799A | China | A | |
| CL2016001351A1 | Chile | A1 | |
| CN106104605A | China | A | |
| KR20160132105A | Republic of Korea | A | |
| MX2016007217A | Mexico | A | |
| MX2016007218A | Mexico | A | |
| JP2017504871A | Japan | A | |
| JP2017505000A | Japan | A | |
| EP3132406A1 | European Patent Office (EPO) | A1 | |
| AU2014357381B2 | Australia | B2 | |
| MX2016010086A | Mexico | A | |
| CL2016001353A1 | Chile | A1 | |
| EP3078220A4 | European Patent Office (EPO) | A4 | |
| JP2017513248A | Japan | A | |
| AU2014391256B2 | Australia | B2 | |
| BR112016012359A2 | Brazil | A2 | |
| BR112016012527A2 | Brazil | A2 | |
| EP3077972A4 | European Patent Office (EPO) | A4 | |
| ZA201603938B | South Africa | B | |
| NZ720688A | New Zealand | A | |
| HK1226890A | Hong Kong, China | A | |
| HK1226890A1 | Hong Kong, China | A1 | |
| HK1227146A | Hong Kong, China | A | |
| HK1227146A1 | Hong Kong, China | A1 | |
| AU2014357343B2 | Australia | B2 | |
| EP3132406A4 | European Patent Office (EPO) | A4 | |
| JP6224254B2 | Japan | B2 | |
| AU2017245412A1 | Australia | A1 | |
| UA115500C2 | Ukraine | C2 | |
| UA115501C2 | Ukraine | C2 | |
| KR101809221B1 | Republic of Korea | B1 | |
| KR20170139689A | Republic of Korea | A | |
| RU2016126401A | Russian Federation | A | |
| RU2016126407A | Russian Federation | A | |
| RU2642821C2 | Russian Federation | C2 | |
| AU2018200422A1 | Australia | A1 | |
| NZ721223A | New Zealand | A | |
| SG10201800179UA | Singapore | A | |
| SG10201801008SA | Singapore | A | |
| JP2018050300A | Japan | A | |
| US9953315B2 | United States of America | B2 | |
| RU2653290C1 | Russian Federation | C1 | |
| MX356939B | Mexico | B | |
| US10007909B2 | United States of America | B2 | |
| SG10201803986RA | Singapore | A | |
| JP6353537B2 | Japan | B2 | |
| US2018204212A1 | United States of America | A1 | |
| RU2661910C1 | Russian Federation | C1 | |
| RU2663319C2 | Russian Federation | C2 | |
| CA2932346C | Canada | C | |
| CA2933336C | Canada | C | |
| KR101903709B1 | Republic of Korea | B1 | |
| KR20180108907A | Republic of Korea | A | |
| JP2018164281A | Japan | A | |
| AU2018200422B2 | Australia | B2 | |
| UA117951C2 | Ukraine | C2 | |
| JP6438027B2 | Japan | B2 | |
| MX361684B | Mexico | B | |
| MX361793B | Mexico | B | |
| JP2019004474A | Japan | A | |
| RU2018113732A | Russian Federation | A | |
| RU2018113732A3 | Russian Federation | A3 | |
| RU2682840C2 | Russian Federation | C2 | |
| NZ735128A | New Zealand | A | |
| CA2932105C | Canada | C | |
| KR102025816B1 | Republic of Korea | B1 | |
| JP6603765B2This record | Japan | B2 | |
| AU2019250276A1 | Australia | A1 | |
| CN106031207B | China | B | |
| KR20200018729A | Republic of Korea | A | |
| CN106104605B | China | B | |
| IL246109A | Israel | A | |
| IL246109B | Israel | B | |
| KR102103377B1 | Republic of Korea | B1 | |
| KR20200044130A | Republic of Korea | A | |
| JP2020074566A | Japan | A |
13 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 6603765
- Publication, DOCDB
- 6603765
- Publication, EPODOC
- JP6603765B
- Application
- 142528
- Application, DOCDB
- 2018142528
- Application, EPODOC
- JP20180142528
Titles2
- Japanese
- セキュアエレメントを用いずに移動装置に対する遠隔通知サービスメッセージをセキュアに送信するための方法およびシステム
- English
- Methods and systems for securely sending remote notification service messages to mobile devices without the use of secure elements
Classification
- CPC, 12
- G06Q20/3821
- G06Q20/4012
- H04W12/08
- H04L63/06
- H04L2463/102
- H04L63/083
- G06Q20/3829
- H04L63/0428
- H04W12/041
- H04L63/062
- H04W12/06
- H04W12/04
- IPC, 3
- H04L9 32
- H04L9 08
- G06F21 33
