Cloud-based transactions methods and systems
22 claims: 12 independent, 10 dependent
- 1通信デバイスを使用してトランザクションを行う時に前記通信デバイスのセキュリティを向上させるための方法であって、 限定的使用キー(LUK)の利用を限定する1つ又は複数の限定的使用閾値のセットに関連付けられる前記LUKを、リモート・コンピュータから受信することと、 前記通信デバイスによって、前記LUKを使用してトランザクション暗号文を生成することと、 前記トランザクションを行うために、実アカウント識別子 の代わりに トークン と前記トランザクション暗号文 をアクセス・デバイスへ送信すること、を含む方法であって、少なくとも、前記LUKの利用が前記1つ又は複数の限定的使用閾値のセットを超えたかどうかに基づいて、前記トランザクションは許可される、方法。
- 2前記通信デバイスはセキュア要素内に前記LUK又は前記トークンを記憶しない、請求項1に記載の方法。
- 3前記LUKを受信することは、前記LUKの生成に関する情報を含むキー・インデックスを受信することをさらに含む、請求項1に記載の方法。
- 4前記キー・インデックスは、前記トランザクションを行うために前記トランザクション暗号文と共に前記アクセス・デバイスへ送信される、請求項3に記載の方法。
- 5前記キー・インデックスは前記LUKがいつ生成されるかを示す時間情報を含む、請求項3に記載の方法。
- 6前記キー・インデックスは、前記LUKを生成するためのシードとして使用される疑似乱数を含む、請求項3に記載の方法。
- 7前記1つ又は複数の限定的使用閾値のセットは、 前記LUKが有効である時 間 を示す有効期間、 前記LUKが有効である所定のトランザクション数、及び、 前記LUKが有効である総トランザクション量を示す累積トランザクション量、のうちの少なくとも1つを含む、請求項1に記載の方法。
- 8前記1つ又は複数の限定的使用閾値のセットは、国際利用閾値及び国内利用閾値を含む、請求項1に記載の方法。
- 9前記LUKは第1のLUKであり、 前記通信デバイス上に記憶されるトランザクション・ログから導き出されるトランザクション・ログ情報を含む、第2のLUKについての補充要求を、前記リモート・コンピュータへ送信することと、 前記補充要求内の前記トランザクション・ログ情報が前記リモート・コンピュータにおけるトランザクション・ログ情報に一致する時、前記第2のLUKを前記リモート・コンピュータから受信することと、をさらに含 み、ここで、前記第2のLUKは、前記第1のLUKが有効で無くなった後に更なるトランザクションを実行するために前記通信デバイスによって使用されて別のトランザクション暗号文を生成するためのものである 、請求項1に記載の方法。
- 10前記補充要求は、前記LUKの生成に関する情報を含む第1のキー・インデックスをさらに含み、 前記第2のLUKを受信することは前記第2のLUKに関連付けられた第2のキー・インデックスを受信することを含む、請求項 9 に記載の方法。
- 11前記通信デバイス上に記憶される前記トランザクション・ログは、 前記LUKを使用して行われるそれぞれのトランザクションについて、 対応するトランザクションの時間を示すトランザクション・タイムスタンプと、 前記対応するトランザクションに関連付けられるアプリケーション・トランザクション・カウンタ値と、 前記対応するトランザクションが、磁気ストライプ・ベース・トランザクション又は集積チップ・ベース・トランザクションであるかどうかを示すトランザクション・タイプ・インジケータと、を含む、請求項 9 に記載の方法。
- 12前記リモート・コンピュータへ送信される前記トランザクション・ログ情報は、前記LUKを使用して少なくとも前記トランザクション・ログにわたって計算される認証コードを含む、請求項 9 に記載の方法。
- 13前記補充要求は、前記LUKによって行われる次のトランザクションにおいて前記1つ又は複数の限定的使用閾値のセットまで使い果たされることになると判断することに応答して送信される、請求項 9 に記載の方法。
- 14前記補充要求は、前記LUKに関連付けられる前記1つ又は複数の限定的使用閾値のセットまで使い果たされたと判断することに応答して送信される、請求項 9 に記載の方法。
- 15前記補充要求は、前記LUKを補充するように前記通信デバイスに要求するプッシュ・メッセージを受信することに応答して送信される、請求項 9 に記載の方法。
- 16前記LUKは、 第1の暗号化キーを使用してアカウント情報を暗号化して第2の暗号化キーを生成し、 前記第2の暗号化キーを使用して前記キー・インデックスを暗号化して前記LUKを生成する、ことによって生成される、請求項 3 に記載の方法。
- 17第1の暗号化キーを使用してアカウント情報を暗号化して第2の暗号化キーを生成することは、 前記第1の暗号化キーを使用して前記アカウント情報を暗号化して前記第2の暗号化キーの第1の部分を生成し、 前記アカウント情報 の各ビット を反転 させて反転されたアカウント情報を生成し 、そして 前記第1の暗号化キーを使用して当該反転されたアカウント情報を暗号化して前記第2の暗号化キーの第2の部分を生成する、ことを含む、請求項 16 に記載の方法。
- 18前記第2の暗号化キーを使用して前記キー・インデックスを暗号化して前記LUKを生成することは、 前記キー・インデックスを第1の値でパディングして第1のパディングされたキー・インデックス情報を生成し、 前記第1のパディングされたキー・インデックス情報を暗号化して前記LUKの第1の部分を生成し、 前記キー・インデックスを第2の値でパディングして第2のパディングされたキー・インデックス情報を生成し、そして 前記第2のパディングされたキー・インデックス情報を暗号化して前記LUKの第2の部分を生成する、ことを含む、請求項 16 に記載の方法。
- 19前記トランザクション暗号文は、 前記LUKの第1の部分を使用してトランザクション情報を暗号化し、 前記LUKの第2の部分を使用して当該暗号化されたトランザクション情報を解読し、そして 当該解読されたトランザクション情報を前記LUKの前記第1の部分を使用して再暗号化する、ことを含む、請求項1に記載の方法。
- 20前記トランザクション暗号文は、 前記LUKを使用して所定の数値列を暗号化し、そして 当該暗号化された所定の数字列を10進法化する、ことによって生成される、請求項1に記載の方法。
- 21当該暗号化された所定の数字列を10進法化することは、 前記暗号化された所定の数字列から数字を抽出して第1のデータ・ブロックを形成し、 前記暗号化された所定の数字列から16進数字を抽出しそして抽出された16進数字を数字に変換して第2のデータ・ブロックを形成し、 前記第1のデータ・ブロックと前記第2のデータ・ブロックとを連結する、ことを含む、請求項 20 に記載の方法。
- 22プロセッサと、 前記プロセッサに結合されたメモリと、からなる通信デバイスであって、 前記メモリは、当該通信デバイスを使用してトランザクションを行うとき前記通信デバイスのセキュリティを強化するための動作を実行するモバイル・アプリケーションを記憶し、当該動作は請求項1乃至 21 のいずれかに記載の方法を実施する動作である、通信デバイス。
Independent claims22
289 paragraphs, as filed
This application is incorporated herein by reference in its entirety for all purposes, US Provisional Patent Application No. 61 / 918,643 filed December 19, 2013, US Provisional Patent Application filed February 18, 2014. Priority of Patent Application No. 61 / 941,227, US Provisional Patent Application No. 61 / 982,169 filed on April 21, 2014, and US Provisional Patent Application No. 61 / 983,635 filed on April 24, 2014. Claims the interests of.
The increased capabilities of portable communication devices have made it possible to use portable communication devices such as smartphones as payment devices for non-contact transactions. For example, a portable communication device may be placed close to an access device such as a point-of-sale (POS) terminal to transfer account information from the portable communication device to the access device for transaction. it can. A subscriber identification module (SIM) card, a specialized integrated chip embedded in a portable communication device, or a specialized integrated chip to provide a secure operating environment for securely storing account information on a portable communication device. , Secure elements such as specialized components provided as aftermarket solutions are used. During a transaction, the secure element is the contactless interface of the portable communication device (eg near-field communication (NFC)). It communicates directly with the communication) transceiver) and passes the payment data to the contactless reader of the access device. The secure element is considered secure because the access information is stored in the tamper resistant hardware. The hardware protects account information from malware or viruses that can infect operating systems or applications running on portable communication devices.
However, the secure elements used in portable communication devices are typically not under the control of financial institutions, but rather under the control of mobile network operators (MNOs). As a result, issuers and / or payment processors may not be able to directly access the secure element to equip the secure element with account credit certificates and payment functionality. To access the secure element, issuers and / or payment processors have commercial agreements and technical connectivity with the parties controlling the secure element to perform over-the-air (OTA) personalization of the secure element. May have to be established. This is both a cumbersome and complex process. In addition, the addition of incorporating secure elements into the manufacturing costs of portable communication devices has increased the cost of finished portable communication devices.
Therefore, in some cases, it may be desirable to use a portable communication device that does not have a secure element for making payments. Alternatively, if the portable communication device has a secure element, it may be desirable not to rely on the use of the secure element. However, since the secure element is not used, there are concerns about transaction security.
The embodiments of the present invention address these and other issues individually and collectively. Specifically, the embodiments of the present invention address issues related to security concerns when performing payment transactions on mobile communication devices that do not have or rely on secure elements.
<p> The embodiments of the present invention provide techniques for improving the security of a communication device (eg, a portable communication device) when conducting a transaction. The techniques described herein can be used with communication devices that may or may not have secure elements, which are secure against safeguard account credit certificates. This is because it does not require the use of elements. The embodiments of the present invention rather utilize limited use account parameters that may have a limited lifetime and, upon expiration, the limited use account parameters are replenished from the cloud (eg, a remote computer). It may no longer be available for conducting transactions until it is done. Therefore, transactions performed using the techniques described herein are sometimes referred to as "cloud-based transactions."</p>
<p> According to some embodiments, one way to improve the security of a communication device when conducting a transaction using the communication device is to limit the use of a limited-use key (LUK) or It can include receiving a LUK associated with a set of multiple limited usage thresholds from a remote computer. The method is to generate a transaction ciphertext using LUK by the communication device and to send a real account identifier and a token instead of the transaction ciphertext to the access device by the communication device to perform the transaction. Can also be included. At a minimum, transactions can be allowed based on whether LUK usage exceeds a set of one or more limited usage thresholds.</p><p> According to some embodiments, the communication device is a processor and a memory that stores a mobile application that is coupled to the processor and performs actions to improve the security of the communication device when performing a transaction using the communication device. Can be included. The behavior is to receive a LUK associated with one or more sets of limited use thresholds that limit the use of a limited use key (LUK), and to use the LUK to generate a transactional ciphertext. , Sending tokens in lieu of real account identifiers and transaction ciphertexts to carry out transactions. At a minimum, transactions can be allowed based on whether LUK usage exceeds a set of one or more limited usage thresholds.</p><p> According to some examples, a way to improve the security of a communication device when conducting a transaction using the communication device is to encrypt the account information with a computer with a first encryption key and a second encryption key. Generating and encrypting key index information using a second key to generate a Limited Use Key (LUK), which has information about LUK generation. It can include encryption, including the key index. The method can also include providing the LUK and key index to the communication device to facilitate the generation of transactional ciphertext for transactions performed using the communication device. Transactions can be allowed based on LUK and transaction ciphertext.</p><p> According to some embodiments, the method for improving the security of a communication device when conducting a transaction using the communication device is to encrypt the account information to the computer and the computer when executed by the processor. A memory that stores computer-readable code that encrypts with a key to generate a second encryption key and uses the second key to encrypt key index information to generate a limited-use key (LUK). Including, the LUK and key index can be provided to the communication device to facilitate the generation of transaction ciphers for transactions performed using the communication device. The key index information may include a key index that contains information about the generation of the LUK. Transactions can be allowed based on LUK and transaction ciphertext.</p>
<figref num="1">It is a block diagram of an example of a cloud-based transaction system with some examples.</figref><figref num="2">It is a communication flow diagram of an example of an enrollment and provisioning process according to some examples.</figref><figref num="3">It is a communication flow diagram of an example of executing an integrated chip-based transaction according to some examples.</figref><figref num="4">It is a communication flow diagram of an example of executing a magnetic stripe-based transaction according to some examples.</figref><figref num="5">It is a figure which shows the example of the transaction verification log by some examples.</figref><figref num="6">It is a communication flow diagram of an example of a postpaid settlement verification process according to some examples.</figref><figref num="7">It is a communication flow diagram of the example of the account parameter replenishment process by some examples.</figref><figref num="8">It is a figure which shows the example of the process for generating a transaction ciphertext by some examples.</figref><figref num="9">It is a figure which shows the example of the encryption function by some examples.</figref><figref num="10">It is a flow chart of the example of the method for improving the security of a portable communication device by some examples.</figref><figref num="11">It is a flow diagram of an example of another method for improving the security of a portable communication device according to some examples.</figref><figref num="12">It is a block diagram of an example of a portable communication device according to some examples.</figref><figref num="13">It is a state diagram of the example of the mobile application in the manual mode by some examples.</figref><figref num="14">It is a state diagram of the example of the mobile application in the always connected mode by some examples.</figref><figref num="15">It is a state diagram of an example of a mobile application in an always-on mode by on-device verification according to some examples.</figref><figref num="16">It is a block diagram of an example of a computer system according to some examples.</figref>
The embodiments of the present invention provide methods, devices and systems for cloud-based transactions that can be performed by communication devices with or without secure elements. The techniques described herein utilize card emulation techniques (eg, Host Card Emulation (HCE)) to emulate smart cards on communication devices (eg, portable communication devices). However, mobile applications running on portable communication devices can be allowed to perform contactless transactions. In a card emulation environment, mobile applications are operating systems (OS: operating) of portable communication devices without a secure element. You can access the non-contact interface of portable communication devices (eg near field communication (NFC) transceivers) via system). Compared to secure element implementations, the card emulation approach allows issuers and / or payment processors to access mobile applications on portable communication devices without having to allow access to secure elements through mobile network operators. Account credit certificates and payment functionality can be provisioned, reducing the technical and commercial complexity of issuers and / or payment processors.
By removing payment functionality and account credit certificate control from the area of secure elements, the tamper-resistant hardware-based security provided by secure elements can no longer rely on safeguard account information. The account credit certificate may be stored in the memory of a portable communication device that is not part of the secure element, such as the general memory of the portable communication device, without the need for the secure element to be present. As such, account credit certificates may be accessible by malware or viruses that can infect applications or operating systems on portable communication devices.
Use non-renewed account credit certificates stored on portable communication devices when account lifetime is valid to improve the security of portable communication devices when conducting transactions without leveraging secure elements Instead, the cloud-based techniques described herein provision portable communication devices with limited use account parameters that have limited use or lifetime. Once the limited use account parameters have been used for limited use or lifetime, the same set of limited use account parameters can no longer be used to carry out further transactions. The portable communication device is replenished with new limited use account parameters in order to carry out further transactions using the portable communication device. The limited use account parameters provided for portable communication devices can be repeatedly renewed or replenished from the network (also referred to as the "cloud") for the duration of the account. Accounts stored on mobile application software and / or portable communication devices by managing the distribution and lifecycle of limited-use account parameters between a set of network-based capabilities and portable communication devices. There is only a limited security risk in that the credit certificate is threatened, which means that the stolen limited use account parameters can only be used for a small number of transactions or a limited total amount at best. Because there is.
Before discussing the details of some examples of the present invention, explanations of some terms may be helpful in understanding the various examples.
A "communication device" may be a device that includes one or more electronic components (eg, an integrated chip) that can communicate with another device. A "portable communication device" is a communication device that a user can carry and operate. Portable communication devices can provide remote communication capabilities to the network. Portable communication devices can be configured to send and receive data or communications to and from other devices. Portable communication devices include mobile phones (eg, smart phones, cellular phones, etc.), tablets, portable media players, personal digital assistants (PDAs) devices, and wearable computing devices (eg, wristwatches). ), In the form of mobile devices such as electronic readers, or in the form of cards (eg smart cards) or fobs. Examples of portable communication devices can also include portable computing devices (eg, laptops, netbooks, ultrabooks, etc.).
A "server computer" can include a powerful computer or group of computers. For example, a server computer can be a large mainframe, a group of minicomputers, or a group of servers that act as a unit. In one example, the server computer may be a database server attached to a web server. The server computer can be coupled to the database and may include any hardware, software, other logic circuits, or the aforementioned combinations to meet the demands of one or more client computers. A server computer can include one or more computer devices and uses any of the various computing structures, deployment configurations, and compilations to meet the demands of one or more client computers. be able to.
An "issuer" typically refers to a corporate entity (eg, a bank) that maintains a user account associated with a portable communication device, such as an account enrolled in a mobile application installed on the portable communication device. There is. Issuers can also issue account parameters associated with an account to portable communication devices. The issuer may be associated with a host system that performs some or all of the issuer's functions on behalf of the issuer.
A "merchant" may typically be an entity that engages in a transaction and may be an entity that sells goods or services or provides access to goods or services.
An "acquire" may typically be a corporate entity (eg, a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities can perform both issuer and acquirer functions. Some embodiments may include issuers-acquirers of such a single entity.
An "access device" is any suitable device for communicating with a merchant computer or payment processing network and for interacting with payment devices, user computer devices, and / or user mobile devices. It may be there. The access device may generally be located in any suitable location, such as the location of the merchant. The access device may be of any suitable shape. Some examples of access devices include POS devices, cellular phones, PDAs, personal computers (PCs), tablet PCs, handheld special readers, set-top boxes, and electronic teller machines (ECRs:). electronic cash register), automated teller machine (ATM), virtual cash register (VCR) Includes register), kiosks, security systems, access systems, and websites. The access device can use any suitable contact or non-contact mode of operation from or for sending and receiving data associated with the portable communication device. In some embodiments where the access device can include a POS terminal, any suitable POS terminal can be used and can include a reader, a processor, and a computer-readable medium. The reading device may include any suitable contact or non-contact mode operation. For example, an exemplary card reader can include a radio frequency (RF) antenna for interacting with a portable communication device, an optical scanner, a bar code reader, or a magnetic stripe reader.
The "permission request message" may be an electronic message sent to request permission for a transaction. The permission request message can be sent to the payment processing network and / or the issuer of the payment card. The authorization request message according to some embodiments can comply with ISO 8583, a standard for systems that exchange electronic transaction information associated with payments made by users using payment devices or payment accounts. The authorization request message can contain information that can be used to identify the account. The authorization request message can also contain additional data elements such as one or more service codes, expiration dates, and so on. The authorization request message may also be used to identify and / or allow the transaction, as well as any information associated with the current transaction, such as transaction volume, merchant identifier, merchant location, and so on. It can contain transactional information such as any other information. The authorization request message can also include other information such as information identifying the access device that generated the authorization request message, information about the location of the access device, and so on.
The "permission response message" may be an electronic message reply to the permission request message. The authorization response message can be generated by the issuing financial institution or the payment processing network. The authorization response message is just an example, but one or more of the following: Approval-transaction approved, reject-transaction not approved, or call center-answer with more information pending Yet, the merchant may include one or more status indicators, such as having to call a toll-free licensed phone number. The authorization response message is also the code returned by the credit card issuing bank in response to the authorization request message in the electronic message (either directly or through the payment processing network) to the merchant computer indicating the approval of the transaction. May include an authorization code. The code can serve as proof of authorization. As mentioned above, in some embodiments, the payment processing network can generate or send an authorization response message to the merchant.
The term "permission" and its derivatives validate an endpoint's credit certificate (including, but not limited to, applications, people, devices, processors and systems) and who should be declared at that endpoint. May refer to processes that can ensure.
The term "verification" and its derivatives may refer to the process of utilizing information to determine if the underlying subject is valid under a given set of circumstances. Verification may include any comparison of information to ensure that certain data or information is accurate, valid, accurate, legitimate, and / or good.
A "token" may include a surrogate identifier for certain information. For example, a payment token can include a payment account identifier that is a proxy for an account identifier, such as a primary account number (PAN). For example, the token can contain a set of alphanumeric characters that can be used on behalf of the original account identifier. For example, the token "4900 0000 0000 0001" is changed to PAN "4 147 0900 0000". Can be used in place of "1234". In some embodiments, the token may be "formatted" and may have a numeric format that matches the account identifier used in existing payment processing networks (eg, the ISO 8583 financial transaction message format). it can. In some embodiments, tokens can be used in place of PAN to initiate, allow, combine, or resolve settlement transactions. Tokens can also be used to represent the original credit certificate in other systems where the original credit certificate would typically be provided. In some embodiments, the token value can be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derived. Further, in some embodiments, the token format can be configured such that the entity receiving the token can be identified as a token and the entity issuing the token can be recognized.
The "real account identifier" may include the original account identifier associated with the payment account. For example, the real account identifier may be the primary account number (PAN) issued by the issuer of the card account (eg, credit card, debit card, etc.). For example, in some embodiments, the real account identifier can contain a 16-digit number such as "4147 0900 0000 1234". The first six digits of the real account identifier (eg, "414709") can represent a real issuer identifier (BIN: bank identification number) that can identify the issuer associated with the real account identifier.
"Account Parameters" may refer to information related to an account that can be used to make transactions with the account. Examples of account parameters are used to generate information that can be used to identify a user's account (eg, real account identifiers, alternate account identifiers, tokens, etc.), data or information related to the status of the account, and cryptographic information. It can include one or more keys used, data or information related to one or more keys, and the like. Account parameters can be semi-static or dynamic. Dynamic account parameters can be account parameters that have a limited lifetime, and when they expire, they no longer carry out transactions until the account parameters are replenished, refreshed, or renewed. Cannot be used to do. Dynamic account parameters may be replenished frequently during the duration of the account. Semi-static account parameters can be account parameters that have a longer lifetime than dynamic account parameters and can be replenished less frequently than dynamic account parameters, or at all for the duration of the account. Cannot be replenished.
The "key" may refer to one piece of information used in a cryptographic algorithm to translate the input data into another representation. The cryptographic algorithm may be a cryptographic algorithm that transforms the original data into an alternative representation, or a decryption algorithm that transforms the encrypted information into the original original data. Examples of cryptographic algorithms can include triple data encryption standard (TDES), data encryption standard (DES), advanced encryption standard (AES), and so on. ..
"Ciphertext" may refer to an encrypted representation of certain information. The ciphertext is used by the recipient to ensure that the ciphertext generator has the correct key, for example, by encrypting the underlying information with a valid key and comparing the result with the received ciphertext. You can judge whether you have it.
The "limited use threshold" may refer to conditions that limit the use of one piece of information. When the fundamental conditions are met, the limited use threshold may be exceeded or exhausted to that threshold. For example, a limited use threshold can include a validity period that indicates how long an piece of information is valid, after which the limited use threshold is exceeded or exhausted to that threshold. The information may be invalid and may no longer be available. As another example, the limited use threshold can include the number of times an piece of information can be used, and when that one piece of information is used that number of times, the limited use threshold is exceeded or exhausted to that threshold. And that one piece of information may be invalid and may no longer be available.
Details of some embodiments of the present invention are described herein.
I. Account Parameters A cloud-based transaction system, according to some examples, provides a set of functionality for managing the deployment and utilization of account parameters for transactions performed using portable communication devices. provide. Account parameters (sometimes referred to as "account credit certificates") are assigned to the account associated with the user (for example, financial account, bank account, payment account, etc.) that can be used to perform transactions on the user's account. Related information. Account parameters allow a portable communication device to make a transaction to a user's account (for example, by placing the portable communication device in close proximity to a contactless reader of an access device such as a point of sale (POS) terminal). As such, it can be provided or provisioned for portable communication devices.
Account parameters can include semi-static sets of data and dynamic sets of data, and some or all of the account parameters may be limited use account parameters. A semi-static set of data is an identifier that can be used to identify the account associated with a user (eg, an account identifier such as the primary account number (PAN), an alternative account identifier such as an alternate PAN, or on behalf of an account identifier. It may include (such as a token), expiration date, and / or other account details or data that are not necessarily changed to an extended period or, in some embodiments, the duration of the account. A dynamic set of data may include one or more keys, information associated with one or more keys, and / or other dynamic data with a limited lifetime, and account retention. It is repeatedly refreshed or replenished during the period. A dynamic set of data can be used or associated with on-device generation of dynamic transaction ciphertext, or can represent dynamic transaction data during a settlement transaction.
A dynamic set of data may be of limited use in the sense that the dynamic set of data can be used only for a limited amount of time or with a limited number of transactions, and is limited by the dynamic set of data. When it is used up, it may need to be renewed, refreshed, updated or replenished. For example, a dynamic set of data can include a Limited Use Key (LUK) that is used as an encryption key to generate a transactional ciphertext during a transaction. A LUK may be associated with one or more sets of limited use thresholds that limit the use of LUK, in which case the use of LUK will be exhausted up to one or more sets of limited use thresholds or said. Beyond the set, further transactions made using that LUK will be rejected, even if the underlying account is still good. The set of one or more limited usage thresholds to be enforced can be determined, for example, by the issuer of the account or by a cloud-based payment platform that provides cloud-based transaction services.
A set of one or more limited usage thresholds spans a validity period that indicates how long the LUK is valid, a given number of transactions in which the LUK is valid, and / or one or more transactions in which the LUK is valid. It can include at least one of the cumulative transaction volumes indicating the total transaction volume to be totaled, or any combination thereof. For example, a LUK may be valid for a validity period of 5 days, and transactions made using that LUK after 5 days have passed since the LUK was generated may be rejected. As another example, a LUK may be valid for a given number of 5 transactions, and the 6th transaction (and any subsequent transaction) made using that LUK may be rejected. As a further example, a LUK may be valid for a cumulative transaction volume of $ 500, and transactions made using that LUK after it has already been used for transactions totaling more than $ 500 will be rejected. You can do it.
It should be understood that the limited usage values mentioned above are merely examples and other usage limits can be used. For example, the number of transaction usage limits can be set to the number of transactions in the range of 2 to 10 times, or the number of transactions in the range of 5 to 50 times, and the cumulative transaction volume is in the range of $ 100 to $ 5,000. Or, it can be set to a value in the range of $ 10 to $ 1,000.
In some embodiments, the number of limited use thresholds for a transaction can be set to one transaction, such that each LUK is valid for only one transaction. However, in some embodiments, the network bandwidth available to the portable communication device may be limited, or the portable communication device may not always have continuous network connectivity. As such, the number of transactional usage thresholds reduces, for example, the frequency and amount of LUK replenishment over a period of time, and therefore the amount of network traffic used by portable communication devices over a period of time. To reduce it, some embodiments can be set to one or more transactions (eg, five transactions).
In some embodiments, the set of one or more limited usage thresholds may also include an international usage threshold and a domestic usage threshold that indicate separate limits for international transactions versus domestic transactions. For example, the number of transactions that can enable LUK can be more domestic transactions than international transactions if international transactions are considered more risky. A set of one or more limited use thresholds can also include low and high transaction thresholds that indicate separate limits for low to high transactions. For example, the number of transactions that can enable LUK is lower than high-value transactions (for example, LUKs that are valid for 5 transactions over $ 20) (for example, 10 transactions for less than $ 20). You can have more LUKs in effect for), so that low-value transactions trigger less frequent LUK replenishment than high-value transactions.
In some embodiments, the set of one or more limited usage thresholds associated with an account replaces the previous LUK when the LUK is replenished, with the new LUK being different from the previous LUK. It may be changed so that it can have a usage limit of. This may occur, for example, based on changes in consumer propensity to consume, the location of portable communication devices, or timing. For example, if the user's recent pattern is to perform many high-value transactions, or if transaction activity is expected to increase during the holiday season, the new LUK will have a higher usage limit. You may. As another example, a new LUK may have a lower usage limit if the location of the portable communication device indicates that the user may be traveling to a country at high risk of fraud. ..
In embodiments where the LUK is associated with a limited use threshold of 2 or greater, the use of LUK is exhausted when any one of the limited use thresholds is exceeded, or when a combination of limited use thresholds is exceeded. there is a possibility. Therefore, LUK replenishment may be triggered when any one of the limited use thresholds is exceeded or is likely to be exceeded, or when a combination of limited use thresholds is exceeded or is likely to be exceeded.
In some embodiments, the limited usage threshold associated with the account's LUK may have different usage limits configured in different components or entities of the cloud-based transaction system. In other words, the various components or entities, various utilization of specific limited use thresholds to trigger the recruitment of LUK may have a limit for. Components or entities that may consist of various usage limits can include, for example, a user's portable communication device, cloud-based service provider, and / or issuer / host system. According to some examples, the usage limit for portable communication devices can be set lower than the usage limit for cloud-based service providers, and the usage limit for cloud-based service providers can be set lower than the usage limit for issuers. it can. For example, a LUK may have a limited usage threshold with a lifetime, an on-device usage limit for triggering LUK replenishment in a portable communication device can be set to 2 days, and a cloud-based service provider. The service provider usage limit in is set to 4 days, and the issuer usage limit in issuer can be set to 5 days. In this example, the portable communication device will typically start replenishing LUK after 2 days. However, if the portable communication device is turned off or loses network connectivity, the cloud-based service provider can start replenishing the LUK after 4 days, or ensure that the LUK does not become obsolete. If the LUK has not been redesigned before, the issuer can start replenishment after 5 days.
In some embodiments, the various components or entities of the cloud-based transaction system may consist of various limited usage thresholds that can trigger LUK replenishment. For example, a set of on-device limited usage thresholds configured on a portable communication device determines the lifetime and the number of transactions that will trigger LUK replenishment initiated by the portable communication device. A cloud-based service provider and / or an issuer / host system can further or alternatively include a LUK replenishment initiated by a cloud-based service provider and / or an issuer / host system. It may consist of a cumulative transaction volume to trigger. In other words, different components or entities can monitor different types of conditions or limited usage thresholds for triggering LUK replenishment.
In some embodiments, one or more sets of limited usage thresholds are account traits (eg, where different accounts can have different usage limits), portable communication device traits (eg, of the user). Different portable communication devices can have different usage limits even if the underlying account is the same) and / or mobile application characteristics (eg, different mobile applications are the same portable). It may be installed on a communication device and / or may have different usage limits, even if the underlying account is the same). In some embodiments, the LUK can also have other usage restrictions, such as what type of merchant, what particular merchant, or what geographic location the LUK can use. Specific rules or risk parameters for triggering LUK replenishment and / or setting limited usage thresholds can be determined by the issuer or cloud-based transaction provider.
A dynamic set of data can also include a key index associated with the LUK. The key index can contain information about LUK generation. For example, the key index may be used as a seed to generate its corresponding LUK. The key index can contain time information (eg, a time stamp) that indicates when the LUK is generated, and / or the LUK is redesigned for a particular account, mobile application, or portable communication device. It can include a replenishment counter value indicating the number of times it has been or has been replenished. In some embodiments, the replenishment counter value can indicate the number of times the LUK has been replenished within a predetermined period, and the replenishment counter value may be reset when each predetermined period elapses. This predetermined period can correspond to, for example, the smallest time unit that can be determined from the time information, but other predetermined periods can be used. As an example, if the time information contained in the key index indicates the time until the current LUK is generated, the counter value can indicate the number of times the LUK was replenished within that time. In some embodiments, the LUK can include an application transaction counter value that indicates the number of transactions previously performed by the mobile application of the portable communication device at the time of LUK generation, or cloud-based transactions. It can include pseudo-random numbers generated by service providers or by suitable entities such as issuers involved in processing transactions. Understand that a key index can contain one or more pieces of information about LUK generation, and that one or more or all of the information contained in a key index can be used as a seed to generate a LUK. I want to be.
In some embodiments, the semi-static set of data can also include a limited use account parameter that has its own set of limited use thresholds and / or its own set of usage restrictions. In some embodiments, account identifiers such as PAN can be used and stored on portable communication devices, but PAN may be valid for the duration of the account and is a wide variety of various types of transactions (eg, for example). It can be used for card presentation transactions, online transactions, etc.). As such, in order to further improve the security of the portable communication device and to reduce the impact if the account parameters are compromised, in some embodiments, the PAN is used and stored in the portable communication device. Alternatively, an alternate account identifier (eg, alternate PAN) or token can be used on behalf of the account identifier.
An account can have one or more alternate account identifiers and / or tokens associated with the account. Each alternative account identifier or token may be limited to the type of transaction in which the alternative account identifier or token can be used. For example, an account may be associated with a first token that can only be used for online transactions and a second token that can only be used for cloud-based transactions, and is done online using cloud-based tokens. -The transaction will be rejected. Other types of usage restrictions can include restrictions on what type of merchant or which merchant, and / or which geographic location the alternate account identifier or token can be used for.
The alternate account identifier or token can also have its own set of limited usage thresholds (eg, validity period, number of transactions, and / or cumulative transaction volume, etc.). In some embodiments, the limited usage threshold of the alternate account identifier or token can have a higher usage limit than the dynamic set of data (eg LUK), thereby replenishing the alternate account identifier or token. Less frequently. For example, an alternate account identifier or token can have a validity period of one year, while a LUK can have a validity period of five days. As another example, an alternate account identifier or token may be valid for up to 2000 transactions, while a LUK may be valid for up to 5 transactions. In some embodiments, the usage limit of the alternate account identifier or token can also be set to be the same as that of a dynamic set of data (eg LUK), thereby replenishing the alternate account identifier or token. It should be understood that it should occur at the same time as the dynamic set of data.
II. Overview of the cloud-based transaction system In a cloud-based transaction system, the issuer of an account constitutes the service portfolio characteristics and thus the risk parameters, and thus the account parameters of accounts belonging to a particular portfolio. Set a limited usage threshold. Limited usage thresholds can be used to manage triggers for refreshing or replenishing account parameters on provisioned portable communication devices. Implementing some core functionality in the system to deploy and utilize account parameters to ensure that cloud-based transactions are processed according to the risk parameters specified in the service profile for the account. To manage. These features can include provisioning, active account management, payment validation, transaction processing, lifecycle management, and deferred payment processing.
Provisioning involves incorporating enrolled accounts and account parameters such as identifiers (eg, alternate account identifiers such as alternate PANs or tokens) to identify enrolled accounts for cloud-based transactions, and Creating the first dynamic set of data to ensure that account parameters are used only for limited use after delivery to portable communication devices, and established for the portfolio to which the enrolled account belongs. It may be accompanied by inheriting the existing service profile (eg, limited usage threshold). Depending on the type of transaction supported, the dynamic set of data can include LUK and / or other dynamic data such as key indexes. LUK is used, for example, by a portable communication device during a transaction to calculate a transaction ciphertext, or limited use dynamic data such as a verification value, and a verification value (eg, dynamic card verification (dCVV)). Can support traditional transactions using value)).
After the account is provisioned on a portable communication device, relevant service profile details (eg, limited use thresholds) are shared with transaction processing software and entities in the system so that transaction authorization decisions are properly addressed. Can be ensured. In addition, service profile details (eg, limited usage thresholds) are provided to the on-device cloud-based transaction software for mobile applications installed on the portable communication device, with account parameters on the portable communication device. Can be ensured that it is properly managed. As discussed above, the service profile can initiate account parameter replenishment because different usage limits for triggering account parameter replenishment can be set for different entities in the cloud-based transaction system. It is possible to set various usage limits for each limited usage threshold that should be set in various various entities (eg, portable communication devices, cloud-based service providers, issuers, etc.).
After provisioning, the cloud-based transaction system can perform active account management and initiate renewal or replenishment of account parameters. The active account management process can be triggered by a transaction processing activity or initiated by a mobile application running on a portable communication device. If the service profile parameter for a particular account indicates that the account parameter on the device should be replaced (eg, exhausted to the usage limit of that parameter), then the active account management capability is this. Attempts to connect to a portable communication device to recognize and replenish account parameters. Further or alternately, if the on-device service profile parameter managed by the mobile application indicates that account parameter replenishment is or will be required, the mobile application is the account parameter. You can request replenishment.
To perform payment verification, cloud-based transaction systems also provide on-device verification functionality to the payment processing network before or during the transaction, initiating the transaction by the appropriate user of the portable communication device. Has the ability to perform a level of verification that has been and was intended. On-device verification can include a cardholder verification method (CVM) that can be used to verify payments for provisioned accounts. Specific rules can be enacted for what can be used as a CVM as part of a service profile for a portfolio (eg screen locks, application passcodes, etc.), and provisioning, active account management, and Can be shared with transaction processing power.
After the account is provisioned, the transaction processing power of the system can give the recognition that the transactions to be executed are performed using the cloud-based account. When a cloud-based account is identified, the transaction processing power of the cloud-based transaction system is applied to the issuer with service profile parameters (eg, limited usage thresholds) validated against the issuer in the transaction processing message. And can be ensured to be communicated. This ability also ensures that any required active account management action is initiated. For example, if the account identity provided during the transaction corresponds to an account identifier range (eg, PAN range) that is dedicated to cloud-based transactions, or the account identity is cloud-based. Accounts can be identified as cloud-based accounts when dealing with alternative PANs or tokens that are used only for transactions.
After the account is provisioned for cloud-based transactions, the lifecycle management functionality allows the user or issuer to manage the lifecycle of the provisioned account. Lifecycle management events such as account suspension or deletion may be consumer driven. For example, a consumer may trigger account suspension or deletion from a portable communication device by reporting the loss or theft of the portable communication device and / or associated card, or the user may from the portable communication device. You may choose to remove the provisioned account. Lifecycle management events can also be issuer driven, for example, based on risk management or account reissue activities. In some embodiments, other parties, including merchants or multi-issuer mobile wallet providers, who may be involved in the processing of cloud-based transactions or the management of cloud-based accounts, are living. You can also start a cycle action.
FIG. 1 shows a cloud-based transaction system 100 with some examples. The core components of System 100 are the cloud-based payments platform (CBPP) 180 and the mobile application platform (MAP). Including platform) 170, it is possible to manage cloud-based transactions performed using the portable communication device 101. The CBPP180 is sometimes referred to as a remote computer and may be implemented using one or more computing devices or computers, such as one or more server computers, issuers, payment processors, and / or. Can be associated with or operated by a cloud-based service provider, such as another suitable entity. CBPP180 manages cloud-based accounts, provides validation capabilities for cloud-based transactions, manages lifecycle messages from issuer / host system 172 or MAP170, and even lifecycle management events. You can also start. The CBPP180 can also assist the issuer / host system 172 with postpaid payment functionality to reduce the risk to counterfeit account parameters and limit exposure to account parameters stored on the device. For example, CBPP180 can be used to facilitate the request of issuer / host system 172 for payment transactions and / or periodic postpaid payment verification of the validity of account parameter replenishment requests using postpaid payment information. be able to.
The CBPP180 also has an issuer master derivation key (MDK) from which a limited use key (LUK) for cloud-based transactions is derived. It is possible to implement a set of key management functions that manage key). The CBPP180 provides cloud-based account parameters (eg, alternate account identifier or token, first LUK, and associated key) to the MAP170 for the initial setup of the mobile application 112 on the portable communication device 110. You can implement a set of provisioning features that manage the preparation and delivery of (index, etc.). The CBPP180 can also manage cloud-based accounts for processing by the issuer / host system 172, with account parameters based on cloud-based account requirements or risk profiles according to CBPP180 risk management parameters. It can perform active account management functions such as the function to generate. The CBPP180 can also maintain account status for each cloud-based account and manage account parameter replenishment or refresh.
In some embodiments, the CBPP 180 can also implement or provide access to the token service 182 and / or the token vault 184. Token service 182 can be used to generate, process, and maintain tokens that are surrogate identifiers for account identifiers. During a transaction, instead of using a real account identifier (eg, primary account number (PAN)) to identify a user's account, an alternate token can be used to identify the account. By using tokens on behalf of account identifiers, the risk of including real account information can be mitigated. As shown above, tokens may have their own set of usage restrictions, and token service 182 may manage the deployment and use of tokens in accordance with the usage restrictions of the tokens. The token service 182 may communicate with the token vault 184 in which the generated tokens are stored. Specifically, the token vault 184 may maintain a mapping between the token and the real account identifier (eg, PAN) represented by the token. During transaction processing, the token vault 184 may be queried to look up the real account identifier or PAN associated with the token.
Use MAP170 to run between mobile application 112 running on portable communication device 101 and other entities in cloud-based transaction system 100, such as CBPP180 and / or issuer / host system 172. To facilitate communication. The MAP 170 can communicate with the portable communication device 101 via a communication network 192 such as the Internet. In some embodiments, the portable communication device 101 may not always have a certain network connectivity, so one of the main roles of the MAP 170 is network connectivity to the portable communication device 101. As soon as it is established, the request between the mobile application 112 and other entities in the cloud-based transaction system 100 to ensure that the request and response involving the mobile application 112 is achieved. Is to mediate. The MAP170, sometimes referred to as a remote computer, may be implemented using one or more computing devices or computers, such as one or more server computers, and is associated with the provider of mobile application 112. It is possible or can be operated by the provider. The provider of the mobile application 112 can be, for example, an issuer, bank, third party mobile wallet provider, merchant, or other suitable entity. In some embodiments, the MAP170 can be associated with, or can operate by, the same entity as the CBPP180, or they can be separated. MAP170 is shown as a separate logical entity in Figure 1 because CBPP180 is not expected to communicate directly with portable communication devices, but in some embodiments some or all of MAP170's functionality is CBPP180. Integrated as part of Please understand that it is okay to be. Examples of MAP170 can include mobile banking platforms and mobile wallet platforms.
In some embodiments, the MAP 170 implements an authentication function to authenticate the portable communication device 101 when the portable communication device 101 communicates with other entities in the cloud-based transaction system 100 via the MAP 170. Can be done. The authentication feature is that the portable communication device that communicates with the system is an authorized portable communication device and / or a portable communication device that has not been hacked, infected by malware or virus, or otherwise threatened. Can be ensured. For example, the MAP 170 can perform, request, or facilitate device fingerprinting of the portable communication device 101 in order to capture the state of the portable communication device 101 when the portable communication device 101 communicates with the MAP 170. Device fingerprinting can be done, for example, by operating system and version, applications installed on the portable communication device 101, memory usage, whether the portable communication device 101 was jailbroken, device identifiers such as the portable communication device identifier, and /. Alternatively, information about the portable communication device 101, such as other suitable device characteristics, can be captured.
The MAP170 can verify the device fingerprint collection of the portable communication device 101 for each communication session established by the portable communication device 101 or periodically (for example, once every five communication sessions, once a month, etc.). it can. That the portable communication device is not an authorized device for the account (for example, the portable communication device requesting replenishment of account parameters is a different device than the original device used to enroll the account). If device fingerprinting of a portable communication device indicates, or if device fingerprinting indicates that the portable communication device may be potentially hacked, the MAP170 prevents the portable communication device from communicating with the system. It can also warn issuers that portable communication devices may be threatened.
The MAP170 provides an enrollment feature for enrolling mobile cardholders into cloud-based transaction programs, as well as account parameters, configurations, and cloud-based payment device threshold parameters for mobile application 112. Can fulfill a set of provisioning features that facilitate the preparation and delivery of. The MAP170 provides account parameter replenishment capabilities that facilitate the account parameter replenishment process for cloud-based accounts provisioned on portable communication device 101, and issuer / host system 172, CBPP180, and / or. It can fulfill the life cycle management function of managing the life cycle messages from the mobile application 112. MAP170 reduces the risk of counterfeit account parameters, such as periodic postpaid payment validation of payment transactions or facilitating the use of postpaid payment information to demonstrate account parameter replenishment requests. It can also perform a postpaid payment function to limit exposure in account parameters stored on the portable communication device 101.
In the cloud-based transaction system 100, the portable communication device 101 can be used to perform cloud-based transactions facilitated by CBPP180 and / or MAP170. The components in the portable communication device 101 can include the device hardware 103, the mobile operating system (OS) 114, and the application environment 110 in which the mobile application 112 can reside. The device hardware 104 can include a contactless interface 108 capable of interacting with the contactless reader 162 of the access device 160. An example of a non-contact interface 108 is one or more radio frequency (RF) transceivers capable of transmitting and receiving communications using Near Field Communication (NFC), or Bluetooth, Bluetooth Low Energy (BLE: Bluetooth). It can include other radio frequencies or radio communication protocols such as low-energy), Wi-Fi, iBeacon, etc. In some embodiments, the contactless interface 108 provides a quick response (QR: quick) to the contactless reader 162 of the access device 160 when the contactless reader 162 includes an optical code scanner or reader. It can include an optical interface (eg, a display screen) for presenting payment information in the form of a response) code, or image such as a bar code.
The application environment 110 of the portable communication device 101 may host the mobile application 112 provided by the mobile application provider. For example, if the provider of the mobile application 112 is an issuer, the mobile application 112 may be a mobile banking application or a separate mobile payment application. If the provider is a mobile wallet provider such as a mobile network operator or a third party wallet provider that supports multiple issuers, the mobile application 112 may be a mobile wallet application. For a merchant, the mobile application 112 may be the merchant's own mobile application that allows the consumer to perform an e-commerce transaction or a point-of-sale transaction with that merchant, or a mobile wallet that supports multiple merchants. -It may be an application.
According to some examples, the mobile application 112 is an on-device cloud-based transaction software 113 (eg, software) that is integrated with the mobile application 112 to support cloud-based transaction capabilities. Developer Kit (SDK: software developer) Can be in the form of kit)) can be included. On-device cloud-based transaction software 113 incorporates account parameters (eg, LUK and associated key index) to generate a transactional ciphertext that is applied to the contactless interface 108. It can serve functions to facilitate cloud-based transactions, such as delivering to mobile operating system 114 for transmission. On-device cloud-based transaction software 113 can also manage initial service profile parameters (eg, limited usage thresholds). The parameters are provided after the account is provisioned to ensure that requests for account parameter replenishment and other account parameter management activities are initiated.
Mobile application 112 manages the risk profile of cloud-based accounts, maintains account status, and replenishes account parameters for each cloud-based account based on on-device threshold management parameters. Can fulfill the function of. The mobile application 112 can also manage lifecycle messages from the issuer / host system 172 or from MAP170. The mobile application 112 provides a set of features for enrolling mobile cardholders into a cloud-based transaction program, as well as cloud-based account parameters and cloud-based payment device threshold parameters received from MAP170. It can serve as a set of functions for managing reception and configuration. Mobile application 122 also provides consumer device cardholder verification (CDCVM) for cloud-based transactions. It can provide a method) function and perform a set of functions to process and respond to messages that support postpaid payment processing to limit the exposure of account parameters stored on portable communication devices. For example, the deferred payment process can include periodic deferred payment verification of the payment transaction, or use of deferred payment information to demonstrate an account parameter replenishment request.
In a secure element-based implementation, a contactless application that uses a contactless interface to communicate with the contactless reader of the access device (eg, a mobile wallet or payment application for a contactless transaction) is contactless. In order to access the interface, it will have to be coded for and run on the secure element. In some embodiments, the portable communication device 101 uses host card emulation (HCE: host) to allow the mobile application 112 to access the contactless interface 108 without the need for the use of secure elements. card emulation (API: application programming) It may include a mobile operating system (OS) 114 that implements a set of card emulation APIs such as interface). For example, the card embroidery API 116 is an application that can be encoded and executed from the mobile OS 114 of the portable communication device 101, and the mobile application 112 is transmitted from the contactless reader 162. It may include programming function calls to enable receiving, processing, and responding to transactional communications such as the Application Protocol Data Unit (ADPU). In this way, the portable communication device 101 can perform non-contact transactions without requiring access to a secure element on the portable communication device 101.
When the portable communication device 101 and the mobile application 112 are provisioned by the account parameters, the portable communication device 110 interacts with the contactless reader 162 of the access device 160 (eg, at a merchant point of sale (POS) location). This allows cloud-based transactions. The contactless reader 162 includes one or more RF transceivers capable of transmitting and receiving communications using NFC or other radio frequencies or wireless communication protocols such as Bluetooth, BLE, Wi-Fi, iBeacon. Good. In some embodiments, the non-contact reading device 162 may include an optical code scanner or reading device for performing transactions using QR codes, bar codes, and the like. The access device 160 may also include a POS receiving device 164 and / or an electronic cache register 166.
To perform a cloud-based transaction, the user of the portable communication device 101 places the portable communication device 101 in close proximity to the contactless reader 162 of the access device 160, or the contactless reader of the access device 160. Images such as QR codes or barcodes can be displayed on the screen of the portable communication device 101 for scanning by 162. The portable communication device 101 assigns an identifier (for example, an account identifier such as PAN, an alternative account identifier such as an alternative PAN, or a token) to the access device 160 to provide a user account and limited use account parameters. Additional information such as, or information derived from limited use account parameters (eg, transaction ciphers generated from LUK) can be identified. For example, in some embodiments, the account identifier or token, and additional information (eg, transaction ciphertext, account parameters, etc.) are accessed in the APDU response in response to a series of APDU commands received from access device 160. -Can be transmitted to device 160. In some embodiments, the account identifier or token, and additional information can be encoded in a QR code or bar code scanned and processed by the access device 160 to retrieve the coded information. The access device 160, or the merchant computer associated with the access device 160, then generates an authorization request message containing an account identifier or token, and additional information such as transaction ciphertext and other transaction data. A permission request message can be sent to the acquirer 174 associated with the merchant. The authorization request message can then be sent by the acquirer 174 to the payment processing network 194.
Payment processing network 194 includes authorization services, exception file services, transaction scoring services, and data processing subsystems, networks, and operations used to support and deliver clearing and clearing services. It's fine. The exemplary payment processing network can include VisaNet®. Payment processing networks such as VisaNet® can process credit card transactions, debit card transactions, and other types of commercial transaction transactions. VisaNet® may include, among other things, a VIP system (Visa Integrated Payment System) for processing permit requests and a Base II system for clearing and clearing services.
Upon receiving the authorization request message, the payment processing network 194 can send the authorization request message received from the acquirer 174 to the corresponding issuer / host system 172 of the user's account on the portable communication device 101. After the issuer / host system 172 receives the authorization request message, the authorization request message may be parsed and the information in the authorization request message may be verified. For example, the issuer / host system 172 may verify that the transaction ciphertext was generated by a valid LUK and that it did not exceed one or more sets of limited usage thresholds associated with the LUK. it can. In some embodiments, some or all of the information in the authorization request message can also be sent to the CBPP 180 for verification and processing. For example, if the issuer / host system 172 does not have the ability to verify the transaction ciphertext, the payment processing network 194 or the issuer / host system 172 sends the transaction ciphertext to CBPP180 for verification. Can be done.
The authorization response message is then sent back to the payment processing network 194 to indicate whether the current transaction is allowed (or not allowed). The payment processing network 194 then sends an authorization response message back to the acquirer 174. In some embodiments, the payment processing network 194 causes the issuer / host system 172 to make transactions, for example, by the value of the fraud risk score or by whether the limited use account parameters are validated by CBPP180. Even if you allow it, you can reject the transaction. Acquire 174 then sends an authorization response message to the merchant computer and / or access device 160. The authorization response results, which can include transaction data for the transaction, can be viewed by the access device 160 or printed on a physical receipt.
Ultimately, the clearing and clearing process can be performed by the payment processing network 194. The clearing process is the process of exchanging financial details between the acquirer and the issuer to facilitate posting to the user's payment account and arbitration of the user's clearing position. Either Acquirer 174, Payment Processing Network 194, Issuer / Host System 172, CBPP180, and / or MAP170 may be referred to as a remote computer so that an entity can communicate with other entities in System 100, and / Or it should be understood that one or more computing devices, such as one or more computers or server computers, may be included to perform one or more of the functions described herein. ..
III. Enrollment and provisioning FIG. 2 shows a communication flow diagram of an example of the enrollment and provisioning process according to some examples. The enrollment and provisioning process can be initiated from the portable communication device 201 installed with a mobile application programmed with cloud-based transaction capabilities. The mobile application is being manufactured or downloaded by a retailer, from an application store, or from an issuer or cloud-based transaction service provider, and the mobile application is a portable communication device. It can be pre-installed on the portable communication device 201 by the user who installs it on the 201. The user may add the account to the cloud-based transaction service by launching the mobile application and initiating the enrollment request 222 from the mobile application. The enrollment request 222 is sent from the portable communication device 201 to the MAP 270 and may include device information about the portable communication device 201 as well as information that can be used to identify the user and the user's account.
According to some embodiments, the MAP270 (or issuer / host system 272, or CBPP280) generates a device identifier from the device information or provisions to facilitate communication with the portable communication device 201. And the device identifier can be assigned to the portable communication device 201 during the provisioning process. The device identifier is provided to the mobile application on the portable communication device 201 and is used by the mobile application to the portable communication device 201 to other entities in the cloud-based transaction system in subsequent interactions with the system. Can be identified.
When the MAP270 receives the enrollment request 222, the MAP270 processes the request, captures the device information about the portable communication device 201, and routes the enrollment request 224 with the relevant information to the issuer / host system 272. Can be done. The issuer / host system 272 identifies and validates the user and the user's account (ID & V). Verification) can be performed and provisioning request 226 can be sent to CBPP280. Provisioning request 226 may include account identification information such as PAN to identify the user's account. In an embodiment where an alternate account identifier or token is used, the CBPP280 or issuer / host system 272 provides a token service to generate an alternate account identifier or to generate a token that will be used on behalf of the account identifier. Can be called. Upon receiving provisioning request 226, CBPP280 uses the master derived key (MDK) associated with issuer / host system 272 to provide the first set of account parameters for provisioning to portable communication device 201 (eg, for example). LUK) can be generated. In some embodiments, the issuer / host system 272 gives the CBPP180 an MDK if the MDK is maintained or managed by the issuer / host system 272, or the issuer / host system produces a LUK. And the generated LUK can be given to CBPP180. Whether the LUK is generated by CBPP180 or by the issuer / host system 272, the LUK can be generated based on a key index that acts as a seed for the generation of the LUK, and the key index. Can be shared between the CBPP180 and the issuer / host system 272 to facilitate transaction processing using LUK.
The CBPP280 then becomes the first set of account parameters such as alternate account identifiers or tokens, LUKs and key indexes, as well as other information related to transaction execution and / or processing (eg, one associated with LUKs). Alternatively, the provisioning data 228 that can contain a set of multiple limited usage thresholds) is packaged and the provisioning data 228 is transmitted to the MAP 270. The MAP270 can then send information as provisioning data 330 to the portable communication device 201. The mobile application then stores account parameters and related information on the portable communication device 201 so that the portable communication device 201 can use it to perform contactless transactions on the user's account.
In some embodiments, the various entities in the system (eg, portable communication device 201, CBPP280, and issuer / host system 272) have one or more limited usage thresholds during the enrollment and provisioning process. Note that different usage limits can be set for a set of, and each entity can trigger later account parameter replenishment at different usage limits.
If the provisioning data 330 is successfully provisioned onto the portable communication device 201, the portable communication device 201 can send an acknowledgment or acknowledgment 332 to the MAP 270. The MAP270 can also send confirmation 334 to CBPP280 and then confirmation 336 to issuer / host system 272 to complete the enrollment and provisioning process.
It should be understood that the enrollment and provisioning process described above is merely an example, and the messaging sequences in some embodiments may have various variations. In some embodiments, the roles of CBPP280 and issuer / host system 272 can be alternated. For example, the CBPP280 may receive an enrollment request 324 from the MAP270 and send a provisioning request 326 to the issuer / host system 372. As another example, the MAP270 may send confirmation 334 to issuer / host system 272, and the issuer / host system may send confirmation 336 to CBPP280.
IV. Transaction Execution Once the portable communication device is provisioned with the appropriate account parameters, the portable communication device can be used, for example, by placing the portable communication device in close proximity to the contactless reader of the access device. Can execute non-contact transactions. Depending on the capabilities of the access device, a non-contact transaction performed using the techniques described herein may be performed on an integrated chip card (referred to as an "integrated chip-based transaction"). Or as if the transaction were performed on a magnetic stripe card (referred to as a "magnetic stripe-based transaction"). In some embodiments, the number of non-contact transactions using the card emulation techniques described herein may be similar to that of secure element-based implementations. For example, according to some embodiments, it can take less than 500 milliseconds to complete a contactless transaction using card emulation.
In some embodiments, the execution of a contactless transaction using a portable communication device is a contact between a mobile application running on the portable communication device and an access device on a contactless medium such as a radio frequency wave. Messages to and from the reader (for example, Application Protocol Data (APDU)) It can be carried out by providing or exchanging Unit) and message). The message can be an APDU command sent from the contactless reader to the portable communication device and an APDU response sent from the mobile application to the contactless reader in response to the APDU command. To provide additional security, the mobile application can only be configured to respond to APDU commands received from the contactless interface or contactless controller of the portable communication device. In other words, the mobile application can be configured to ignore or reject APDU commands received from other applications or components and / or ADPU commands that the mobile application does not recognize. In some embodiments, when the mobile application receives an unrecognized APDU command from the contactless interface or contactless controller of the portable communication device, the mobile application can respond to the command with a default status word.
In some embodiments, the mobile application may change its state or its stored information of an external entity (eg, MAP, CBPP or issuer / host system via MAP, or access device). When interacting with a contactless reader), the mobile application handles the interaction atomically. In other words, the mobile application may either handle all of the functionality required by the dialogue or not at all. In this way, the mobile application may remain perceived as seen by the external entity.
During the installation of the mobile application, the mobile application registers all application identifiers (AIDs) as well as its proximity payment system environment (PPSE) name contained by the mobile application. Transactions using those AIDs can be ensured to be routed to the mobile application (for example, this can be achieved by filing in the mobile application's manifest to the mobile operating system). For example, in some embodiments, the mobile application can be registered to receive APDU commands for one or more AIDs of PPSEs named "2PAY.SYS.DDF01".
In some embodiments, the mobile application is to receive and process APDU commands for multiple AIDs (eg, AIDs defined for a particular issuer, payment processor or processing network, service provider, etc.). You can register and in some scenarios multiple AIDs can be associated with a single account. A single account may include, for example, if transactions performed on that account can be processed by different payment processing networks and / or the account has different services, features, product types, and payments associated with that account. Multiple AIDs may be associated if they can have the ability. For example, a single account is a general debit AID, and a payment processing network-specific AID associated with a single account (eg Visa). May have AID). As another example, a single account can support a variety of payment products, and each payment product can have its own AID. Multiple AIDs allow the access device to select the preferred AID, how the transaction is processed (eg, which payment processing network), and / or what is associated with or provided with the transaction. It is possible to communicate with the access device to select a service or feature. Multiple AIDs can be populated in directory entries for PPSEs and can communicate with access devices for this purpose.
The mobile application on the portable communication device not only enables the mobile application to respond with the necessary information to the contactless reader, but also possesses information about the account through the user interface of the portable communication device. You can receive, store, and / or support the generation of information related to your account so that you can provide it to others. Some or all of this information can be provided to mobile applications during the enrollment and provisioning process. Account-related information includes card designs or other visible elements that identify the account to consumers, account identification information that can identify the account to the user (eg, nickname or the last four digits of the account), and account status. Current set of account parameters (eg, active, stopped, etc.), account configuration information, transaction flow parameters (eg, information provided to the contactless reader during the transaction), account parameters (eg, LUK and key index). ) And its associated set of one or more limited usage thresholds and corresponding usage limits, as well as transaction verification logs and the like. The account configuration information is the AID (s) of the account, and this consumer verification method (s) (CVM (s)) (eg, online PIN, consumer device CVM, signature, etc.) is the account (or). AIDs supported by multiple AIDs (each AID) and their priorities, whether the account supports magnetic stripe-based transactions, and the issuer used during transaction ciphertext validation. Derived key index (DKI:) associated with the master key derivation key index) and can be included. For mobile applications that support multiple accounts with the same or different account AIDs, the mobile application also populates the contactless reader with data from the currently active account for which the account is currently active. May support concepts that can be.
The mobile application can also implement one or more counters to track the transaction activity of the mobile application. For example, a mobile application can implement a sequence counter (SC) to count how many times a mobile application has successfully requested a new account parameter for a specific account. The mobile application may also implement an application transaction counter (ATC) to count how many times the mobile application has been used to initiate a transaction.
During a transaction, the mobile application receives and stores information such as transaction flow parameters associated with the contactless transaction in order to return the required information to the contactless reader so that the transaction can be executed successfully. , And / or can be constructed dynamically. Some transaction flow parameters can be received, stored and / or constructed before a contactless transaction is initiated, while some transaction flow parameters (eg, transaction ciphertext) are dynamically constructed at transaction time. it can. For mobile applications that support multiple AIDs, various transaction flow parameters can be stored and / or generated for each AID. Examples of transaction flow parameter details (including, for example, transaction processing information and / or account data referred to below) and details of the communication exchange between the mobile application and the contactless reader. Examples will be described with reference to FIG. 3 for integrated chip-based transactions and with reference to FIG. 4 for magnetic stripe-based transactions.
Integrated Chip-Based Transaction Figure 3 shows an example communication flow between the portable communication device 301 and the access device 360 during an integrated chip-based transaction, according to some examples. In some embodiments, the communication can be in the form of ADPU commands and responses. However, it should be understood that other messages, messaging protocols, or formats can be used to exchange relevant information to carry out transactions. Communication can occur between the mobile application running on the portable communication device 301 and the non-contact reader of the access device 360. In some embodiments, the mobile application can communicate with the contactless reader using the mobile operating system card emulation API of the portable communication device 301, so the secure element (although the secure element can be used). Transactions can be performed without the need to use.
When the access device 360 detects the presence of a portable communication device 301 in close proximity to the contactless reader of the access device 360, the access device 360 may list payment applications (s) (eg, AIDs). ) May initiate a transaction by sending an application request 302 available to the portable communication device 301 to request information that can be made available on the mobile application of the portable communication device 301. In some embodiments, the available application request 302 may be in the form of an selective PPSE command. The available application request 302 may include a payment environment identifier (eg, a PPSE name such as "2PAY.SYS.DDF01") to identify the payment environment supported by the access device 360 and the mobile application.
Upon receiving the available application request 302, the mobile application on the portable communication device 301 identifies and processes the request by recognizing the payment environment identifier (eg, PPSE name) contained in the request, and the available application response. It can respond by sending the 304 back to the access device 360. The available application response 304 may include a list of available AIDs and may include a payment environment identifier (eg PPSE name) as a dedicated file name. In some embodiments, the available application response 304 may be in the form of a selective PPSE response, which is the PPSE file control information (FCI). information) may be included. For example, the available application response 304 can include a directory entry for each available AID. If the mobile application supports only one AID (regardless of the number of accounts associated with that AID), the mobile application can respond with a single directory entry for the supported AIDs. If the mobile application supports accounts with multiple AIDs, the mobile application can respond with a directory entry for each of the supported AIDs. Each directory entry contains information such as the AID, the application label associated with the AID (for example, the mnemonic associated with the AID), the application priority indicator indicating the AID priority, and the kernel identifier indicating the application's kernel preferences. , And / or can include additional information related to a particular AID. The available application (s) response 304 can also include other data such as FCI issuer discretionary data.
When the access device 360 receives the available application response 304, the access device 304 (eg, selects an AID from the available AIDs (s) received in the available application (s) response 304). A suitable application may be selected from the list of applications received in the available application response 304. In some embodiments, the selected AID can be the highest priority AID available on the mobile application supported by Access Device 360. The access device 360 can send the application selection 306 by the selected AID to the mobile application of the portable communication device 301 to continue the transaction. In some embodiments, application selection 306 can be in the form of a selection AID command.
Upon receiving the application selection 306, the mobile application on the portable communication device 301 requests transaction data from the access device 360 that may be required to execute a transaction using the selected application / AID. Can send terminal transaction data request 308 to do so. In some embodiments, the terminal transaction data request 308 may be in the form of a selective AID response and may include AID file control information (FCI) with the AID selected as the dedicated filename. The terminal transaction data request 308 may include a list of transaction data identifiers to request the appropriate data from the access device 360 and process the list of transaction data identifiers Optional Data Object List (PDOL:). processing options data object It can be in the form of list). Transactions The transaction data required by mobile applications includes terminal transaction qualifier (TTQ), allowed amount, other amount, terminal country code, terminal verification result, transaction currency code, transaction date, etc. It can include transaction types and / or unpredictable numbers. The terminal transaction data request 308 may also include FCI issuer discretionary data, application program identifiers, and other data such as language selection.
After receiving the terminal transaction data request 308, the access device 360 can send the terminal transaction data 310 requested by the mobile application to the mobile application of the portable communication device 301. In some embodiments, the terminal transaction data 310 is a Get Processing option (GPO: get processing). option) · May be sent in the form of a command and may contain the terminal transaction data requested in the processing options data object list (PDOL). In some embodiments, the terminal transaction data 310 (eg, terminal transaction qualifier (TTQ)) determines whether the access device 360 supports integrated chip-based transactions or magnetic stripe-based transactions. It can include a transaction type indicator that indicates. Therefore, in the integrated chip-based transaction shown in FIG. 3, the access device 360 indicates the transaction type in terminal transaction data 310 to indicate that the access device 360 supports integrated chip-based transactions.. Indicator can be sent. In some embodiments, the terminal transaction data 310 (eg, terminal transaction qualifier (TTQ)) determines whether the consumer validation method (CVM) is required by the access device 360 for the transaction. It can also include a CVM requirement indicator to indicate, and one or more CVM type indicators to indicate the types of CVM supported by the access device 360. Examples of CVMs that may be supported by Access Device 360 are online PINs, signatures, and / or, such as passcodes used on portable communication devices 301 to unlock screens or mobile applications. It can include a consumer device CVM (CDCVM).
When a mobile application on the portable communication device 301 receives terminal transaction data 310, the mobile application increments its application transaction counter (ATC) and uses at least part of the received terminal transaction data 310. It can generate dynamic transaction processing information and send a set of transaction processing information 312, including the generated dynamic transaction processing information, to access device 360. In some embodiments, transaction processing information 312 can be sent in the form of a GPO response. In some embodiments, the transaction processing information 312 can be used as a file address (s) by the access device 360 to read account data stored on the portable communication device 301. · File locator (AFL) and application exchange profile (AIP) that can be used to demonstrate the capabilities of mobile applications. interchange profile) and may be included.
For integrated chip-based transactions, transaction processing information 312 includes LUK, Track-2 equivalent data, and issuer Application data (IAD), form factor indicator (FFI), Additional data such as card transaction qualifier (CTQ), cryptogram information data (CID), updated ATC, and / or application PAN sequence number (PSN) Can be used to include dynamically generated transactional statements. In some embodiments, the issuer application data (IAD) is a length indicator that indicates the length of the IAD, a ciphertext version (CVN) that indicates the version of the transaction ciphertext. number), derived key indicator (DKI) that can be used to identify the master key (for example, the master key associated with the issuer used when generating the LUK), card validation result (CVR: card) It may include derived data such as verification result), wallet provider ID, and / or key index used when generating the LUK.
The card validation result (CVR) can contain information about the CVM validation entity for the transaction and the CVM validation type. Use the CVM validation entity to indicate which entity is validating the CVM for the transaction. A validation entity can be an access device (or terminal), a secure application that resides with it, an application in a trusted execution environment, the mobile application itself, a remote server or computer (eg, the cloud), or a mobile operating system. It can be a system. The CVM validated type is used to indicate the CVM method used for the transaction. The CVM method may be passcode, biostatistics (eg for fingerprinting), pattern locking (eg for screen locking), signature, or online PIN. In some embodiments, if terminal transaction data 310 received from access device 360 indicates that the CVM supported by access device 360 is an online PIN or signature, then access the CVM validation entity in the CVR. It can be set on the device (or terminal) to indicate that the access device 360 is a validation entity, and the CVM-validated type can be set accordingly (eg, online PIN or signature).
If the terminal transaction data 310 received from the access device 360 indicates that the CVM supported by the access device 360 is a CDCVM, then the CVM validation entity and the CVM validation type can be set according to the account's configuration parameters. .. For example, if the account supports CVM with a passcode validated by the mobile operating system of portable communication device 301, the CVM validation entity can be set to the mobile operating system and the CVM validated type is CVM. Can be set to indicate that is a passcode. In some examples, did the card transaction qualifier (CTQ) include an indicator made by the CDCVM and did the CVM validation entity successfully validate the user using the CDCVM indicated by the CVM validated type? I can show you.
If the terminal transaction data 310 received from access device 360 indicates that CVM is not required, the CVM validation entity and CVM validated type can be configured to indicate that CVM was not validated. In some embodiments, the CVR may include additional data, such as a threshold indicator, indicating whether one or more limited use thresholds associated with the LUK have been exceeded.
The form factor indicator (FFI) is a form factor indicator version number that indicates the version of the form factor indicator used, and a consumer payment device form factor that indicates the device type of the portable communication device 301. It can include information about the portable communication device 301, such as an indicator and a consumer payment device feature indicator that indicates what payment features are supported by the portable communication device 301. The consumer payment device form factor is that the portable communication device 301 is a standard card (eg, ID-1 card type as specified in ISO7811), minicard, non-card form factor (eg, key fob). , Watches, wristbands, rings, stickers, etc.), or may indicate that it is a mobile phone. The consumer payment device feature indicator is that the portable communication device 301 has a passcode available (separable from the PIN used during the transaction), has a signature panel, has a hologram, and has a card verification value (eg,). , CVV2), can perform two-way messaging to exchange identifying information between the issuer and the user, and / or uses a cloud-based credit certificate (eg, LUK, token, etc.) Can indicate if there is support for doing so. The form factor indicator (FFI) can also include a payment transaction technology indicator indicating that the portable communication device 301 supports contactless transactions (eg, NFC).
In some embodiments, the transaction processing information 312 transmitted from the portable communication device 301 to the access device 360 may include some or all of the information described above, and in some embodiments, specific. It should be understood that it may contain additional information that is not specifically stated.
After the access device 360 receives the transaction processing information 312, the access device 360 may send an account data request 314 to the mobile application of the portable communication device 301 and store it on the portable communication device 301. Additional account data can be read. In some embodiments, the account data request 314 may be in the form of a read-record command, which is an application file locator (AFL) indicating the location of the account data that the access device 360 is trying to read. ) Can be included. The AFL included in the account data request 314 may correspond to the AFL in the transaction processing information 312 provided from the portable communication device 301 to the access device 360.
After the access device 360 receives the transaction processing information 312, the access device 360 may send an account data request 314 to the mobile application of the portable communication device 301 and store it on the portable communication device 301. Additional account data can be read. In some embodiments, the account data request 314 may be in the form of a read-record command, an application file locator indicating the address or location of the account data that the access device 360 is trying to read. (AFL) can be included. The AFL included in the account data request 314 may correspond to the AFL in the transaction processing information 312 provided by the portable communication device 301.
In response to receiving account data request 314 from access device 360, portable communication device 301 is capable of transmitting account data 316 stored at the location indicated by AFL to access device 360. In some embodiments, the account data 316 may be transmitted in the form of a read-record response. Account data 316 can be accessed, for example, in applications, cardholder names, customer-specific data, issuer country codes, token requester IDs (eg, if tokens are used), and / or AFL locations. It may contain other account-related data.
In some embodiments, the account data 316 transmitted from the portable communication device 301 to the access device 360 may include some or all of the information described above, and in some embodiments, specific. It should be understood that additional information not listed in may be included.
In some embodiments, for example, if additional account-related data to be stored is required by the access device 360 to complete the transaction, then two sets between the access device 360 and the portable communication device 301. There is a possibility that there is communication between the above account data 314 and account data 316. When the access device 360 receives the required data from transaction processing information 312 and / or transmission of one or more account data 316, some or all of the data elements in transaction processing information 312 and / or, The access device 360 can use the transmission of one or more account data 316s to generate a transaction permission request message and request the transaction permission from the issuer. For example, in some embodiments, the transaction permit request message can include at least track-2 equivalent data and a transaction ciphertext generated by the LUK, and the transaction is at least exactly generated by the transaction ciphertext. Transactions are performed based on verifying that the LUK used to generate the transaction ciphertext has not been exhausted to one or more limited usage threshold sets of the LUK. Can be allowed.
Magnetic Stripe-Based Transaction Figure 4 shows an example communication flow between a portable communication device 401 and an access device 460 during a magnetic stripe-based transaction, according to some examples. In some embodiments, the communication can be in the form of ADPU commands and responses. However, it should be understood that other messages, messaging protocols or formats can be used to exchange relevant information for conducting transactions. Communication can be performed between the mobile application running on the portable communication device 401 and the contactless reader of the access device 460. In some embodiments, the mobile application can communicate with the contactless reader using the mobile operating system card emulation API of the portable communication device 401 (although the secure element can be used). Transactions can be performed without the need to use secure elements.
For magnetic stripe-based transactions, the available application request 402, available application response 404, application selection 406, and terminal transaction data request 408 communication and related data elements included in the communication are shown in Figure 3. It is not necessary to repeat these detailed descriptions as they are similar to those for integrated chip card based transactions as described above with reference.
In response to receiving a terminal transaction data request 408 from the mobile application of the portable communication device 401, the access device 460 can send the requested terminal transaction data 410 to the portable communication device 401. The terminal transaction data 410 provided to the portable communication device 401 in a magnetic stripe based transaction is such that the transaction type indicator provided in the terminal transaction data 410 (eg, terminal transaction qualifier (TTQ)) It is similar to that of an integrated chip card based transaction as described above with reference to FIG. 3, except that the access device 360 can be shown to support magnetic stripe based transactions.
If the mobile application of portable communication device 401 receives terminal transaction data 410 and determines that access device 460 supports magnetic stripe-based transactions, the mobile application determines that application transaction counter (ATC). Can be increased to send a set of transaction processing information 412 to access device 360. In some embodiments, transaction processing information 412 can be sent in the form of a GPO response. In some embodiments, the transaction processing information 412 is one or more applications that can be used as a file address (s) by the access device 460 to read account data stored on the portable communication device 401. It may include a file locator (AFL) and an application exchange profile (AIP) that can be used to demonstrate the capabilities of mobile applications. In some embodiments, the one or more AFLs provided to the access device 460 during a magnetic stripe-based transaction may differ from the AFLs (s) provided during an integrated chip-based transaction. It is capable, which allows mobile applications to maintain various locations for storing separate sets of data for use in magnetic stripe-based transaction vs. integrated chip-based transactions. The mobile application also generates dynamic transaction processing information that may or may not use at least a portion of the received terminal transaction data 410, and one or more of the generated information. Can be stored in a location accessible by multiple application file locators (AFLs). The dynamic transaction processing information may include, for example, a transaction ciphertext generated by using LUK.
After the access device 460 receives the transaction processing information 412, the access device 460 may send an account data request 414 to the mobile application of the portable communication device 401 and store it on the portable communication device 301. Account data can be read. In some embodiments, the account data request 414 may be in the form of a read-record command, which is an application file locator (AFL) that indicates the location of the account data that the account device 460 is trying to read. ) Can be included. The AFL included in the account data request 414 may correspond to the AFL in the transaction processing information 412 provided from the portable communication device 401 to the access device 460.
In response to receiving account data request 414 from access device 460, portable communication device 401 is capable of transmitting account data 416 stored at the location indicated by AFL to access device 460. In some embodiments, account data 416 may be transmitted in the form of a read-record response. Account data 416 may include, for example, Track-2 equivalent data and cardholder name. In some embodiments, for magnetic stripe-based transactions, the transaction ciphertext generated by using the LUK and / or the key index associated with the LUK can be embedded in the Track-2 equivalent data.
In some embodiments, the account data 416 transmitted from the portable communication device 401 to the access device 460 may include some or all of the information described above, and in some embodiments, specific. It should be understood that additional information not listed in may be included.
In some embodiments, for example, if additional account-related data to be stored is required by the access device 460 to complete the transaction, then two sets between the access device 460 and the portable communication device 401. There may be communication exchanges between the above account data request 414 and account data 416. When the access device 460 receives the required data from the transaction processing information 412 and / or the transmission of one or more account data 416, some or all of the data elements in the transaction processing information 412 and / or, The access device 460 can use the transmission of one or more account data 416 to generate a transaction permission request message and request the transaction permission from the issuer. For example, in some embodiments, the transaction permit request message can include at least track-2 equivalent data and a transaction ciphertext generated by the LUK, and the transaction is at least exactly generated by the transaction ciphertext. Transactions are performed based on verifying that the LUK used when generating the transaction ciphertext has not been exhausted to one or more limited usage threshold sets of the LUK. Can be allowed.
Track-2 Equivalent Data According to some examples, depending on the type of transaction being performed (integrated chip-based transaction or magnetic stripe-based transaction), various data elements can be transferred to the mobile of a portable communication device. It can be included in the Track-2 equivalent data provided by the application to the access device. Table 1 shows examples of Track-2 equivalent data formats with embedded transaction ciphertext that can be used in either magnetic stripe-based transactions or integrated chip-based transactions.
<tables num="1"><img file="JP6551850B2_D0001.tif" /></tables>
The key index is associated with the LUK used when generating the transaction ciphertext for a particular transaction and can contain information about the LUK generation as described herein. For example, the key index may be the seed used to generate the LUK and may contain time information (eg a timestamp) indicating when the LUK was generated, and / or the LUK is a particular account. , A replenishment counter value indicating the number of renewals or replenishments for a mobile application, or portable communication device. In some embodiments, the key index may include an application transaction counter value indicating the number of transactions previously performed by the mobile application of the portable communication device at the time of LUK generation, or cloud-based. It may include pseudo-random numbers generated by a transaction service provider or by a suitable entity such as an issuer involved in processing the transaction.
The transaction ciphertext embedded in the Track-2 equivalent data may be the ciphertext generated by using LUK as the encryption key. In some embodiments, the transaction ciphertext embedded in the Track-2 equivalent data may differ from the transaction ciphertext provided in transaction processing information 312 (eg, GPO response). For example, ("<u style="single">Decimalization</u>Transaction ciphertexts embedded in Track-2 equivalent data (sometimes referred to as "transaction ciphertexts") may be shorter (eg, reduced to 6 digits) and / or It may be generated by encrypting static data (eg, a given string of numbers) instead of terminal transaction data.
In some embodiments where transactions are performed using an optical non-contact interface, an optical image such as a QR code or barcode is generated to encode the Track-2 equivalent data format shown in Table 1. An optical image encoding the Track-2 equivalent data can be displayed on a portable communication device and presented to the access device's optical scanner or reader for transactions.
Table 2 shows examples of Track-2 equivalent data formats without embedded transaction ciphertext that can be used in integrated chip-based transactions.
<tables num="2"><img file="JP6551850B2_D0002.tif" /></tables>
For integrated chip-based transactions, the transaction ciphertext has already been provided to the access device in transaction processing information 312 (eg, GPO response), so the transaction in track-2 equivalent data for the integrated chip-based transaction. It may not be necessary to include the ciphertext. Therefore, while the Track-2 equivalent data formats shown in Table 2 can be used for integrated chip-based transactions, the Track-2 equivalent data formats shown in Table 1 may also be used.
In some embodiments, the key index associated with the LUK can be embedded in the Track-2 discretionary data in the Track-2 equivalent data format shown in Table 2. The key index can include, for example, time information and / or replenishment counter values, application transaction counter values, pseudo-random numbers, or any of the examples described herein. In some embodiments, the key index can serve as a seed for generating transactional ciphertext. Tracks passed to the issuer-2 By including a seed in the discretionary data, the issuer can validate the seed, and in some embodiments, the seed is used to replay the transaction ciphertext to validate the transaction ciphertext. can do.
The Track-2 equivalent data format described above is an example, and in some embodiments the Track-2 equivalent data may omit some of the data elements and / or additions not specifically shown. Please understand that it may contain data elements of.
V. Transaction Validation Log According to some examples, a mobile application can update the transaction validation log at the end of a transaction to include information about the transaction in the transaction validation log maintained by the mobile application. The mobile application recognizes that all transaction processing information and / or account data that may be required by the access device to complete the transaction is provided to the access device (eg, GPO). When the response is successfully returned, the end of the transaction can be recognized by recognizing whether the final record defined in the AFL was successfully returned or there is no AFL).
Figure 5 shows an example of the data elements that can be included in the transaction validation log, according to some examples. Mobile applications can maintain transaction validation logs per LUK or per set of account parameters. In some embodiments, the portable communication device can maintain a large number of transaction validation logs for some LUK or set of account parameters, or optionally the current LUK or account parameters. When new or replenished, transaction validation logs corresponding to previous LUK or account parameters can be deleted to save memory space on portable communication devices.
The transaction validation log is a key index that corresponds to the set of LUK or account parameters used in the logged transaction and the number of times the set of LUK or account parameters has been replenished. It can and / or can include the sequence counter values associated with the set of parameters. For each transaction performed using a particular LUK or a particular set of account parameters, the transaction validation log is a transaction timestamp indicating the time of the corresponding transaction, accessed during the transaction (if possible). Unpredictable number provided by the device (UN: unpredictable) number), the application transaction counter (ATC) value associated with the corresponding transaction (for example, the number of transactions made using the mobile application at the time of the transaction), and the corresponding transaction is aggregate chip-based. It can include a transaction type indicator that indicates whether it was done as a transaction or a magnetic stripe based transaction. The transaction timestamp may be the UTC time as determined by the portable communication device at the time of the transaction. In some embodiments, the transaction validation log can include additional information such as the location of the portable communication device at the time of the corresponding transaction. It should be appreciated that in some embodiments, the transaction validation log can contain fewer data elements and / or other data elements not specifically indicated.
Transaction verification logs can be used for a variety of purposes, such as postpaid payment validation and account parameter replenishment. FIG. 6 shows a communication flow diagram of an example of the deferred payment verification process according to some examples. The postpaid payment verification process is when the issuer / host system 672 decides to check the account, for example, when a transaction is received that is flagged as suspicious or potentially fraudulent, or the issuer. When the / host system 672 checks the account randomly or periodically as a fraud prevention measure, it can be initiated by the issuer / host system 672.
The issuer / host system 672 can initiate the deferred payment verification process by sending a transaction log request 622 to the CBPP680 to request the transaction verification log associated with the account. Transaction log request 622 can include information such as an account identifier that can be used by CBPP680 to identify the account. The CBPP680 can identify the account and the mobile application in which the account is registered and send this information as transaction log request 624 to the MAP670. The MAP670 can identify and authenticate the portable communication device associated with the account and mobile application and send a transaction log request 626 to the identified mobile application of the portable communication device 601.
Upon receiving the transaction log request 626, the mobile application on the portable communication device 601 retrieves the transaction verification log from the memory of the portable communication device and sends the data to the issuer / host system 672 in the transaction log. Can be packaged in information 628. Transaction log information 628 is derived from the transaction validation log stored on the portable communication device and includes transaction time stamps, application transaction counter values, transaction type indicators, unpredictable numbers if possible, And / or transaction validation logs such as transactional details for each transaction, such as any combination thereof, key index associated with the LUK or account parameter used for the transaction, LUK or account parameter. It may include an associated sequence counter and / or some or all of the information contained in any combination thereof. Alternatively or additionally, the transaction log information derived from the transaction verification log may include an authentication code (eg, message authentication code, hash value, etc.) calculated over some or all of the information in the transaction verification log. For example, the authorization code can be calculated over transaction-by-transaction details, or along with transaction-by-transaction details across key indexes and / or sequence counters. In some embodiments, the authorization code can be generated by using LUK as the encryption key.
After deriving the relevant transaction log information 628 from the transaction validation log, the mobile application on the portable communication device 601 sends the transaction log information 628 to the MAP670. The MAP670 sends information as transaction log information 630 to the CBPP680, and the CBPP680 sends information as transaction log information 632 to the issuer / host system 672. In some embodiments, the CBPP680 can validate the transaction log information received, for example, if the CBPP680 tracks transaction activity for an account, and / or instead, issuer / host system 672. It is possible to provide the verification result in the transaction log information 632 transmitted to.
When the issuer / host system 672 receives transaction log information 632, the issuer / host system 672 compares that information to a suspicious transaction and / or compares that information to the current LUK or account. Can be compared against transaction activity for a set of parameters. If transaction log information 632 indicates that a suspicious transaction was performed by a mobile application on portable communication device 601 and / or transaction log information 632 matches transaction activity, issuer / host. System 672 completes the postpaid payment verification process and maintains the account in activity status.
If transaction log information 632 indicates that a suspicious transaction did not arise from the mobile application on portable communication device 601 or if transaction log information 632 does not match transaction activity in the issuer, the issuer / host. System 672 may suspend the account and send a suspension notice to the CBPP680. CBPP680 may suspend the account in its system and send a suspension notice to MAP670. The MAP670 then sends a stop notification to the mobile application on the portable communication device 601. In response to receiving the outage notification, the mobile application may remove the current set of account parameters from the mobile application and display a message requesting the user to contact the issuer.
VI. Account Parameter Replenishment By using account parameters whose set of account parameters (eg LUK) has been exhausted to the life of the account parameter or the associated set of one or more limited usage thresholds. When it expires, subsequent transactions made using the set of expired account parameters may be rejected. To enable mobile applications on portable communication devices to continue to carry out transactions, mobile applications update, refresh, and refresh the set of account parameters available to mobile applications. Or may need to be replenished. In some embodiments, the transaction validation log is also used during the account parameter replenishment process to request a new account parameter for a mobile application or portable communication device that was previously received and previously received. It can be verified that it is the same application or device using a set of parameters.
To facilitate the account parameter replenishment process, the mobile application of the portable communication device tracks the utilization of a set of account parameters (eg, LUK) and is associated with the account parameter or LUK or one or more. It is possible to maintain an account parameter status that indicates whether it has been or is about to be exhausted up to multiple limited usage thresholds. For example, a mobile application may have how many transactions were performed using a set of account parameters or LUKs, how long it has been since the set or LUKs of account parameters were generated, and / or. You can track the cumulative transaction volume across all transactions performed using a set of account parameters or LUK. At the end of each transaction, the mobile application updates the set of account parameters or LUK usage tracked by the mobile application for one or more limited usage thresholds on-device. You can compare their usage. In some embodiments, the current set of account parameters or LUK usage has been exhausted to one or more limited usage threshold sets on the device, or used beyond the usage limit. If the mobile application determines that it has been, the mobile application may initiate an account parameter replenishment request. In some embodiments, the mobile application determines that the next transaction performed using the current account parameter set or LUK will be exhausted to one or more limited usage threshold sets. If so, the mobile application may initiate an account parameter replenishment request. This, for example, a set of valid account parameters or LUK is always available for mobile applications.
FIG. 7 shows a communication flow diagram of an example of the account parameter replenishment process according to some examples. In the example shown in Figure 7, the account parameter replenishment process is initiated by the mobile application on the portable communication device 701 and is sometimes referred to as the replenishment pull process. Portable communication device 701 when the mobile application determines that the set of limited usage thresholds associated with the current set of account parameters has been or is about to be exhausted. The mobile application can send an account parameter replenishment request 722 to the MAP770 to replenish the set or LUK of account parameters available to the mobile application.
The account parameter replenishment request 722 can include information identifying the associated account, mobile application, and / or portable communication device 701, and is a transaction log derived from the transaction validation log stored on the portable communication device. Information can be included. The transaction log information provided in account parameter replenishment request 722 is the transactional details for each transaction made using the current set of account parameters or LUK (eg, transaction time stamps, application. It may include some or all of the information contained in the transaction validation log, such as transaction counter values, transaction type indicators, unpredictable numbers if possible, and / or any combination thereof. Transaction log information may include a key index associated with the current account parameter set or LUK and / or a sequence counter associated with the current account parameter set or LUK. Alternatively or further, the transaction log information derived from the transaction validation log and provided in account parameter replenishment request 722 is an authentication code calculated over some or all of the information in the transaction validation log (eg, for example. Message authentication code, hash value, etc.) may be included. For example, the authorization code can be calculated over transaction-by-transaction details, or along with transaction-by-transaction details across key indexes and / or sequence counters. In some embodiments, the authorization code can be generated by using LUK as the encryption key.
When the MAP770 receives the account parameter replenishment request 722, the MAP770 sends a request as the account parameter replenishment request 724 to the CBPP780. Upon receiving the account parameter replenishment request 724, the CBPP780 can either verify the transaction log information or request the issuer / host system 772 to verify the transaction log information. If the transaction log information matches transaction activity on the CBPP780 or issuer / host system 772, the CBPP780 then generates a new set of account parameters (eg, a new key index and a new LUK). , Can supplement the current set of account parameters in mobile applications. The CBPP780 can send a replenishment notification 726 to the issuer / host system 772 to notify the mobile application that a new set of account parameters has been replenished. In some embodiments, the replenishment notification 726 provides a new set of account parameters (eg, a new key index and a new LUK) to allow the issuer / host system 772 to make its own updates. May include. Issuer / host system 772 can respond by sending acknowledgment 728 to CBPP780.
After the new set of account parameters is generated, the CBPP780 may send the new set of account parameters 730 to the MAP770. The new account parameter set 730 may include a new key index, a new LUK, etc., and in some embodiments, the account parameter or LUK may have different usage limits than the previous threshold. It can also include a set of new one or more limited usage thresholds associated with it. The MAP770 then sends the data as a new set of account parameters 732 to the mobile application on the portable communication device 701.
When the mobile application on the portable communication device 701 receives a new set of account parameters (eg, a new LUK and a new key index associated with that LUK), the mobile application uses the old account parameters. Deletes the set and associated transaction validation log details, as well as usage tracking, and stores a new set of account parameters. If the new set of account parameters has different usage limits for one or more sets of limited usage thresholds, then one or more limited usage thresholds can be updated with the new usage limits. The mobile application also increases the sequence counter for each successful account parameter replenishment. When the mobile application updates the set of account parameters, the mobile application on the portable communication device 701 can send confirmation 734 to MAP780, which sends this as confirmation 736 to CBPP770 to replenish the account parameters. You can confirm that the process was successful.
In some embodiments, if issuer / host system 772 is responsible for account parameter generation, instead of sending replenishment notification 726 to issuer / host system 772, CBPP780 issues account parameter replenishment request 724. It can be sent to the issuer / host system 772 to have the issuer / host system 772 generate a new set of account parameters (eg, a new key index and a new LUK). In such an embodiment, the issuer / host system 772 can provide a new set of account parameters to the CBPP780 and / or MAP770 to be sent to a mobile application on the portable communication device 701.
According to some embodiments, the account parameter replenishment process can be initiated by the CBPP770 and / or the issuer / host system 772. The account parameter replenishment process that is not initiated by the mobile application is sometimes referred to as the replenishment push process. For example, the account parameter replenishment process can be triggered by transaction activity monitored by CBPP770 and / or issuer / host system 772. In some embodiments, the CBPP770 and / or issuer / host system 772 can maintain its own set of one or more limited usage thresholds, which are maintained in the mobile application. It may or may not have the same usage limit as the on-device limited usage threshold. The CBPP770 and / or issuer / host system 772 may track the use of the current set of account parameters (eg LUK) .
When the CBPP770 determines that one or more sets of limited usage thresholds in the CBPP770 associated with the current set of account parameters have been or are about to be exhausted, the CBPP770 pushes. You can send a message to the MAP780 to request the mobile application to replenish its current set of account parameters. Issuer / Host System 772 determines that one or more sets of limited usage thresholds associated with the current set of account parameters have been or are about to be exhausted. At times, the issuer / host system 772 may send a push message to the CBPP770 and / or MAP780 requesting the mobile application to replenish its current set of account parameters.
Upon receiving a push message from the CBPP770 or the issuer / host system 772 to replenish the set of account parameters, the MAP780 can send the push message to the mobile application on the portable communication device 701. In some scenarios, the portable communication device 701 may be powered off or the mobile application is not on the portable communication device 701 when the CBPP770 and / or the issuer / host system 772 begins the replenishment process. May be activated. In such a scenario, the MAP780 can be queued for delivery of push messages to the mobile application after some time, periodically to the mobile application until the MAP780 establishes communication with the mobile application. You can try to reach it. When the mobile application receives a push message requesting the mobile application of the portable communication device 701 to replenish the account parameters (eg, LUK and associated key index), the portable communication device responds accordingly. The 701 mobile application may send an account parameter replenishment request with relevant transaction log information to the MAP 780. The replenishment process may continue in a manner similar to the replenishment push process described above with reference to FIG. In some embodiments, the CBPP770 and / or the issuer / host system 772 can generate a new set of account parameters and provide them with a push message to the MAP780, which makes the MAP780 mobile. Allows the mobile application to be provided with a new set of account parameters when communication with the application is established.
The above description of the account parameter replenishment process can be a description of the LUK and the replenishment of the key index associated with the LUK, but others, such as replenishing tokens used on behalf of the account identifier. It should be understood that the account parameter replenishment process can be used to replenish the account parameters or related information of. In some embodiments, tokens can be replenished at the same time as the LUK and key index, or separately from the LUK and key index.
VII. Transaction Ciphertext To perform cloud-based transactions, as some examples do not require a secure element that should exist to protect the account credit certificate stored on the portable communication device. Account parameters may have a limited lifetime, which allows the stolen account parameters to expire or soon expire even if a given set of account parameters is threatened. Therefore, it will be rarely used. Instead of using the static key stored in the secure element to generate the ciphertext during the transaction, for example in some secure element implementations, the cloud-based transaction system generates the transaction ciphertext. Sometimes use limited use keys.
In some embodiments, the two types of transactional ciphertext may be used track-2 data used in a magnetic stripe-based transaction and used in an integrated chip-based transaction. .. For both types of transactional ciphertext, the transactional ciphertext is generated using the Limited Use Key (LUK). The difference between the two types of transactional ciphertext is the input data used to generate the ciphertext, which is transmitted to the access device to perform the transaction, and / or the final format of the transactional ciphertext. For integrated chip-based transactions, the input data used to generate the cipher is the dynamic data (eg, terminal transaction data) received from the contactless reader of the access device during the transaction (eg, terminal transaction data). , Data that changes for each transaction), and the input data for a magnetic stripe-based transaction does not change from static data (for example, a given number string, from one transaction to another) Data). This means that, in some embodiments, for magnetic stripe-based transactions, either the CBPP or the mobile application itself does not rely on data from the contactless reading of the access device to generate the transaction ciphertext. Therefore, transaction ciphertext can be generated, and for integrated chip-based transactions, mobile applications can generate transaction ciphertext.
Also, in some embodiments, the input for generating the transaction ciphertext in a magnetic stripe-based transaction is alternative or, additionally, dynamic received from the contactless reader of the access device during the transaction. Note that data (eg terminal transaction data) can be included. Also, in an integrated chip-based transaction, the input for generating the transaction ciphertext can optionally or further include static data.
In addition to being used during transactional ciphertext generation, some examples use LUK to provide an authorization code when a mobile application communicates with other components or entities in a cloud-based transaction system. Can be generated. For example, an authorization code or hash code can be generated over transaction validation log details using LUK as a key during the account parameter replenishment process.
FIG. 8 shows a block diagram of an example of Process 800 for generating a transactional ciphertext, according to some examples. Any one of the cryptographic functions 806, 812, 818 and / or 824 may be the same as or different from any of the other cryptographic functions. For example, any one of the cryptographic functions 806, 812, 818 and / or 824 is a Triple Data Encryption Standard (TDES), Data Encryption Standard (DES), Advanced Encryption Standard (AES), or , May be implemented as other suitable encryption algorithms.
Process 800 can be divided into two parts. In the second part, the first part is related to LUK generation (blocks 802 to 814), and the second part is related to transaction ciphertext generation (blocks 816 to 828). The first part related to LUK generation can be done once to generate a LUK (eg by CBPP or issuer / host system), and the second part related to transaction ciphertext generation is part 1 of LUK. It can be done multiple times using the LUK generated from Part 1 (eg, by a mobile application) until one or more sets of limited usage thresholds are exceeded, at which time the third related to LUK generation. One copy can be done again to replenish, renew, or refresh the LUK.
Process 800 can be started by encrypting the account information 804 with the first encryption key 802 using the encryption function 806 to generate the second encryption key 808. The first encryption key 802 may be the base key associated with the issuer of the user's account, and the base key may be associated with a group of accounts. For example, the first encryption key 802 may be associated with a group of accounts within the BIN or PAN range specified for the cloud-based transaction service. In some embodiments, the first encryption key 802 may be the master derived key (MDK) associated with the issuer of the account associated with account information 804, and the first encryption key 802 is Can be maintained in CBPP or issuer / host system.
Account information 804 can include account identification information such as an account identifier (eg, PAN), an alternate account identifier (eg, alternate PAN), or a token on behalf of the account identifier, and further (eg, multiple users have the same account). Can include user identification information such as a sequence number (eg, PAN sequence number (PSN)) that identifies a particular user for that account. For example, the account information 804 used as an input to the encryption function 806 can be a concatenation of the account identification information and the user identification information, or an inverted version of the concatenation.
In some embodiments, the second encryption key 808 generated from account information 804 may each include a plurality of parts generated from various variants of account information 804. For example, the second encryption key 808 can be split into two parts. The first part of the second encryption key 808 can be generated by encrypting the account information 804 using the first encryption key 802. The second part of the second encryption key 808 can be generated by inverting the account information 804 and encrypting the inverted account information using the first encryption key 802. The encryption function 806 used to generate the second encryption key 808 may be, for example, the Triple Data Encryption Standard (TDES) or other suitable encryption algorithm, the first of binary zeros. You can use the chaining vector of. In some embodiments, the second encryption key 808 generated from the account information 804 may correspond to a unique derivation key (UDK) for the account.
Process 800 may continue by encrypting key index information 810 with a second encryption key 808 using encryption function 812 to generate Limited Use Key (LUK) 814. The key index information 810 can be derived from a key index that contains information about the generation of LUK814 and can be used as a seed to generate LUK814. For example, the key index may contain time information indicating when LUK814 was generated. In some embodiments, the time information can be represented as a sequence of numbers "YHHHH". In this case, "Y" (0-9) represents the last digit of the current year, and "HHHH" (0001-8784) is the time from the beginning of January 1st of the current year represented by the digit. Represents a number (for example, the first hour of January 1st = 0001). In some embodiments, the key index includes a replenishment counter value indicating the number of times LUK814 is renewed or replenished in a given time cycle (eg, the number of times LUK814 is generated every hour). You can also. For example, the replenishment counter value can be represented as a number string "CC" (00 to 99). At the beginning of each time, "CC" starts at 00 and is incremented by 1 for each LUK814 generated. In some embodiments, the key index may include an application transaction counter value or a pseudo-random number generated by a CBPP or issuer.
According to some embodiments, the key index information 810 provided as input to the encryption function 812 can be generated by padding the key index with one or more numbers. For example, the key index can be the first number of the key index (eg, 1 or 2 shown as "m" or "n" in Figure 8) and / or the last number of the key index (eg, figure). It can be padded with 80000000), which is shown as "xxxxxxxx" in 8. In some embodiments, the LUK 814 generated from the key index information 810 may each include a plurality of parts generated from various variants of the key index information 810. For example, LUK814 can be split into two parts. The first part of LUK814 padded the key index with the first value to generate the first padded key index (eg 1YHHHHCC80000000) and used the second encryption key 808. Can be generated by encrypting the first padded key index. The second part of LUK814 padds the key index with a second value to generate a second padded key index (eg 2YHHHHCC80000000) and uses the second encryption key 808. Can be generated by encrypting the second padded key index. The cryptographic function 812 used to generate LUK814 may be, for example, TDES or other suitable cryptographic algorithm, and the first chaining vector of binary zero can be used. It should be understood that the numbers given herein are merely examples and that other numbers may be used in some embodiments.
After LUK814 is generated (eg by CBPP or issuer), LUK814, and a key index containing information about LUK814 generation, facilitates the generation of transaction ciphertext for transactions performed using portable communication devices. May be provided to portable communication devices. The LUK can be associated with one or more sets of limited usage thresholds that limit the number of transactions that can be performed using LUK814, as described herein. During the execution of the transaction, the transaction ciphertext and / or key index can be provided from the portable communication device to the access device, and the transaction is used to validate the transaction ciphertext and generate the transaction ciphertext LUK814. May be allowed based on whether has exceeded the limited use threshold of one or more LUKs.
As discussed above, in some embodiments it is possible to generate two types of transactional ciphertext. For magnetic stripe-based transactions, the transaction ciphertext 828 is (<u style="single">Decimalization</u>It may be a reduced-length transactional ciphertext (sometimes referred to as a transactional ciphertext). The transaction ciphertext 828 is generated by encrypting the static data 822 using LUK814 as the encryption key in the encryption function 824 (for example, it can be a predetermined number string such as "0000000000000001"). , Encrypted static data represented by hexadecimal numbers (0 to F) or encrypted numbers can be formed. Cryptographic function 824 may be, for example, TDES or other suitable cryptographic algorithm, and can use the first chaining vector of binary zero. Encrypted static data (or an encrypted sequence of digits) is then used to generate transaction ciphertext 828.<u style="single">Decimalization</u>By using function 826<u style="single">Decimalization</u>it can.
In some embodiments, the transaction ciphertext 828 may be split into two data blocks. Used to generate two data blocks for transaction ciphertext 828<u style="single">Decimalization</u>Function 826 extracts numbers (0-9) from encrypted static data or an encrypted sequence of numbers to form a first data block, and for the second data block, Extracting hexadecimal characters (A to F) from encrypted static data or an encrypted sequence of digits and forming a second block of digits from the corresponding hexadecimal characters 10 Can include converting each extracted hexadecimal character to a number by subtracting. The first data block is then concatenated with the second data block to form the transaction ciphertext 828. In some examples,<u style="single">Decimalization</u>The transaction ciphertext 828 can have 6 digits and is embedded in the key index (eg "YHHHHCC") in the track-2 equivalent data provided in the transaction permission request message to allow the issuer to make a transaction. Can be requested.
For integrated chip-based transactions, transaction ciphertext 820 may be generated by encrypting dynamic transaction data 816 using LUK 814 as the encryption key in encryption function 818. The dynamic transaction data 816 may include, for example, some or all of the terminal transaction data 310 provided from the access device to the mobile application of the portable communication device during the execution of the transaction. In some embodiments, the dynamic transaction data 816 contains the following data elements: allowed amount, other amount, terminal country code, terminal validation result, transaction currency code, transaction date, transaction type, and forecast. It can contain impossible numbers and / or can include application exchange profiles (AIPs), application transaction counters (ATCs), and issuer application data (IADs). In some embodiments, some data elements may be omitted and / or may include additional data elements not specifically described. The data set that makes up the dynamic transaction data 816 is provided as input to the encryption function 818. In some embodiments, the transaction ciphertext 820 uses the first part of LUK814 to encrypt the dynamic transaction data 816 and the second part of LUK814 to encrypt the dynamic transaction. It can be generated by decrypting the data and then re-encrypting the decrypted dynamic transaction data using the first part of LUK814.
According to some examples, in addition to transaction ciphertext 820,<u style="single">Decimalization</u>The transaction ciphertext 828 that was created can also be used and generated in an integrated chip-based transaction.<u style="single">Decimalization</u>Note that the transaction ciphertext 828 that has been made can be inserted into Track-2 equivalent data.
FIG. 9 shows a block diagram of an example of the encryption function 900 according to some examples. In some embodiments, the encryption function 900 can be used as the encryption function 818. For example, the data sets that make up dynamic transaction data 816 are concatenated together (eg, in the order described above), and then data blocks of equal length D.<sub>1</sub>~ D<sub>N</sub>May be divided into sets of (eg, 8-byte data blocks). If the dynamic transaction data 816 is not equally divided into data block lengths, then the last data block D<sub>N</sub>The least significant digit missing in can be filled with zeros. The first key KA may correspond to the first part of LUK814 (eg the most significant 8 bytes) and the second key KB may correspond to the second part of LUK814 (eg the least significant 8 bytes). .. The iterative cryptographic conversion process involves data block D<sub>1</sub>~ D<sub>N</sub>May be applied to the set of. The iterative encryption conversion process uses the key KA as the encryption key in the data encryption algorithm (DEA (e)) in the first data block D.<sub>1</sub>Can include encrypting. The result of the encryption is then the next data block D<sub>2</sub>Exclusive OR is taken by. The result of the exclusive OR operation is then used as input for the next iteration of the encryption process. All data blocks D<sub>1</sub>~ D<sub>N</sub>The cryptographic conversion process continues until is processed, and the final data block D<sub>N</sub>Output of the last exclusive OR operation by I<sub>N</sub>Is encrypted and the output of the iterative encryption conversion process O<sub>N</sub>To form. Output of iterative cryptographic conversion process O<sub>N</sub>Can then be decrypted using the key KB as the decryption key in the data decoding algorithm (DEA (d)). Decoding process output O<sub>N + 1</sub>Is then re-encrypted using key KA as the encryption key in the data encryption algorithm (DEA (e)) and output O<sub>N + 2</sub>To generate. According to some examples, output O<sub>N + 2</sub>Can be used as transaction ciphertext 820.
In some embodiments, the encryption function 900 described with reference to FIG. 9 is used, for example, by applying the encryption function 900 over at least the transaction verification log stored on the portable communication device. Note that you can generate an authorization code that will be used in the postpaid payment verification process and / or the account parameter replenishment process. In some embodiments, the encryption function 900 described with reference to FIG. 9 can also be used for any of the encryption functions 806, 812, 818, and / or 824.
VIII. Method Examples Figure 10 shows a flow diagram of an example of Method 1000 for improving the security of a communication device (eg, a portable communication device) when performing a transaction using the communication device, according to some embodiments. Shown. Process 1000 can be performed, for example, by a mobile application running on a portable communication device and can be performed without the secure element (although the secure element can be used in some examples). ..
At block 1002, the communication device can receive a Limited Use Key (LUK) associated with one or more sets of Limited Use Thresholds that limit the use of the LUK. The LUK can be received from a remote computer (eg, a MAP, CBPP, or a remote computer associated with the issuer / host system). In some embodiments, a set of one or more limited usage thresholds has a validity period indicating the amount of time that the LUK is valid, a predetermined number of transactions in which the LUK is valid, and / or the LUK is valid. It can contain at least one of the cumulative transaction volumes that indicates a total transaction volume. In some embodiments, the set of one or more limited use thresholds can include an international use threshold and a domestic use threshold.
According to some embodiments, the communication device can also receive a key index, which contains information about the generation of the LUK, by the LUK. For example, the key index is generated with time information indicating when the LUK is generated, a replenishment counter value indicating the number of times the LUK was replenished, a pseudo-random number used as a seed to generate the LUK, and a LUK. It can include a transaction counter value indicating the number of transactions previously performed by the mobile application of the communication device at the time and / or any combination thereof.
Block 1004 allows a transaction (eg, a settlement transaction, an access transaction, or any other transaction performed using an account) to be placed in close proximity to a contactless reader of an access device, such as a point-of-sale terminal. Can be started by putting. In block 1006, the communication device can use LUK to generate transaction ciphertext. In block 1008, the communication device may send a transaction ciphertext to the access device to perform a transaction. In some embodiments, the communication device can also send a token (eg, on behalf of the account identifier) to the access device in place of the real account identifier to perform a transaction. In some embodiments, process 1000 stores a token or LUK in the communication device without using a secure element. Transactions can be allowed, at a minimum, based on whether the use of LUK has exceeded one or more sets of limited use thresholds and / or verification of the transaction ciphertext.
In block 1010, after performing a transaction, process 1000 has been exhausted (or exhausted) up to or exceeded (or has been exhausted) a set of one or more limited usage thresholds associated with the LUK. You can judge whether it is or is about to exceed it. Not exhausted to one or more sets of limited use thresholds associated with the LUK, or not exceeding (or likely to be exhausted or not likely to exceed) the set of thresholds. If determined, process 1000 can proceed to block 1004 to perform another transaction.
It is determined that the set of one or more limited usage thresholds associated with the LUK has been exhausted or has exceeded (or is likely to be exhausted or is not likely to exceed) the set of thresholds. If so, the communication device may send a replenishment request for the new LUK to the remote computer at block 1012. A replenishment request responds to the determination that one or more limited usage threshold sets associated with the LUK have been exhausted, or one or more in the next transaction made by the LUK. May be transmitted in response to determining that up to a set of limited usage thresholds will be exhausted. In some embodiments, the replenishment request may be sent in response to receiving a push message requesting the communication device to replenish the LUK.
The replenishment request can include transaction log information derived from a transaction log stored on the communication device (eg, a transaction verification log). In some embodiments, the transaction log stored on the communication device is, for each transaction performed using LUK, a transaction time stamp indicating the time of the corresponding transaction, the application associated with the corresponding transaction. It can include a transaction counter value and / or a transaction type indicator that indicates whether the corresponding transaction is a magnetic stripe-based transaction or an integrated chip-based transaction. In some embodiments, the transaction log information sent to the remote server or computer may include an authorization code calculated using the LUK at least over the transaction log. If the transaction log information in the replenishment request matches the transaction log information on the remote computer, process 1000 may proceed to block 1002 and the communication device has a new LUK and a new key associated with the new LUK. You may receive the index.
FIG. 11 shows a flow diagram of an example of Method 1100 for improving the security of a communication device when a transaction is performed using the communication device, according to some embodiments. Process 1100 can be performed, for example, by a computer associated with CBPP or issuer.
In block 1102, the account information associated with the account is encrypted using the first encryption key to generate a second encryption key. In some embodiments, the account information may include an alternative account identifier, such as a PAN, an alternative PAN, or a token on behalf of the account identifier. In some embodiments, the first encryption key may be the master derived key associated with the issuer of the account. According to some embodiments, encrypting the account information to generate a second encryption key uses the first encryption key to encrypt the account information and the second encryption key. Generate the first part, flip the account information, and use the first encryption key to encrypt the flipped account information to generate the second part of the second encryption key. It may include things. In some embodiments, the second encryption key may be a unique derived key for the account.
In block 1104, the key index information is encrypted using a second encryption key to generate a Limited Use Key (LUK). The key index information may include a key index that contains information about the generation of the LUK. For example, the key index information may include a counter value indicating the number of times the LUK is renewed or replenished in a predetermined time cycle, and / or time information indicating when the LUK is generated. In some embodiments, encrypting the key index information to generate the LUK means padding the key index with the first value to generate the first padded key index information. , May include encrypting the first padded key index information to generate the first part of the LUK. Encrypting the key index information to generate the LUK also padding the key index with a second value to generate the second padded key index information and the second padded key. It may include encrypting the index information to generate a second part of the LUK.
In block 1106, process 1100 associates the LUK with one or more sets of limited usage thresholds that limit the use of the LUK. In block 1108, the LUK and key index are provided to the communication device (eg, a portable communication device) to facilitate the generation of transaction ciphertext for transactions performed using the communication device. Transactions may be allowed on the basis of LUK and transaction ciphertext (eg, whether the use of LUK exceeds a set of one or more limited use thresholds and / or validation of the transaction ciphertext).
In some embodiments, when the transaction is an integrated chip-based transaction, the transaction cipher uses the first part of the LUK to provide transaction information (eg, a terminal received from an access device during the transaction). (Dynamic transaction information such as transaction data) is encrypted, the second part of the LUK is used to decrypt the converted transaction information, and the first part of the LUK is used to decrypt the transaction information. Can be generated by re-encryption.
When the transaction is a magnetic stripe-based transaction, the transaction ciphertext uses LUK to encrypt a given string of digits and then encrypts the given string of digits.<u style="single">Decimalization</u>Can be generated by In some examples, a given encrypted sequence of digits<u style="single">Decimalization</u>What you do is extract numbers from a given encrypted string to form the first data block, and extract hexadecimal characters from a given encrypted string to make a second. To form a data block of, convert each extracted hexadecimal character to a number and concatenate the first and second data blocks to form a transaction cipher. Can include things. The transaction ciphertext and / or key index can be embedded in the track-2 equivalent data of the authorization request message.
IX. Cloud-Based Payment Platform (CBPP) This section provides further details on some of the functionality that can be achieved with a Cloud-Based Payment Platform (CBPP) (eg, CBPP180). In some embodiments, these functionality includes key management, active account management and account parameter replenishment, payment and payment transaction processing, payment validation, provisioning, lifecycle management, and postpaid payment validation. It's fine. Communication between CBPP and Mobile Application Platform (MAP) is a transport level security (TLS) protocol, a secure socket layer (SSL) protocol, Alternatively, hypertext transfer protocol (HTTPS) secure) · Can be established using a secure channel, such as one that conforms to the protocol. Communication between the CBPP and the issuer / host system can be established using secure channels that comply with issuer security requirements.
The issuer of the key management account is a secure element using a dedicated set of keys (eg MDK) according to the bank identification number (BIN) range for cloud-based payment transactions or according to the primary account number (PAN) range. You may want to avoid situations where the same key is used for both base and cloud based transactions. The MDK can be used as a base key to generate the LUK provided for portable communication devices. In some embodiments, the CBPP can provide its own set of issuer MDK keys (specific to cloud-based environments) stored in its own hardware security module. In some examples, instead of using MDK's own set to generate the LUK, the CBPP calls the issuer / host system and stores it in the issuer / host system's hardware security module. You can search for LUK.
Active Account Management and Account Parameter Replenishment The cloud-based payment techniques described herein do not require the use of secure elements to securely store data such as unique derived keys (UDKs). As such, portable communication devices do not have access to all the capabilities associated with secure elements, such as the ability to generate application cryptograms (ACs) for transactions that use only securely stored information. In some cases. To mitigate the risk of account parameters being compromised, to periodically generate limited-use account parameters by CBPP to replenish mobile applications on portable communications devices, as well as to keep accounts active. Can be refreshed in the issuer / host system.
For the active account management process to be initiated, the CBPP may receive requests for account parameter generation from the MAP or issuer / host system. For example, MAP requests a new set of account parameters, such as limited-use keys, and an associated key index from the CBPP in response to requests from mobile applications for account parameter data updates. You can. As another example, the issuer / host system is used during transaction processing within its limited usage threshold, such as the current set of account parameters is still valid (eg, the number of transactions allowed, the validity period, etc.). Can be checked. If a given risk setting threshold is exceeded, the issuer / host system may warn the CBPP that a new set of account parameters should be updated in the mobile application.
In response to the request, CBPP may generate a set of account-related data. Account-related data is mobile to generate semi-static account information and transaction ciphertext (eg, application ciphertext (AC)) when the portable communication device is presented to the contactless reader of the access device. It may contain dynamic account parameters that change with each replenishment, such as LUK, which may be used by the application. Account parameters include account traits (eg, different account parameters for different user accounts), portable communication device traits (eg, different underlying accounts, even when the underlying account is the same, different user portable communication devices. (Various account parameters for) and / or mobile application characteristics (eg, different account parameters for different mobile applications, even when different mobile applications are in the same portable communication device). Parameter).
The set of account-related data is also limited in risk management parameters that will indicate to the issuer / host system how transaction data should be used (eg, the number of consecutive transactions allowed and the lifetime). Usage threshold) may be included. Risk parameters are performed by account traits (eg, all cloud-based transactions performed by an account are unified for risk parameter evaluation), portable communication device traits (eg, by a particular portable communication device). All cloud-based transactions are unified for risk parameter assessment), mobile application characteristics (eg, all cloud-based transactions made through a particular mobile application are risk parameter (Unified for evaluation) and / or account parameter attributes (eg, each set of account parameters has its own set of risk parameters).
In some embodiments, the issuer / host system provides a unified view of all transactions performed on the account because the same account can be provisioned in various mobile applications that may have their own risk limits. You may implement your own set of risk limits or limited usage thresholds that apply to each account to have, while all transactions performed by various mobile applications using that account are the same issuer / Allowed by the host system. Risk management parameters can be predetermined in both mobile applications and issuer / host systems, or can be managed separately by other systems, so that the CBPP may not need to generate the parameters. The set of account-related data also triggers the update of account parameters in the mobile application, as well as the device threshold management parameters used to update the risk management parameters in the issuer / host system when possible. May include.
The mobile application can store or receive from the cloud a number of risk management parameters (eg, limited usage thresholds) that trigger an update of the current set of account parameters. When the account parameters are near the time of expiration (eg, when the next transaction performed by LUK will be exhausted to one or more sets of limited usage thresholds), the mobile application will use the account. -You may request an update from the CBPP via the MAP to replenish the parameters. The device threshold management parameters monitored by the mobile application include, for example, the number of transactions with a given set of account parameters that can be done before the account parameters need to be updated (eg 5 transactions). It's fine. The mobile application may send a warning to the mobile wallet platform before exceeding this limit so that the portable communication device can be used for one or more transactions before it begins to be rejected. (For example, a warning can be sent after four transactions to make a portable communication device available for one or more transactions). Therefore, if the account parameter is valid for a given number of transactions in the CBPP risk management parameter, then the number of transactions for the on-device threshold management parameter managed by the mobile application in the CBPP to trigger replenishment. It can be configured with a threshold lower than the value.
Device threshold management parameters can also include a validity period (eg, 5 days) for a given set of account parameters before they need to be updated. The mobile application 114 can notify the mobile wallet platform before it is exhausted to this limit to request a new set of account parameters (eg after 4 days). Therefore, if the account parameter has an expiration date in CBPP, the validity value for the on-device threshold management parameter managed by the mobile application is the specified time in CBPP to trigger replenishment. It can be configured by the previous threshold. In some embodiments, the device threshold management parameter also uses the transaction volume for the mobile application to determine whether the account parameter should be updated (for example, if the transaction volume is low, the account parameter. (May not require immediate update), cumulative transaction volume as a trigger for account parameter updates based on the sum of individual transaction volumes, and / or international if considered more risky It may include, but is not limited to, national vs. international risk settings to trigger more updates than usual for a typical transaction.
Due to the limited use of account parameters, additional risk management parameters specific to cloud-based environments may be implemented and implemented by the issuer / host system. These risk management parameters can be provided to the issuer / host system by the CBPP during the active account management process, or can be defined and managed separately. For example, the issuer / host system issues a warning to request the CBPP to generate a new set of account parameters to be replenished in the mobile application before the issuer / host system issues the current account. It may be verified that a set of parameters (eg, LUK and associated key index) can only be used a limited number of times (eg, 5 times). The issuer / host system also has a limited period of time (eg 5 days) for the current set of account parameters before the new set of account parameters needs to be generated by CBPP and sent to the mobile application. You may check that only) can be used.
Additional risk management parameters such as individual transaction volume and cumulative total transaction volume can also be checked by the issuer / host system. For example, low transaction volumes may not require immediate update of account parameters, and high transaction values may require more frequent updates. As another example, when the cumulative total transaction volume based on the sum of the individual transaction volumes is exceeded, the issuer / host system needs to generate and replenish a new set of account parameters in the mobile application. , CBPP may be notified. Domestic-to-international risk settings can also be checked to trigger updates more frequently if an international transaction is considered more risky.
After the CBPP receives a request from either the MAP or the issuer / host system for the account parameters to be updated, the CBPP can proceed with data generation for a given account. CBPP stores in its own hardware security module and uses the newly generated key index to generate a LUK derived from the MDK (specific to cloud-based environments). You may use a set of keys, or the CBPP may search the MDK-derived LUK using a newly generated key index from the issuer / host system hardware security module. ..
After generating a new set of account parameters, or otherwise searching, CBPP may send the account parameters to the requested entity. The MAP may receive a new set of account parameters and device threshold management parameters and then send the set to the mobile application. In some embodiments, the set of risk parameters or limited usage thresholds for a given account may change over time, and the new set of account parameters will have different thresholds than the previous set of account parameters. Can have. The threshold limit may change, for example, based on the consumer's propensity to consume, or when the consumer travels abroad. The issuer / host system can also receive a new set of account parameters from the CBPP. In some embodiments, the CBPP may be disconnected from the issuer / host system or may not be connected in real time. In this case, the issuer / host system can use the time stamp in the authorization message to determine when the data will be generated. In particular, the key index may be generated to include the concept of the date when the account parameter was generated.
The MAP and issuer / host system can take some action after receiving a new set of account and device threshold management parameters from the CBPP. MAP can deliver and apply a new set of account parameters to mobile applications over communication networks. After replenishing the account parameter set in the mobile application, the old set of account parameter sets is obsolete and can be removed from the mobile application. If the MAP is unable to communicate with the mobile application immediately, it may continue to try until communication with the mobile application is established, otherwise the issuer / host system will have the old account parameters from that point on. You may start rejecting transactions that take place in the set of. In some examples, the MAP receives confirmation from the mobile application that the account parameters have been updated to notify the issuer / host system to start with a new set of account parameters. You can do it. The issuer / host system may also update the risk management parameters for a given set of account parameters as soon as the update data is available. If the issuer / host system receives updated data directly from the CBPP in real time or with a certain delay, for example, the issuer / host system may apply a new set of data to a mobile application. You may refresh the risk management parameters for the new set of account parameters when you receive a confirmation of success from the CBPP. If the issuer / host system does not receive the update data directly from the CBPP, the issuer / host system may receive a new set of account parameters in the first transaction made by the post-update portable communication device. At that time, the processing permission system is a new red
The issuer / host system may operate in sync with the CBPP and thus the MAP to ensure that the transaction data processing process is in sync with the account parameter generation process. Data generation and data host processing systems also use algorithms, time stamps and other mechanisms to ensure that the data in issuer / host systems and mobile applications is consistent, up-to-date and the same risk model. Can be ensured to follow.
Settlement and settlement transaction processing After the settlement transaction is initiated on the access device, when it is processed by the processing authorization system, the mobile application and issuer / host system can take additional actions to process the cloud-based transaction. When a payment transaction occurs and the portable communication device and contactless reader exchange data, the mobile application uses the LUK stored in the mobile application or the key index associated with it. Transactional ciphertexts (eg, application ciphertexts (AC)) can be generated. From the reader's point of view, the transaction may look like a regular non-contact transaction. For integrated chip-based transactions, access device maps can provide an unpredictable number (UN) used to generate transaction ciphertext. For magnetic stripe-based transactions, the transaction ciphertext may be generated by the mobile application without using the input from the access device. In some embodiments, the dynamic card verification value (dCVV) can be omitted.
After the mobile application sends transaction ciphertext and other transaction data to the access device, the mobile application accounts by checking on-device threshold management parameters (eg, on-device limited usage thresholds). You may check that the parameters are still valid. The mobile application may warn the MAP when it exceeds the device threshold management parameters and requests a new set of account parameters from the CBPP. The mobile application allows the old set of account parameters to still be used in later transactions to allow the issuer / host system to make authorization and risk decisions, even if the account parameters have not been updated in the mobile application. You may check.
After the mobile application interacts with the access device, transaction data is passed to the issuer / host system by the merchant and acquirer. When the issuer / host system receives transaction data in an authorization request message, the issuer / host system demonstrates the transaction code and other transaction data, and if necessary, assigns an alternate account identifier or token. It may be converted to a real account identifier (eg real PAN), checked for risk parameters, and verified that the account is good. The issuer / host system may verify that the data, especially the transaction ciphertext and key index, is still valid for a given account by checking the risk management parameters. The CBPP may request a new set of account parameters from the CBPP that will be warned when the risk management parameters are exceeded and should be replenished in the mobile application via the MAP. Even if the account parameters have not been updated in the mobile application, the issuer / host system accepts this risk for a given account, BIN or PAN range, or for a specific transactional environment (eg domestic vs. international). If the issuer thinks it can, it may verify that the old set of account parameters can still be used in later transactions.
The account parameters are beyond the issuer / host system's point of view because they have not been updated in the mobile application, but the issuer / host system allows the transaction and has a certain tolerance level. You may give it. You may notify the CBPP that the issuer / host system may have begun to reject further transactions if the account parameters have not been updated in the mobile application. Thresholds such as the number of transactions and the validity period that allows the CBPP to be notified in advance before exceeding the actual risk management parameters are set for each of the risk management parameters in the issuer / host system. This gives the CBPP additional time to generate a new set of account parameters, allowing the MAP to replenish the account parameters in the mobile application.
Verification of payment To carry out the transaction, the consumer may activate the portable communication device and then present the portable communication device to the contactless reader to proceed with the transaction. In some embodiments, activating the portable communication device may involve the consumer making input to the Consumer Device Card Holder Verification Method (CDCVM) on the user interface of the portable communication device. .. Depending on the mobile application configuration, the CDCVM may be device level (eg screen lock) or mobile application level (eg application password / passcode). The mobile application can be set up to use CDCVM for each transaction or for each transaction above a certain transaction volume. If the mobile application is configured to use the CDCVM, the consumer may be prompted to make the corresponding input to the CDCVM to allow before or during the mobile payment transaction. If the CDCVM is used in a transaction and the CDCVM is obtained prior to presentation to the contactless reader of the portable communication device, the transaction may proceed to completion. If the CDCVM is used in a transaction and the CDCVM is not obtained prior to presentation to the contactless reader of the portable communication device, the transaction process may depend on the merchant access device version.
The CBPP can provide a set of features where the issuer can configure the CDCVM, and this CDCVM configuration information (eg screen lock, passcode, etc.) is provisioned for the mobile application. The CBPP may support issuer CDCVM requirements and allow issuers to configure CDCVM data in provisioning data. In some embodiments, the issuer / host system may determine if the input corresponding to the CDCVM has been made. If the input corresponding to the CDCVM is captured by the device, the result can be passed to the issuer / host system in an authorization message for transaction processing.
Provisioning CBPP can provide a set of provisioning features that allow cloud-based account data to be sent to the MAP. CBPP can manage the data for each cloud-based account and ensure that the data is sent to the MAP on a request-by-request basis. The CBPP can support provisioning capabilities when data is prepared and then sent to the MAP to allow issuers to initiate requests to replenish or update cloud-based account data. CBPP provides provisioning capabilities for provisioning account parameter data to the MAP for each account holder, allowing the data to be prepared and packaged before being sent to the MAP. For example, the CBPP may provide the ability to provision semi-static data parts (eg, account identifiers or tokens) and dynamic data parts (eg, LUKs and key indexes) to the MAP. The CBPP may maintain a state machine per account and provide push or pull functionality to / from the MAP to initiate provisioning / replenishment requests. The CBPP may provide replenishment capabilities for provisioning account parameter data to the MAP for each account holder. The CBPP may provide issuer-to-push features for provisioning / replenishment functionality. CBPP can provide provisioning / replenishment functionality that supports a single account that can be initiated by a MAP or issuer / host system. In some embodiments, the CBPP may provide updated account parameters as part of a provisioning / replenishment request only when invoked by a mobile application.
Life cycle management Lifecycle Management is a set of features that perform account lifecycle events. The CBPP may receive and process lifecycle event messages from the MAP or from the issuer / host system. In some cases, lifecycle requests can be initiated by consumers, such as when removing an account from a mobile application or blocking an account from an issuer to address fraudulent activity. The CBPP180 provides per-account lifecycle management capabilities and can provide account lifecycle events such as adding, deleting, suspending, and resuming suspended accounts. In some embodiments, an account lifecycle event may include replacing or blocking an account and / or managing a lost or stolen account. The CBPP may provide an interface for MAP and / or issuer / host systems to perform lifecycle updates for consumer accounts. The query may trigger the provisioning or replenishment of new account parameters. In some embodiments, the CBPP may act on a lifecycle event such as deleting or suspending an account in response to such a request immediately. CBPP can provide notification of all lifecycle events to affected systems such as issuer / host systems and MAPs.
Deferred payment processing Deferred payment verification can reduce the risk of fake account parameters and also reduce the exposure of account parameters stored on portable communication devices, for example issuer / host systems are periodic. Verification can be performed, which limits the exposure associated with the account parameters stored on the portable communication device. The CBPP may define a protocol for exchanging postpaid payment verification messages. The deferred payment verification protocol may be based on a real-time interface and may follow Transport Level Security (TLS). Either the issuer / host system and / or CBPP can trigger the exchange of postpaid payment verification messages. The CBPP may give issuers the option to configure postpaid settlement validation parameters. With this option, CBPP triggers the exchange of postpaid payment verification messages. For example, the issuer may configure the parameters to trigger postpaid settlement validation for transactions where the CBPP exceeds a threshold (eg, $ 100). The issuer may configure the parameters so that the CBPP triggers postpaid payment validation after each renewal of the account parameters or after multiple renewals (eg, after 5 renewals). .. In some embodiments, the issuer may configure the parameters so that the issuer / host system initiates postpaid payment verification. In this case, CBPP facilitates the exchange of messages between the issuer / host system and the mobile application.
In some embodiments, the CBPP can avoid taking any action based on the results of the validation and instead inform the issuer / host system of suspicious activity. The issuer / host system may determine the appropriate action based on those processes and the risk profile of the account. The CBPP may support postpaid payment processing to address using transaction validation logs to verify that the appropriate device has made the payment. The CBPP will verify that the transaction log for a given set of account parameters stored on a portable communication device matches the transaction in the issuer / host system, for example, so that the appropriate device is accounted for. It may support postpaid settlement processing to address using transaction validation logs to verify whether a request for parameter replenishment has been initiated. The CBPP can provide an option to configure the threshold to trigger a deferred payment validation message from the CBPP. CBPP can take lifecycle management actions based on the results of postpaid payment verification. If the validation fails, the CBPP may inform the issuer / host system of suspicious activity. The CBPP may provide additional information in the transaction validation log, such as location information about the transaction or unique device identifier.
X. Mobile Application Platform (MAP) This section describes some additional details of the functionality that can be achieved by the Mobile Application Platform (MAP) (eg MAP170). According to some embodiments, the MAP can manage the mobile application and intermediate communication between the CBPP and the mobile application. MAP enrolls in cloud-based payment services, provisions cloud-based payment accounts, active account management (ie account parameter replenishment), account lifecycle management, and postpaid payment transaction validation log requests. It can support cloud-based payment dialogue such as. MAP and CBPP can communicate using secure transport channels such as time-limited SSL or HTTPS. MAP and CBPP are Web Services Security (WSS: Web Services) Security) allows you to exchange secure web service messages.
To communicate with the mobile application, MAP uses single or multi-factor authentication to establish a secure channel between the mobile application and the MAP, users, portable communication devices, and / or You may authenticate your mobile application. At the time of this support, MAP can establish an account by a consumer with a unique username and password. The password is memorable and can be verified by MAP. Consumers can create their mobile application credit certificates (username / password) through the enrollment process. In some embodiments, this username and password may be different or the same as the portable communication device verification or CDCVM.
Enrollment and Account Provisioning MAPs CBPP or issuer account and consumer enrollment data received from mobile applications to demonstrate enrollment requirements and to carry out the identification and validation process defined by the issuer. / Can be sent to the host system. The issuer may be involved in the enrollment process (eg, the issuer makes an acceptance / rejection enrollment decision or delegates the decision to a third party under predetermined conditions). In both cases, the issuer may control the criteria, specifically defining account verification methods and consumer authentication methods. The MAP can support receiving enrollment requests and associated enrollment data from mobile applications.
The MAP can route enrollment requests and associated data to the CBPP and / or issuer / host system. Upon successful enrollment, MAP may initiate a provisioning request with CBPP. If provisioning with CBPP is successful, MAP may receive data from CBPP to configure a new cloud-based payment account in the mobile application. The MAP may receive provisioning confirmations or failure notifications from mobile applications. The MAP may route confirmation or failure notifications from the mobile application to the CBPP and / or the issuer / host system. If provisioning by CBPP is unsuccessful, MAP can receive enrollment failure notifications from CBPP and MAP can route provisioning failure notifications to mobile applications. The mobile application may display the appropriate message to the consumer.
Active Account Management To mitigate the risk of account parameters being compromised, account parameters are not only generated periodically by the CBPP (or by the issuer / host system) and replenished in the mobile application, but also in the active state. Refresh on the issuer / host system to maintain the account on. For the active account management process to be initiated, CBPP can receive replenishment requests for new account parameters from mobile applications through the MAP. The CBPP may also act on replenishment requests received from the issuer / host system. MAP acts as a broker, routing communications to mobile applications and to CBPP for active account management dialogue.
In the pull implementation, the MAP receives an account parameter replenishment request from the mobile application. MAP can establish a secure communication channel before it begins exchanging request messages from mobile applications. After receiving the replenishment request, MAP sends a replenishment request message to the CBPP. After processing the replenishment request, CBPP sends new account parameters to the MAP, which then sends those parameters to the mobile application. If necessary, MAP may reestablish a secure connection with the mobile application. If the MAP fails to send the account parameter replenishment response from the CBPP to the mobile application after a certain number of attempts in the time window, the MAP indicates that the account parameter replenishment delivery attempt was unsuccessful. May be notified to.
In the push implementation, the CBPP (or issuer / host system) initiates the process for updating account parameters. The CBPP sends a push message to the MAP to initiate a replenishment push. The MAP then sends a push message to the mobile application. The mobile application then generates an account parameter replenishment request according to the pull flow described above. Prior to initiating the exchange of sensitive information, MAP may perform user, portable communication device, and / or application level authentication according to security requirements. If the MAP fails to send the account parameter replenishment response from the CBPP to the mobile application after a certain number of attempts in the specified time window, then the MAP has failed the account parameter replenishment attempt. May be notified to CBPP.
When the mobile application receives and processes a new set of account parameters from either the push or pull implementation, the mobile application may generate a status or confirmation notification to the MAP, which then states the status. Or send a confirmation notice to CBPP.
Lifecycle Management When consumers initiate account deletion, MAP can facilitate the exchange of deletion messages from mobile applications to CBPP and issuer / host systems. MAP can delete the account data associated with the account from its database and send a deletion message from the mobile application to the CBPP.
When the issuer initiates account deletion, the MAP can facilitate the exchange of deletion messages from the CBPP or issuer / host system to the mobile application. The issuer / host system may send a delete request to the CBPP or MAP. The MAP can send a delete message from the issuer / host system or CBPP to the mobile application. After receiving the acknowledgment from the mobile application, the MAP can send the acknowledgment to the CBPP or the issuer / host system. The MAP can ensure that the account deletion request is sent to the appropriate mobile application installed on the appropriate portable communication device. MAP removes the data associated with the deleted account from its records and the account previously provisioned for a particular consumer's mobile application profile is no longer an active cloud-based payment account. You can be sure that.
When the issuer / host system or CBPP initiates an account suspension, the MAP can facilitate the exchange of suspension messages from the CBPP or issuer / host system to the mobile application. The issuer / host system may send a stop request to the CBPP or MAP. The MAP can send a stop message from the issuer / host system or CBPP to the mobile application. After receiving the acknowledgment from the mobile application, the MAP can send the acknowledgment to the CBPP or the issuer / host system. The MAP can ensure that the account suspension request is sent to the appropriate mobile application installed on the appropriate portable communication device.
When the issuer / host system or CBPP initiates account resumption, the MAP can facilitate the exchange of resumption messages from the CBPP or issuer / host system to the mobile application. The issuer / host system may send a resume request to the CBPP or directly to the MAP. The MAP can send a resume message from the issuer / host system or CBPP to the mobile application. After receiving the acknowledgment from the mobile application, the MAP can send the acknowledgment to the CBPP or the issuer / host system. The MAP can ensure that the account resumption request is sent to the appropriate mobile application installed on the appropriate portable communication device.
Deferred payment processing Postpaid payment dialogue can help limit the exposure of account parameters stored on portable communication devices, as it can help issuers mitigate the risk of threatening account parameters. The MAP can support receiving information captured from on-device transaction validation logs (eg, corresponding to a particular key index) to ensure the accuracy of account parameter replenishment requests. .. Issuer / host systems that work in conjunction with the CBPP have the option to initiate requests for transaction validation log data captured and stored by mobile applications through the MAP. The mobile application may respond via the MAP to a request that has the requested transaction validation log data. This data can then be verified by the issuer / host system to see if a particular transaction was caused by the queried portable communication device. Examples of data elements that can be used for this purpose were made from a mobile application for transaction time (eg, contactless interaction time) for each transaction performed using a set of account parameters. It may include an application transaction counter (ATC) that counts the number of transactions, the transaction volume, and / or the unpredictable number of terminals (UN) received from the access device during the transaction.
For the purpose of using transaction validation logs to see if a transaction was made from a portable communication device, the MAP is about mobile application transaction validation log data from the CBPP issued by the issuer / host system. You may receive the request. To use the transaction validation log to provide the CBPP with a degree of confidence that the request originated from the appropriate portable communication device, MAP uses the transaction validation log in the account parameter replenishment request from the mobile application. You may use the information provided. The MAP can identify and authenticate portable communication devices before transmitting or receiving postpaid payment dialogue messages to mobile applications.
XI. Mobile application This section describes some additional details about portable communication devices and some of the functionality that can be performed by mobile applications installed on portable communication devices used to perform cloud-based transactions. .. FIG. 12 shows a detailed block diagram of the portable communication device 1201 according to some embodiments. The portable communication device 1201 can include device hardware 1204 and memory 1202. Device hardware 1204 may include processor 1205, communication subsystem 1209, user interface 1206, display 1207 (which may be part of user interface 1206), and contactless interface 1208. Processor 1205 can be implemented as one or more integrated circuits (eg, one or more single-core or multi-core microprocessors and / or microcontrollers) and is used to control the operation of portable communication device 1201. .. The processor 1205 can execute various programs in response to the program code or computer-readable code stored in the memory 1202, and can maintain a plurality of simultaneously executing programs or processes. Communication subsystem 1209 includes one or more RF transceivers and / or connectors that can be used by the portable communication device 1201 to connect to an external network (eg, communication network 192) and to communicate with other devices. Good. User interface 1206 may include any combination of input and output elements to allow the user to interact with and recall the functionality of portable communication device 1201. In some embodiments, the display 1207 may be part of the user interface 1206.
Contactless interface 1208 may include one or more RF transceivers to interact with the contactless reader of the access device. In a secure element-based implementation, only secure elements can access the contactless interface 1208. In the cloud-based payment techniques described herein, the contactless interface 1208 can be accessed by mobile OS 1214 without the need for the use of secure elements. In some embodiments, the display 1207 can be part of the non-contact interface 1208 and is used, for example, to perform transactions using QR codes, barcodes, and so on.
Memory 1202 is any number of non-volatile memory (eg, flash memory) and volatile memory (eg, DRAM, SRAM), or any combination of any other non-temporary storage medium, or any medium thereof. Can be implemented using a combination of. The memory 202 is a mobile application in which one or more mobile applications including the mobile OS 1214 and the mobile application 1212 to be executed by the processor 1205 (for example, mobile wallet application, mobile payment application, etc.) reside. You may remember the environment 1210. The mobile OS 1214 may implement a set of card emulation APIs 1216 that can be called by the mobile application 1212 to access the contactless interface 208 and interact with the access device.
Regarding the cloud-based payment implementation form, the payment system environment (for example, PPSE) and mobile payment application functionality are unified to the mobile application 1212, while the secure element-based implementation form is one of these functionality from the secure element. Part or all may be provided. The mobile application 1212 may include a cloud-based payment logic circuit 1250. Cloud-based payment logic 1250 is contactless payment logic 1258, proximity payment system environment (PPSE) logic 1256, transaction validation log 1254, and account parameter threshold 1252 (eg, one or more associated with LUK1242). A set of limited usage thresholds) may be included. The contactless payment logic circuit 1258 may include functionality that enables contactless communication to be performed by the contactless reader of the access device to perform a contactless transaction. Used to inform access devices that payment products are available on the mobile application 1212 using PPSE logic circuit 1256. The access device then uses this information to select a payment account and initiate a contact transaction. Transaction validation log 1254 can be used to support deferred payments. The mobile application 1212 can maintain transaction validation log 1254 (which can be hidden from the consumer) that holds transaction details for transactions initiated by the mobile application 1212. Mobile application 1212 can also use transaction validation log 1254 to support active account management processes and postpaid payment interactions. The account parameter threshold 1252 (eg, limited use threshold) is initially configured and updated with various thresholds to request for updated account parameters (eg, lifetime, number of transactions, cumulative transaction volume, etc.). When to start
The mobile application 1212 can also include an account parameter storage device 1240 and a mobile application platform (MAP) communication logic circuit 1246. Account parameter storage device 1240 stores account parameters (eg, account identifier or surrogate account identifier or token, LUK1242, key index 1244, etc.) used to initiate a cloud-based payment transaction. Request, send and receive information to manage a user's cloud-based payment account by enabling secure communication with the Mobile Application Platform (MAP) using MAP logic circuit 1246. To do. It may include logic circuits for consuming and processing information for account management logic circuits 1230.
The account management logic 1230 provides information for cloud-based payment services such as enrollment logic circuit 1232, provisioning logic circuit 1233, active account management logic circuit 1236, life cycle management logic circuit 1234, and postpaid payment dialogue logic circuit 1238. Includes logic circuits for processing. Enrollment logic circuit 1232 includes logic circuits for consumers to initiate account enrollment to cloud-based payment services. The provisioning logic circuit 1233 includes a logic circuit for processing issuer data for configuring an account into the mobile application 1212, including provisioning of initial account parameters. Active account management logic circuit 1236 can be used by MAP to initiate a request to update account parameters when the account parameter threshold is exceeded. Lifecycle Management Logic Circuits 1234 provides logic circuits for initiating and processing account lifecycle events such as consumer-driven deletion, issuer-driven deletion, issuer-driven shutdown, and / or issuer-driven recovery. May include. Deferred payment payment Uses interactive logic circuit 1238 to support payment verification. The deferred payment dialogue logic circuit 1238 may include a logic circuit for receiving and responding to a request for transaction verification log 1254 from the MAP. Postpaid settlement dialogue logic 238 can also be used to support account parameter replenishment, extracting the required information from transaction validation log 1254 and sending it to the MAP as part of the account parameter replenishment request. Good.
The mobile application 1212 can also include the mobile application function 1220. The mobile application function 1220 may include a consumer verification method (CVM) logic circuit 1224, a payment mode 1222, and a user setting 1226. CVM logic 1224 is required to identify the mobile application passcode or on-device verification method (eg, screen lock), or any other verification information method supported by the mobile application 1212. It may include logic circuits. Payment mode 1222 may include logic circuits to support different ways of setting up mobile application 1212 and portable communication device 1201 so that it is ready to initiate a transaction, in manual mode and / or always connected. May include support for modes.
Manual mode allows the consumer to (1) open the mobile application 1212, (2) perform user input for consumer verification methods, if necessary, and (3) contactless payment transactions and simple. A state in which the mobile application 1212 is configured to be accessible for making payments after explicitly selecting to select an account to perform one or a limited number of transactions. For manual mode, you can make a decision as to whether the Consumer Device Cardholder Verification Method (CDCVM) will be required before making a payment. When CDCVM is used, a two-tap scenario for overpriced transactions may not be required. Conversely, if the issuer decides not to ask for a CDCVM in manual mode in order to reduce usage barriers, the consumer will be able to make a transaction once the conditions for manual mode operation are met. Become. In this latter scenario, mobile application 1212 can support CDCVM entry if CDCVM is required during overpriced payments.
The always-on mode is a state in which the account (default account) on the portable communication device 1212 is intended to have continuous access to the contactless reader. The portable communication device with the account set in this state allows the consumer to initiate a contactless payment transaction by presenting the portable communication device to the contactless reader. Always-on mode can also support device verification (referred to as always-on mode with on-device verification below). This setting allows for additional security. For example, the user must unlock the user interface or display screen of the portable communication device before the mobile application 1212 responds to a contactless reader attempting to initiate a payment transaction.
13 to 15 show the mobile application 1212 when the mobile application 1212 is in the manual mode (Fig. 13), the always-on mode (Fig. 14), and the always-on mode by on-device verification (Fig. 15). State Indicates a machine. The various states shown in FIGS. 13 to 15 will be described below.
Downloaded: Consumers download the application. The downloaded state can be a transient state depending on the application and OS design. If the consumer taps the portable communication device on the non-contact reader in this state, no information is exchanged between the portable communication device and the reader.
Installed: The consumer does the installation. If the consumer taps the portable communication device on the non-contact reader in this state, no information is exchanged between the portable communication device and the reader.
Initialized: Consumers set up an account with MAP, but no payment card is added. If the consumer taps the portable communication device on the non-contact reader in this state, no information is exchanged between the portable communication device and the reader.
Active: The consumer adds a payment card and valid account parameters are provisioned in the mobile application. If the consumer taps the portable communication device on the non-contact reader in this state, the mobile application may respond according to the demonstration processing mode.
Ready for payment (manual mode): The consumer activates the payment card to make the payment. This is a transient condition, and mobile applications must set up a timer to get out of this condition. The mobile application moves to the payment transmission state if it becomes active or moves when the transaction times out, or to the "CDCVM input" if a CDCVM input is required. When the consumer taps the portable communication device on the contactless reader in this state, the mobile application begins the contactless data exchange.
Ready to settle (both always connected modes): The portable communication device is ready to initiate a transaction with a contactless reader. Consumers choose always-on mode in their mobile applications. The mobile application moves to the payment transmission state when a transaction is made, or to the CDCVM input state when a CDCVM is required. When the consumer taps the portable communication device on the contactless reader in this state, the mobile application begins the contactless data exchange.
CDCVM input: The non-contact reader asks for the CDCVM. This is a transient condition, and the mobile application must set up a timer to get out of that state. The mobile application will move to a second tap state when the consumer enters a valid CDCVM, otherwise after the timer expires, it will be active (manual mode) or ready for payment (both always connected). Go to (in mode). If the consumer taps the portable communication device on the non-contact reader in this state, no information is exchanged between the portable communication device and the reader.
Second tap: The portable communication device is ready for a second tap to transmit the CDCVM verification information to the contactless reader. This is a transient state, and mobile applications may set up timers to exit that state. The mobile application moves to the payment sending state when the consumer taps the portable communication device on the contactless reader, otherwise after the timer expires, it is active (manual mode) or ready for payment (manual mode). Move to (in both always-on modes). When the consumer taps the portable communication device on the contactless reader in this state, the CDCVM verification flag is sent to the contactless reader.
Payment is sent: The consumer sends the payment payload to a contactless reader. This is a transient condition. If the consumer taps the portable communication device on the non-contact reader in this state, no information is exchanged between the portable communication device and the reader.
Background: The mobile application is running in the background. If the consumer taps the portable communication device on the non-contact reader in this state, the mobile application may respond according to the demonstration processing mode.
Not running: The mobile application is not running on a portable communication device. If the consumer taps a device on the non-contact reader in this state, no information is exchanged between the portable communication device and the reader.
Mobile application security To provide additional security, the mobile application 1212 can obfuscate and protect keys stored by accepted mechanisms, such as key wrapping. The code and data in the mobile application 1212 may be obfuscated to protect the code against reverse engineering. Communication between the mobile application 1212 and the MAP containing sensitive information can be exchanged after the channel has been secured by the MAP (eg, using TLS). Mobile application 1212 may comply with appropriate industry standards such as FIPS-140-2. Error codes sent to the OS logging framework can only disclose information that does not assist an attacker. Event logs and debugging information can avoid exposing any credit certificate directly or indirectly. You can also encrypt the logged information. The mobile application 1212 and MAP may provide a mechanism for detecting, rejecting, and reporting when the portable communication device is in debug mode. Device states, including jailbreaks, routing, malware, mobile application runtime integrity, etc., are sent to mobile application 1212 prior to personalization and provisioning of mobile application 1212, and new account parameters are sent to mobile application 1212. You can check it when you go. If any compromise is detected, the mobile application 1212 can be deactivated and the reason for deactivating it will be relayed to the original MAP. Mobile application security capabilities can be built essentially in mobile application 1212, minimizing reliance on portable communication device and OS platform security capabilities. Debye for devices that have been rooted or stolen to access
In some embodiments, the MAP may authenticate the consumer and / or portable communication device 1201 using single or multi-factor authentication. The storage device / memory used to store the key in the mobile application 1212 may proceed to the certification process. For example, a root credit certificate can be generated. High entropy attributes such as the hard to clone feature (UF) that resides on portable communication devices, and the time that the input to generate the root credit certificate is received and stored from the back-end system. It can arise from the limit attribute. Subsequent credit certificates hosted in key memory are key encrypted with the generated key encryption (KEK). It can be extracted from key). The user credit certificate can be used as input to generate the root credit certificate and KEK. The obfuscated substitution logic can be provided as an input for generating the root credit certificate and KEK. Obfuscated substitution logic can be based on the xx-morphic (polymorphic, metamorphic) mechanism. The credit certificate store can be time-limited and variable. The stored data key extracted from the key store can be encrypted and decrypted from yet another KEK when resident as in-use data. Binary attributes to the application logic that processes the keys can be provided as inputs (binds) to generate the KEK to protect the data in use. In-use data keys can be scrubbed through application logic circuits that process the keys. The following Protection Profile (PP): PP for KEK1 protection key store, PP for KEK1 & 2 generated logic circuit, PP for KEK2 protection in-use data key, and / or PP for in-use data key scrub Can be established.
The code and data in the mobile application 1212 can be obfuscated to protect the code against reverse engineering. Application logic circuits that also extract keys can prove tamper resistance to ensure key protection. The application logic that hosts the credit certificate used to authenticate and the credit certificate itself can prove tamper resistance. Tamper resistance / detection mechanism can be implemented to maintain the integrity of code / application logic circuits. The user credit certificate can be used as an input for encrypting the confidential part of the code logic circuit. The obfuscated substitution logic can be provided as an input to generate the KEK. Obfuscated substitution logic can be based on the xx-morphic (polymorphic, metamorphic) mechanism. Code and application logic circuits can be time-limited and variable. The following protection profiles (PPs): tamper resistance / detection PP, obfuscation generation logic circuit PP, PP to ensure measured initialization, and / or update PP can be established. ..
Mobile application launch and account preparation At each consumer-driven manual launch (ie, by hard or soft key, or from the device's mobile application environment 1210), the mobile application 1212 determines whether the portable communication device 1201 is in debug mode. You may check and report to MAP. The mobile application 1212 checks that the payment account provisioned in the mobile application 1212 is active and available, checks whether the account parameter threshold 1252 has been exceeded, and requires an account parameter replenishment request. You may judge whether it is said to be. The mobile application 1212 may check for jailbreaking, rooting, malware, mobile application runtime integrity, and whether new account parameters are sent to the mobile application 1212. If device or application compromise is detected, the mobile application 1212 can be deactivated and the reason for deactivating is relayed to the original MAP.
If the payment account managed by the mobile application 1212 is suspended, it may be advantageous for consumers to provide informed information to take the necessary actions or to contact their issuers. In order to prepare the payment account provisioned in the mobile application 1212 for payment, the user may first choose to make payments using this payment account. This can be done in the following ways for each payment mode: In manual mode, the user launches the mobile application 1212, selects a card or account to use for payment, navigates to the payment screen for the selected card or account, and selects payment. In always-on mode, the user selects a card or account to be used for payment as the default payment account. For always-on mode with on-device verification, the user selects a card or account to be used for payment as the default payment account. Once the card or account for payment is selected, the mobile application 1212 may configure PPSE1256 with the appropriate account details for the selected card or account. Once PPSE1256 is configured, the selected card or account is ready for payment when the user taps the portable communication device 1201 on the access device or otherwise communicates with the access device.
Mobile Application User Verification In some embodiments, the mobile application 1212 may support user verification when interacting with the MAP and / or the access device. When interacting with the MAP (eg, provisioning or replenishing account parameters stored in the account parameter storage device 1240), the unique username and password are verified by the MAP, depending on the issuer's dialogue and needs. You can do it. The mobile application 1212 may also provide the access device with a list of cardholder verification methods supported by the mobile application 1212 when interacting with the access device. Cardholder verification methods supported in card environments such as online PINs and signatures can also be supported by cloud-based payments.
The portable communication device 1201 may also have a specific category of cardholder verification methods called Consumer Device Cardholder Verification Methods (CDCVM). There are a number of different methods that can be used to give the CDCVM to the mobile application 1212, which can contain the same username / password utilized during MAP validation. Various levels of security may be provided by the CDCVM method utilized by the mobile application 212.
The cloud-based CDC VM provided by connecting to an online service can provide the highest level of security. This is considered to be the same username / password used to authenticate to the MAP. However, in the absence of data connectivity, this results in payments that require a CDC VM fail. Therefore, this option may be used in manual mode to prevent settlement transactions in the absence of a two-tap process intermediate due to lack of data connectivity.
On-device CDCVM, done by the operating system at the portable communication device level, can provide a better consumer experience. One example is the method required to unlock a portable communication device screen. The mobile application 1212 receives an indication from the portable communication device 1201 when the input of the CDCVM is successful. Mobile application 1212 does not have the ability to modify the on-device CDCVM. The mobile application CDCVM can be performed when opening and launching the mobile application 1212. One example is entering a numeric code to open the mobile application 1212. This method may be used in combination with more secure options, such as cloud-based CDCVM, as software-based CDCVM may be less secure than other options, where the mobile application CDCVM is available. Used when there is no good data connectivity.
User settings The mobile application 1212 may receive these options or a subset thereof in a suitable manner, or may assume defaults for one or more of these options. These options represent common behaviors for mobile application 1212. For example, user settings 1226 may include payment modes such as manual, always-on, or always-on with on-device verification. User settings 1226 determine whether the consumer can make changes to these initial preferences, how many times the consumer has to make payments in each mode, and in a two-tap transaction where the consumer has to make a payment. You have to enter the password several times (which may be applicable to high-value transaction scenarios), and in the absence of consumer interaction, how long should the mobile application 1212 be closed? It may include whether or not it is. User settings 1226 can also support password changes. The user may populate the consumer-selected mobile application password by invoking the password change process and provide the current or default password as well as the consumer's newly selected password. Consumers may choose this option to change their previously selected passcode / password. The mobile application 1212 can prompt consumers to enter their current and new passwords (passwords are hidden or not hidden, depending on the implementation and method, new to ensure accurate entries. Consumers can be prompted to enter their password twice). The mobile application 1212 can replace the old passcode / password with the new passcode / password. The passcode / password location may be stored remotely or locally to the device.
If the consumer chooses to modify the always-on mode setting, PPSE1256 may be configured appropriately (eg, the File Control Information (FCI) template can be updated with a directory entry for the default payment account. ). This ensures that the default account is used when bringing the portable communication device 1212 close to the access device when conducting transactions.
When the on-device verification setting is turned on, the mobile application 1212 can ensure that it does not start a transaction until the verification method is confirmed. The verification method in this case can be set by the user to unlock the phone. If the verification is successful, you can set the validation fields for the Contingent Valuation Method (CVM) in the mobile application 1212. Successful validation in this configuration is then propagated to the access device and finally to the issuer via the CVM validation field.
Mobile application interaction event The behavior of the mobile application interaction event is whether the mobile application 1212 is currently running when this event occurs, or whether the underlying mobile application environment 1210 receives the event. It may depend on whether it is the trigger that triggered 1212. Depending on the capabilities of the underlying mobile application environment 1210, the mobile application 1212 may be distinguishable between various events.
Receiving push notifications by the underlying mobile application environment 1210 can target the mobile application 1212. The mobile application 1212 arrives in bandwidth via the MAP to supplement account parameters for cloud-based accounts, or to provide other data that may be required by the issuer and / or the MAP. Can be pushed. Communication channels via MAP may also be used by issuers to send lifecycle management events such as stop, resume, and delete.
Upon shutdown, the mobile application 1212 can ensure that the state of each payment account is in a suitable state. This may be the case not only when the mobile application 1212 proceeds to the expected shutdown sequence, but also when the mobile application 1212 is abruptly terminated. Previous account validation applied during manual launch may be disabled and the payment account CDCVM validation indicator may be set to deny. The mobile application 1212 can ensure that the settings selected by the consumer are reflected and that the payment account is in a regular idle state.
Mobile Application Shutdown / Cleanup The mobile application 1212 may perform cleanup when it is closed abruptly (eg, a portable communication device is blocked by low battery power) or intentionally. In any payment mode, the mobile application 1212 saves the payment mode, account parameters, associated thresholds, and default card settings so that it will be available when the mobile application 1212 is relaunched. can do. The mobile application 1212 terminates any in-progress transaction, closes any session with any open MAP, and saves the transaction log if the transaction is successful earlier and shuts down immediately. , Any system and memory resources used by mobile application 1212 may be released. In some embodiments, the mobile application 1212 may be chosen to set or reset the "CDCVM done successful" flag, depending on how the CDCVM validation logic is implemented.
The implementation logic associated with the PPSE configuration may differ during shutdown / cleanup depending on the payment mode selected when the mobile application 1212 is shut down. In always-on mode, the mobile application 1212 may save the PPSE configuration so that the PPSE receives the default card as the only active card for payment when the mobile application 1212 is relaunched. In manual mode, the PPSE configuration does not have to be saved at shutdown. Rather, PPSEs may be repopulated the next time the consumer selects a card and makes a payment the next time the mobile application 1212 is launched. Upon shutdown of the mobile application 1212, the mobile application 1212 can ensure that the settings selected by the consumer are reflected and that the payment account is in their regular idle state.
Navigation from the mobile application When the consumer presses the home or back button on the portable communication device to exit the mobile application 1212 and then back, the mobile application 1212 continues to run in the background and lines. You may continue the operation that is being done. The mobile application 1212 may apply additional security restrictions, such as timeouts, to limit the amount of time it can continue to run in the background. If the consumer puts the mobile application 1212 in the background while the transaction is in progress, the mobile application 1212 may continue processing the transaction.
Mobile Application Uninstall As part of the uninstall process, the mobile application 1212 may clear any sensitive data such as keys, certificates, and account parameters. The mobile application 1212 may inform MAP that the CBPP and issuer / host system can perform the lifecycle management process required for the account provisioned in the mobile application 1212 at the time of uninstallation. The mobile application 1212 can close any open session by the MAP, terminate any ongoing transactions if present, and free any system and memory resources used by the mobile application 1212.
The account enrollment mobile application 1212 may include an enrollment logic 1232 for enrolling / adding a payment account to a cloud-based payment program unless the issuer provides another channel to achieve it. The issuer may be directly involved in the enrollment process (eg, the issuer may make an accept / reject enrollment decision directly or make that decision under predetermined conditions. Leave it to the party). In both cases, the issuer may have full control over acceptance criteria, specifically defining card account verification methods and consumer authentication methods.
Enrollment logic circuit 1232 may allow consumers to enter card details to initiate payment account enrollment. The details for capture may be determined by the issuer / host system and / or CBPP, but should be sufficient to uniquely identify and verify the payment account. The issuer / host system and / or CBPP may determine the methods and information required to authenticate the consumer who owns the account. The mobile application 1212 may send payment account enrollment data to the MAP, which will then send and manage the account enrollment and account verification process by the issuer / host system and / or CBPP. Become.
If the enrollment is successful, the mobile application 1212 will be launched from the MAP, payment account application ID (AID), PPSE. You may receive data to provision a new payment account for payment, including AID, payment account issuer settings, payment account card design, account parameters, account parameter settings and thresholds. If the enrollment is successful, the enrollment logic 1232 may provision a payment account based on the information received from the MAP. The mobile application 1212 may also require consumers to set an account verification method (eg, passcode) if it has not yet been configured as part of the configuration process. After completing the account configuration, the mobile application 1212 may display a message to the consumer that the enrollment was successful. The mobile application 1212 may support and configure account parameter thresholds as defined by the issuer / host system and / or CBPP. The account parameter threshold is a large number of transactions (ie, the cumulative number of transactions that will trigger a replenishment request for a specific payment account), validity period (ie, the mobile application 1212 replenishment request for a specific payment account). Time elapsed before triggering) and / or cumulative transaction volume (ie, for a specific account before mobile application 1212 triggers a replenishment request for that account) May include the total amount over one or more transactions). If the enrollment is unsuccessful, the mobile application 1212 receives and processes a failure notification and reason code, displays a message to the consumer that the enrollment was unsuccessful, and takes any appropriate action. May request.
Payment using mobile application The mobile application 1212 allows a user to perform a contactless transaction on a contactless access device via the portable communication device 1201. The mobile application 1212 facilitates this by using the account parameters provided by CBPP to generate the data format and perform the settlement transaction. To avoid consumer confusion about where payments will be assigned, if there are multiple payments mobile applications 1212 installed on a portable communication device, the consumer will choose which mobile application for payments. It may be necessary to choose whether to use. There are many options on how to make this possible. Consumers may, at their discretion, set default payment mobile applications in their mobile OS settings. Consumers may be able to set default payment products in their specific mobile application settings. Consumers may be able to manually select payment products within their mobile application. To ensure that consumer selection is used, mobile application 1212 can present the selected payment account to the access device. The mobile application 1212 may support either an integrated chip-based transaction path or a magnetic stripe-based transaction path, depending on what type of transaction the access device supports. The integrated chip-based transaction is the default path used by chip card-enabled access devices, and the magnetic stripe-based transaction is the default path used by magnetic stripe-enabled access devices.
In some embodiments, the mobile application 1212 may support multiple application identifiers (AIDs) for a single account. A single account may have, for example, if the transactions performed on that account can be processed by different payment processing networks and / or the account has different services, features, product types, and payment capabilities associated with the account. If so, multiple AIDs may be associated. Multiple AIDs are communicated to the access device, allowing the access device to select the preferred AID, how to process the transaction (eg, which payment processing network), and / or what service. Alternatively, it is possible to select whether the feature can be associated with the transaction. Multiple AIDs can populate directory entries for PPSEs and communicate with access devices for this purpose.
For example, a single account may have a general debit AID and a payment processing network specific AID (eg, Visa AID) associated with the single account. These AIDs can be populated into directory entries for PPSE, and the PPSE File Control Information (FCI) for each directory entry is the Issuer Identification Number (IIN) and the Issuer Country Code (ICC). Code) may be included. In some embodiments, the CVM for the debit AID can be an online CVM (eg, an online PIN) and the CVM for the payment processing network specific AID can be a signature.
Contactless payment is when the consumer taps the portable communication device 1201 against a contactless reader (eg, an NFC reader) or, in other cases, communicates with the contactless reader of the access device. It can be started by (for example, displaying a QR code or barcode). The access device may require a Contingent Valuation Method (CVM) for transactions above the threshold (eg, transactions above $ 20). The mobile application 1212 can support a number of different CVMs, including a mobile-specific consumer device cardholder verification method (CDCVM). Not all access devices can support CDCVM, in which case an alternative CVM such as a signature or online PIN can be requested.
The indication of a successful CDCVM entry is sent to the contactless reader during the settlement transaction. The mobile application 1212 can configure the appropriate data in the account parameters at the time of payment when the CDCVM verification is successful. Whenever the CDCVM input is successful, the mobile application 1212 stores this information so that a CDCVM validation indicator and a CDCVM type indicator can be set and passed to the contactless reader during the payment transaction. This allows the access device to prevent consumers from being prompted for CDCVM entries in the access device. The mobile application 1212 may be capable of providing successful CDCVM indications when requested by an access device during a two-tap payment transaction.
When the mobile application 1212 is locked by inactivity, the mobile application 1212 remembers this information so that the CDCVM validation indicator can be set to deny. If contactless payment is initiated in this state, the access device may prompt the consumer for a CDCVM entry. The mobile application 1212 can provide the ability for CDCVM to be reconfigured if it provides a consumer validation entry method for CDCVM. The mobile application 1212 may set a limit on the number of consumer verification attempts, which locks the mobile application 1212. For security purposes, the issuer may request additional consumer verification before unlocking the mobile application 1212. In some embodiments, the mobile application 1212 may have a CDC VM that is out of sync with the companion card's online PIN.
In manual mode, the consumer may open or launch the mobile application 1212 to enable payment functionality. When the mobile application 1212 is opened, the functionality can be enabled so that consumers can initiate payments by tapping the portable communication device 1201 against the contactless reader. The portable communication device 1201 can prevent consumers from making transactions based on any account stored in the mobile application 1212 if the mobile application 1212 is not opened and activated as a foreground application. ..
If the CDCVM indicator is not affirmative (ie, no valid CDCVM entry is still entered), the mobile application 1212 can request a CDCVM entry when it is opened. If this implementation path is chosen, it can ensure that consumers are not reclaimed for CDCVM entries during a payment transaction (ie, avoiding the two-tap scenario for high-value payments). Conversely, if this implementation path is not chosen, the usefulness for consumers can be improved by omitting the request for CDCVM entries for transactions below the high price limit, but in exchange for the high price. You will be asked for a CDCVM entry if the payment is made.
If there are two or more payment cards or accounts available in the mobile application 1212, the card or account selected as the default will be payment unless the consumer selects an alternative card or account to activate for payment. It will be used for transactions. When the mobile application 1212 is opened, the PPSE1256 becomes popular and the portable communication device 201 can initiate a payment transaction. The mobile application 1212 may display to the consumer a message indicating that the portable communication device 1201 is "ready for payment". The mobile application 1212 may set a time limit for inactivity, beyond which the mobile application 1212 may be locked. This ensures that the consumer remains in control of payment functionality and that manual mode is not morphed into always-on mode by inactivity. The mobile application 1212 can also allow consumers to select a preferred time period in their settings. Depending on whether or not the CDCVM is required, the mobile application 1212 may require a CDCVM entry to unlock the mobile application 1212 after being locked by inactivity.
In always-on mode, the contactless payment capability is available whenever the phone screen is active. Non-contact capabilities (eg NFC) can be made available even when the phone screen is still locked. To ensure that consumers are aware of this capability and can opt in for its use, the mobile application 1212 may disable the always-on mode as the default mode. Whenever the phone screen is active, PPSE1256 can be activated and populated, and the portable communication device 1201 can initiate a payment transaction. When a consumer initiates a contactless transaction on a locked screen, the contactless reader may request a CDCVM entry. When device-level CDCVM is used, the icon indicator can be displayed on the notification bar and the phone screen must be unlocked. Mobile application 1212 The consumer may then be instructed to tap the portable communication device 1201 to the non-contact reader. When a mobile application level CDCVM is used, an icon indicator can be displayed on the notification bar. The mobile application 1212 presents the CDCVM entry screen to the consumer, after which the contactless reader may be instructed to tap the portable communication device 1201 if the CDCVM input is successful. ..
In always-on mode with device verification, contactless payment capabilities are available whenever the phone screen is active and unlocked. The non-contact capability is not available when the phone screen is still locked. Whenever the phone screen is unlocked, PPSE1256 can be activated and populated, and the portable communication device 1201 can initiate a payment transaction. When a consumer attempts to initiate a contactless payment on a locked screen, nothing happens on either the access device or the portable communication device 1201 because the contactless reader will not be able to communicate with the portable communication device 1201. There is no. The contactless reader may request a CDCVM entry when the consumer initiates a contactless payment on the unlocked screen. When device-level CDCVM is used, the mobile application 1212 may require the non-contact reader to tap the portable communication device 1201. When a mobile application level CDCVM is used, the mobile application 1212 presents the CDCVM entry screen to the consumer, and then upon successful input of the CDCVM, the portable communication device 1201 to the contactless reader. You may instruct the consumer to tap.
When the mobile application 1212 and the access device complete communication, provide data, and complete the transaction, the mobile application 1212 may display a message indicating that the payment has been sent. Contactless payments made using the integrated chip-based transaction path may give the mobile application 1212 some transaction data, such as transaction volume and merchant information. The mobile application 1212 can populate this information in the message that sent the payment. Contactless payments made using the magnetic stripe-based transaction path do not give mobile application 1212 any transaction data. Following the payment, the mobile application 1212 may check the account parameter thresholds and determine if the mobile application 1212 needs to send a request for replenishment of the account parameters.
Active Account Management The active account management logic circuit 1236 of the mobile application 1212 initiates and manages a request to replenish account parameters when the account parameter threshold is exceeded. To reduce the risk of the account parameters stored in the account parameter storage device 1240 being threatened, the account parameters can be generated periodically by the CBPP and are not only replenished in the mobile application 1212 but also issuer / host. By refreshing in the system, you can keep your account active. For the active account management process to be initiated, the CBPP may receive replenishment requests for new account parameters from mobile application 1212 through the MAP. The CBPP180 can also comply with requests received from the issuer / host system.
In some embodiments, the active account management logic circuit 1236 of the mobile application 1212 can trigger an account parameter update or replenishment by an account parameter replenishment pull process. Active account management logic 1236 attempts to initiate the account parameter replenishment flow at the time the consumer launches the mobile application 1212, or after the transaction is complete and the account parameter threshold 1252 is exceeded. Good. Upon receiving the updated set of account parameters, the mobile application 1212 may process the account parameter payload and make the new account parameters available for payment. Upon successful processing of the new set of account parameters, mobile application 1212 may generate a notification to the MAP. The MAP may notify the CBPP that the account parameters have been successfully delivered to the mobile application 1212. Updated account parameters are a new set of device threshold management parameters (eg, of previous account parameters) that the issuer may want to use when the customer is in different environments (eg, outside the domestic market). Note that it may be accompanied by a limited usage threshold that differs from the set. Prior to initiating the exchange of sensitive information, MAP may perform user, device, and application level authentication.
Account parameter updates or replenishments can also be performed through the account parameter replenishment push process. In this flow, CBPP initiates the process for updating account parameters. The CBPP sends a push message to the MAP to initiate a replenishment push. The MAP can then send a push message to the mobile application 1212. The mobile application 1212 then generates an account parameter update request according to the replenishment pull flow described above. Prior to initiating the exchange of sensitive information, MAP may perform user, device, and application level authentication. If user-level authentication is used because the previous authentication has expired, the mobile application 1212 may cache the request until the customer opens the mobile application 1212 and performs user-level authentication. After successful authentication, mobile application 1212 follows the same procedure as the replenishment pull flow. If user-level authentication is not required because the previous authentication has not expired, the mobile application 1212 can immediately follow the same steps as the replenishment pull flow.
Upon receiving the updated set of account parameters, the active account management logic circuit 1236 checks the validity of the new account parameters, makes the new account parameters available for payment, and makes the account parameters available. You may reset the threshold, reset the account parameter threshold configuration, and remove the old set of account parameters. In some embodiments, the mobile application 1212 may be able to initiate a transaction even if the account parameters have not been updated due to lack of network connectivity. The issuer / host system, or payment processing network acting on behalf of the issuer, in combination with other issuer-defined risk metrics, decides to approve or reject the transaction based on knowledge of stale account parameters. Can be done.
The mobile application 1212 may include a number of cloud-based payment device account parameter thresholds 1252, or risk limits that trigger an update of the current set of account parameters. This may include a large number of transactions, lifetimes, and / or cumulative transaction volumes and the like. If the account parameter is valid for a large number of transactions in CBPP, the account parameter threshold 1252 in mobile application 1212 has a lower threshold number of transactions to trigger replenishment (eg, the number of transactions in CBPP). It can be composed of less than one). If the account parameter has an expiration date in CBPP, the account parameter threshold 1252 in the mobile application 1212 can consist of a threshold amount earlier than the expiration date for triggering replenishment. When available from a contactless reader, the transaction volume can be used by active account management logic circuit 1236 to make a decision as to whether account parameters should be updated. If the transaction volume is small, it may not always be necessary to update the account parameters immediately. However, this mechanism may be unreliable in environments where the mobile application 1212 does not consistently receive transaction volumes from access terminals. If available, the cumulative transaction volume can be used as a trigger for account parameter updates. This limit is based on the sum of the individual transaction volumes. This data may not always be reliable from the perspective of mobile application 1212 unless the data is synchronized with the issuer / host system to ensure that a given transaction volume is approved. .. Using the national vs. international risk setting, the transaction when the international transaction is considered more risky.
The account lifecycle management mobile application 1212 is a lifecycle management logic circuit that provides a user-driven deletion option for the user to delete a card or account from the mobile application 1212 via the lifecycle management logic circuit 1234. May include 1234. Account lifecycle logic circuit 1234 may delete account parameters stored in account parameter storage device 1240 associated with that account, along with all other account configuration data or artifacts. Lifecycle management logic circuit 1234 can initiate the process of account deletion in CBPP by initiating a deletion request to CBPP through MAP.
Lifecycle Management Logic 1234 can enable an issuer-driven deletion mechanism for issuers to delete accounts. The issuer / host system can send a delete request to the CBPP, which may then route the request to the mobile application 1212. Lifecycle Management Logic 1234 may delete locally stored account parameters associated with an account, along with all other account configuration data or artifacts. The mobile application 1212 may send an acknowledgment to the MAP indicating that the deletion is complete. The mobile application 1212 can also display a message to the user informing them that their account will be deleted.
Lifecycle management logic circuit 1234 may enable an issuer-driven shutdown mechanism for issuers to suspend accounts. The issuer / host system may send a stop request to the CBPP, which may then route the request to the mobile application 1212. Lifecycle management logic circuit 1234 can suspend a card or account in mobile application 1212. In the suspended state, the account cannot be made selectable in the mobile application settings for making payments. Lifecycle management logic circuit 1234 may send an acknowledgment to the MAP after account suspension. The mobile application 1212 can display a message to the user informing them that their account will be suspended, and can also instruct consumers to contact the issuing bank.
Lifecycle management logic circuit 1234 may enable an issuer-driven resumption mechanism for the issuer to reactivate an account when it is suspended in mobile application 1212. The issuer / host system may send a resume request to the CBPP, which can then route the request to the mobile application 1212. Lifecycle management logic circuit 1234 can reactivate a card or account in mobile application 1212. After resumption, the card or account may be selectable in the mobile application settings for payment. After resuming the account, the mobile application 1212 may send an acknowledgment to the MAP and may display a message to the user informing the user that the account has been reopened.
Deferred Payment Dialogue A deferred payment dialogue or process can help issuers mitigate the risk of threatening account parameters, thus helping to limit the exposure of account parameters stored on the portable communication device 1201. be able to. The information contained in the transaction validation log can be used to provide a reference point that the CBPP assists in ensuring that account parameter replenishment requests arise from the expected portable communication device. The mobile application 1212 can configure an account parameter replenishment request by including a deferred payment logic circuit 1238 and extracting information from the transaction validation log 1254.
In addition, issuer / host systems that work in conjunction with CBPP have the option to validate transactions by initiating requests for transaction validation log data captured and stored by mobile application 1212 through the MAP. The mobile application 1212 may respond through the MAP to a request with the requested transaction validation log data. This data can then be validated by the issuer / host system to see if a particular transaction originated from the queried portable communication device. Examples of data elements that may be included in the transaction validation log are for each transaction the transaction time (eg, contactless interaction time, transaction volume, and unpredictable number received from the access device during the transaction. ), As well as account parameter information such as the key index associated with the LUK used to perform the transaction. For settlement transaction validation, the mobile application 1212 may receive and process requests from the MAP for transaction validation log data captured and stored by the mobile application 1212. The mobile application 1212 may respond to a MAP request with the requested transaction log data. The mobile application 1212 may use the current account parameter LUK or equivalent in the dynamic data portion of the account parameter to sign the requested transaction validation log data.
Transaction validation log The mobile application 1212 determines whether the transaction has been accepted or rejected, or whether the mobile application 1212 has visibility into the outcome of the transaction (eg, accepted or rejected). Regardless, transaction validation log 1254 can be maintained to log all contactless interactions (eg NFC) depending on the payment account parameters when shared with the access device. The mobile application 1212 may store transaction validation log data for the current and previous set of account parameters for each payment account. In some embodiments, transaction validation log data for the old set of account parameters can be deleted when the mobile application 1212 receives the new set of account parameters. Transaction validation log 1254 may or may not be accessible to the user.
XII. Illustrative Computer Systems The various entities or components described herein with reference to Figure 1 are associated with one or more computer devices to facilitate the functions described herein. It may be done or it may be operated. Any entity or component in FIG. 1, including any server or database, may use any suitable number of subsystems to facilitate functionality.
An example of such a subsystem or component is shown in FIG. The subsystems shown in Figure 16 are interconnected via system bus 1602. Additional subsystems such as printer 1604, keyboard 1606, fixed disk 1608 (or other memory, including computer-readable media), monitor 1610 coupled to display adapter 1612, and others are shown. Peripherals and I / O devices coupled to the Input / Output (I / O: input / output) controller 1614 (which can be a processor or other suitable controller) are in the art, such as serial port 1616. It can be coupled to a computer system by any known means. For example, a serial port 1616 or an external interface 1618 can be used to connect a computer device to a wide area network such as the Internet, a mouse input device, or a scanner. Through interconnection over the system bus, the central processor 1620 communicates with its respective subsystems and not only executes instructions from system memory 1622 or fixed disk 1608, but also exchanges information between subsystems. Allows you to control. System memory 1622 and / or fixed disk 1608 can embody a computer-readable medium.
The examples of the present invention are not limited to the examples described above. For example, separate functional blocks are shown for issuers, payment processing networks, and acquirers, but some entities may perform all of these functions and be included in the embodiments of the present invention.
Specific details regarding some of the aspects described above are given above. The specific details of the specific embodiments may be combined in any suitable manner without departing from the spirit and scope of the embodiments of the present invention. For example, back-end processing, data analysis, data collection, and other transactions may all be combined in some embodiments of the invention. However, other examples of the present invention may be directed to specific examples associated with each individual aspect, or specific combinations of these individual aspects.
It should be understood that the invention described above can be implemented in the form of control logic circuits using computer software (stored in tangible physical media) in a modular or integrated fashion. Those skilled in the art will know and understand hardware and other ways and / or methods for implementing the present invention using hardware and software combinations, based on the disclosures and teachings provided herein. Will.
Any of the software components or features described herein, for example, using conventional or object-oriented techniques, eg Java®, C.<sup>++</sup>Alternatively, it may be implemented as software code to be executed by a processor using any suitable computer language such as Perl. The software code can be a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard drive or floppy (registered trademark) disk, or a CD-ROM. It can be stored as a series of commands or commands on a computer-readable medium such as an optical medium. Any such computer-readable medium may reside on or within a single computer, and may reside on or within various computers within a system or network.
The above explanation is an example and is not limited. Many variations of the invention will be apparent to those skilled in the art when reviewing the present disclosure. Therefore, the scope of the invention should not be determined with reference to the above description, but rather with reference to the pending claims, along with its full scope or equivalent.
One or more features from any other embodiment can be combined with one or more features from any other embodiment without departing from the scope of the invention.
The statements "a", "an" or "the" are intended to mean "one or more" unless specifically indicated otherwise.
All patents, patent applications, publications, and specifications mentioned above are incorporated herein by reference in their entirety for all purposes. Neither is recognized as prior art.
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 | Cited during |
|---|---|---|---|
| US11842350B2 | Cited by | United States of America | Applicant |
| US12469021B2 | Cited by | United States of America | Applicant |
| US11875344B2 | Cited by | United States of America | Applicant |
| JP03034641A | Cites | Japan | – |
| JP2007513529A | Cites | Japan | – |
| JP2010004390A | Cites | Japan | – |
| US20110240745A1 | Cites | United States of America | – |
| US20130262317A1 | Cites | United States of America | – |
45 members in 11 offices
Priority claims24
| Document | Office | Kind | Date |
|---|---|---|---|
| 201361918643 | United States of America | P | |
| 201361918643 | United States of America | P | |
| 61918643 | United States of America | – | |
| 201461941227 | United States of America | P | |
| 201461941227 | United States of America | P | |
| 61941227 | United States of America | – | |
| 201461982169 | United States of America | P | |
| 201461982169 | United States of America | P | |
| 61982169 | United States of America | – | |
| 201461983635 | United States of America | P | |
| 201461983635 | United States of America | P | |
| 61983635 | United States of America | – | |
| 2014071622 | United States of America | W | |
| 2014071622 | United States of America | W | |
| 61918643 | – | – | – |
| 61941227 | – | – | – |
| 61982169 | – | – | – |
| 61983635 | – | – | – |
| US201361918643P | – | – | – |
| US2014071622 | – | – | – |
| US201461941227P | – | – | – |
| US201461982169P | – | – | – |
| US201461983635P | – | – | – |
| WO2014US71622 | – | – | – |
Members45
| Document | Office | Kind | |
|---|---|---|---|
| CA2931093A1 | Canada | A1 | |
| US2015178724A1 | United States of America | A1 | |
| US2015180836A1 | United States of America | A1 | |
| WO2015095771A1 | World Intellectual Property Organization (WIPO) | A1 | |
| US2016140545A1 | United States of America | A1 | |
| AU2014368949A1 | Australia | A1 | |
| SG11201604906QA | Singapore | A | |
| US2016217452A1 | United States of America | A1 | |
| CN105830107A | China | A | |
| KR20160101117A | Republic of Korea | A | |
| EP3084701A1 | European Patent Office (EPO) | A1 | |
| JP2017507518A | Japan | A | |
| BR112016014106A2 | Brazil | A2 | |
| EP3084701A4 | European Patent Office (EPO) | A4 | |
| RU2016129192A | Russian Federation | A | |
| US9922322B2 | United States of America | B2 | |
| US9972005B2 | United States of America | B2 | |
| US2018189783A1 | United States of America | A1 | |
| US2018232722A1 | United States of America | A1 | |
| SG10201900964QA | Singapore | A | |
| RU2686014C1 | Russian Federation | C1 | |
| RU2019111186A | Russian Federation | A | |
| JP6551850B2This record | Japan | B2 | |
| US10402814B2 | United States of America | B2 | |
| US2019295063A1 | United States of America | A1 | |
| JP2019180097A | Japan | A | |
| US10664824B2 | United States of America | B2 | |
| US10909522B2 | United States of America | B2 | |
| KR102221636B1 | Republic of Korea | B1 | |
| KR20210024669A | Republic of Korea | A | |
| US11017386B2 | United States of America | B2 | |
| KR102293822B1 | Republic of Korea | B1 | |
| KR20210107894A | Republic of Korea | A | |
| US11164176B2 | United States of America | B2 | |
| US2021357925A1 | United States of America | A1 | |
| US2022019995A1 | United States of America | A1 | |
| EP3084701B1 | European Patent Office (EPO) | B1 | |
| KR102408299B1 | Republic of Korea | B1 | |
| KR20220084421A | Republic of Korea | A | |
| EP4057203A1 | European Patent Office (EPO) | A1 | |
| CN115082065A | China | A | |
| KR102526100B1 | Republic of Korea | B1 | |
| US11875344B2 | United States of America | B2 | |
| US12469021B2 | United States of America | B2 | |
| CN115082065B | China | B |
15 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 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A821A521 | A521 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| 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 | |
| Written submission of copy of amendment under article 19 pctJAPANESE INTERMEDIATE CODE: A524A524 | A524 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 6551850
- Publication, DOCDB
- 6551850
- Publication, EPODOC
- JP6551850B
- Application
- 2016541553
- Application, DOCDB
- 2016541553
- Application, EPODOC
- JP20160541553
Titles2
- Japanese
- クラウド・ベース・トランザクションの方法及びシステム
- English
- Cloud-based transaction methods and systems
Classification
- CPC, 18
- G06Q20/327
- H04L9/0822
- G06Q20/38
- G06Q20/322
- G06Q20/385
- G06Q20/3829
- H04L9/0869
- H04L63/0428
- H04L2209/24
- G06Q2220/00
- G06Q20/326
- G06Q20/3672
- G06Q20/389
- H04L9/0866
- H04L9/088
- H04L9/14
- H04L2209/20
- G06Q20/00
- IPC, 1
- H04L9 08
