Cloud-based transaction method and system

Abstract

Techniques for enhancing security of a communication device when conducting a transaction using the communication device can include generating a transaction cryptogram using a limited use key (LUK) and sending, to an access device, a token that substitutes for an actual account identifier and the transaction cryptogram for the transaction. The LUK can be associated with a set of one or more limited use thresholds that limit use of the LUK, and the transaction can be authorized based at least on whether use of the LUK has exceeded the set of one or more limited use thresholds.

Description

[0001] Cross-references to related applications

[0002] This application is a divisional application of Chinese Patent Application No. 201480069311.1, entitled "Cloud-based Transaction Method and System". Chinese Patent Application No. 201480069311.1 claims priority to U.S. Provisional Application No. 61 / 918,643, filed December 19, 2013; U.S. Provisional Application No. 61 / 941,227, filed February 18, 2014; U.S. Provisional Application No. 61 / 982,169, filed April 21, 2014; and U.S. Provisional Application No. 61 / 983,635, filed April 24, 2014, all of which are incorporated herein by reference in their entirety for all purposes. background

[0003] Advances in the capabilities of portable communication devices (PCDs) have enabled PCDs, such as smartphones, to be used as payment instruments for contactless transactions. For example, a PCD can be placed near an access device (such as a point-of-sale (POS) terminal) to transfer account information from the PCD to the access device for a transaction. To provide a secure operating environment for storing account information securely on the PCD, secure elements are used, such as subscriber identity module (SIM) cards, dedicated integrated chips built into the PCD, or dedicated components offered as aftermarket solutions. During a transaction, the secure element communicates directly with the PCD's contactless interface (e.g., a near-field communication (NFC) transceiver) to transfer payment data to the access device's contactless reader. The secure element is considered secure because the account information is stored in tamper-proof hardware that protects the account information from malware or viruses that could infect the operating system or applications running on the PCD.

[0004] However, the secure element used in portable communication devices is typically not under the control of financial institutions, but rather under the control of mobile network operators (MNOs). Therefore, issuing banks and / or payment processors may not have direct access to the secure element to provide account authentication and payment functionality. To gain access to the secure element, issuing banks and / or payment processors may have to establish commercial agreements and technical connectivity with the party controlling over-the-air (OTA) personalization of the secure element. This is a cumbersome and complex process. Furthermore, incorporating a secure element increases the manufacturing cost of the portable communication device and the overall cost of the finished product.

[0005] Accordingly, in some cases, it would be desirable to use a portable communication device that does not have a secure element to make payments. Alternatively, if a portable communication device has a secure element, it can be desirable to not rely on the use of the secure element. However, because the secure element is not used, transaction security can be a concern.

[0006] Embodiments of the present invention address these and other problems, individually and collectively. Specifically, embodiments of the present invention address security concerns by using a mobile communication device that does not have or rely on a secure element for payment transactions.

[0007] BRIEF OVERVIEW

[0008] Embodiments of the present invention provide techniques for enhancing the security of a communication device when a transaction is conducted using the communication device (e.g., a portable communication device). The communication device, which can or can not have a secure element, can use the techniques described herein because the techniques do not require the use of a secure element to protect the security of account credentials. Embodiments of the present invention instead utilize limited-use account parameters, which can have a limited period of use and can no longer be used to conduct transactions once expired, until the limited-use account parameters are replenished from a cloud (e.g., a remote computer). Accordingly, transactions conducted using the techniques described herein can be referred to as "cloud-based transactions."

[0009] According to some embodiments, a method for enhancing the security of a communication device when a transaction is conducted using the communication device can include receiving, from a remote computer, a limited-use key (LUK) associated with a set of one or more limited-use thresholds that limit the use of the LUK. The method can also include generating, using the LUK, a transaction cryptogram by the communication device; and conducting, by the communication device, the transaction by sending a token that replaces an actual account identifier and the transaction cryptogram to an access device. The transaction can be authorized based at least on whether the use of the LUK has exceeded the set of one or more limited-use thresholds.

[0010] According to some embodiments, a communication device can include a processor; and a memory coupled to the processor and storing a mobile application that performs operations to enhance the security of the communication device when a transaction is conducted using the communication device. The operations can include receiving a limited-use key (LUK) associated with a set of one or more limited-use thresholds that limit the use of the LUK; generating a transaction cryptogram using the LUK; and sending, to an access device, a token that replaces an actual account identifier and the transaction cryptogram to conduct the transaction. The transaction can be authorized based at least on whether the use of the LUK has exceeded the set of one or more limited-use thresholds.

[0011] According to some embodiments, a method for enhancing security of a communication device when a transaction is conducted using the communication device can include generating, by a computer, a second encryption key using a first encryption key to encrypt account information; and generating a limited use key (LUK) using the second key to encrypt key index information, wherein the key index information includes a key index having information related to the generation of the LUK. The method can further include providing the LUK and the key index to the communication device to facilitate generation of a transaction key for a transaction conducted using the communication device. The transaction can be authorized based on the LUK and the transaction key.

[0012] According to some embodiments, a computer for enhancing security of a communication device when a transaction is conducted using the communication device can include a processor, and a memory storing computer readable code that, when executed by the processor, causes the computer to: generate a second encryption key using a first encryption key to encrypt account information, generate a limited use key (LUK) using the second key to encrypt key index information, and provide the LUK and the key index to the communication device to facilitate generation of a transaction key for a transaction conducted using the communication device. The key index information can include a key index having information related to the generation of the LUK. The transaction can be authorized based on the LUK and the transaction key. BRIEF DESCRIPTION OF DRAWINGS

[0013] Figure 1 A block diagram of a cloud-based transaction system is shown in accordance with some embodiments.

[0014] Figure 2 A communication flow diagram showing an example of an enrollment and configuration process is shown in accordance with some embodiments.

[0015] Figure 3 A communication flow diagram showing an example of performing an integrated chip-based transaction is shown in accordance with some embodiments.

[0016] Figure 4 A communication flow diagram showing an example of performing a magnetic stripe-based transaction is shown in accordance with some embodiments.

[0017] Figure 5 An example of a transaction verification log is shown in accordance with some embodiments.

[0018] Figure 6 A communication flow diagram showing an example of a post-payment verification process is shown in accordance with some embodiments.

[0019] Figure 7 A communication flow diagram showing an example of an account parameter replenishment process is shown in accordance with some embodiments.

[0020] Figure 8 An example of a process for generating a transaction key is shown in accordance with some embodiments.

[0021] Figure 9 An example of an encryption function is shown in accordance with some embodiments.

[0022] Figure 10 A flowchart of an example of a method for enhancing security of a portable communication device is shown in accordance with some embodiments.

[0023] Figure 11 A flowchart of an example of another method for enhancing security of a portable communication device is shown in accordance with some embodiments.

[0024] Figure 12 A block diagram of an example of a portable communication device is shown in accordance with some embodiments.

[0025] Figure 13 A state diagram of an example of a mobile application in a manual mode is shown in accordance with some embodiments.

[0026] Figure 14 A state diagram of an example of a mobile application in an always online mode is shown in accordance with some embodiments.

[0027] Figure 15 A state diagram of an example of a mobile application in an on-device-verified always online mode is shown in accordance with some embodiments.

[0028] Figure 16 A block diagram of an example of a computer system is shown in accordance with some embodiments. DETAILED DESCRIPTION

[0029] Embodiments of the invention provide methods, devices, and systems for cloud-based transactions that can be performed by a communication device with or without a secure element. The technology described herein can utilize card emulation technology (e.g., host card emulation (HCE), etc.) to emulate a smart card on a communication device (e.g., a portable communication device), thereby allowing a mobile application running on the portable communication device to conduct contactless transactions. Under a card emulation environment, the mobile application can access a contactless interface (e.g., a near field communication (NFC) transceiver) of the portable communication device via an operating system (OS) of the portable communication device without involving a secure element. Compared to secure element implementations, the card emulation approach reduces technical and business complexity for card issuers and / or payment processors, as the card issuers and / or payment processors can configure account credentials and payment functionality to a mobile application on the portable communication device without having to access a secure element through a mobile network operator.

[0030] By removing the payment function and control of the account credentials from the secure element's restrictions, the security of the account information can no longer rely on the security based on the tamper-resistant hardware provided by the secure element. Without requiring the presence of the secure element, the account credentials can be stored in a memory of the portable communication device that is not part of the secure element, such as a general memory of the portable communication device. As such, the account credentials can be susceptible to access by malware or viruses that can have infected an application or operating system of the portable communication device.

[0031] To enhance the security of the portable communication device when transactions are conducted without the secure element, instead of using a rigid account credential that can be valid for the duration of the use of the account stored on the portable communication device, the cloud-based techniques described herein provision the portable communication device with limited-use or limited-time-of-use restricted-use account parameters. When the limited use or limited time of use of the restricted-use account parameters is exhausted, the same set of restricted-use account parameters can no longer be used to conduct additional transactions. To conduct additional transactions using the portable communication device, the portable communication device is replenished with new restricted-use account parameters. The restricted-use account parameters provided to the portable communication device can be repeatedly refreshed or replenished from a network (also referred to as "the cloud") during the duration of the use of the account. By managing the transfer and lifecycle of the restricted-use account parameters between the network-based capability set and the portable communication device, the leakage of the mobile application software and / or the account credentials stored on the portable communication device becomes the only limited security risk, as a stolen restricted-use account parameter can at most be used for only a small number of transactions or a limited monetary amount.

[0032] Before discussing details of some embodiments of the application, a description of some terminology can be helpful to understanding the various embodiments.

[0033] A "communication device" can be a device that includes one or more electronic components (e.g., integrated chips) that can communicate with another device. A "portable communication device" is a communication device that can be transported and operated by a user. The portable communication device can provide remote communication capabilities to a network. The portable communication device can be configured to transmit and receive data or communications to and from other devices. The portable communication device can be in the form of a mobile device, such as a mobile phone (e.g., a smart phone, a cellular phone, etc.), a tablet computer, a portable media player, a personal digital assistant (PDA), a wearable computing device (e.g., a watch), an e-reader device, etc., or in the form of a card (e.g., a smart card) or a key fob, etc. Examples of the portable communication device can also include a portable computing device (e.g., a laptop computer, a netbook computer, an ultrabook computer, etc.).

[0034] A "server computer" can include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer can be a database server coupled to a Web server. The server computer can be coupled to a database and can include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. The server computer can comprise one or more computation means and can use any of a variety of computing structures, arrangements, and compilations to service the requests from one or more client computers.

[0035] A "card issuer" can generally refer to a business entity (e.g., a bank) that maintains an account for a user associated with a portable communication device, such as an account registered in a mobile application installed on the portable communication device. The card issuer can also issue account parameters associated with the account to the portable communication device. The card issuer can be associated with a host system that performs some or all functions of the card issuer on behalf of the card issuer.

[0036] A "merchant" can generally be an entity that engages in transactions and can sell or provide a channel for goods or services.

[0037] An "acquirer" can generally be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities can perform the functions of both a card issuer and an acquirer. Some embodiments can include such a single entity card issuer-acquirer.

[0038] An "access device" can be any device suitable for communicating with a merchant computer or a payment processing network, and suitable for integration with a payment device, a user computer device, and / or a user mobile device. An access device can generally be located in any suitable location, such as at a location of a merchant. An access device can take any suitable form. Some examples of access devices include POS devices, cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, websites, and the like. An access device can use any suitable contact or contactless mode of operation to transmit or receive data from or associated with a portable communication device. In some embodiments, where an 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 reader can include any suitable contact or contactless mode of operation. For example, an exemplary card reader can include a radio frequency (RF) antenna, an optical scanner, a bar code reader, or a magnetic stripe reader to interact with a portable communication device.

[0039] An "authorization request message" can be an electronic message sent to request authorization for a transaction. The authorization request message can be sent to a payment processing network and / or the issuer of a payment card. An authorization request message according to some embodiments can comply with ISO 8583, which is 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 include information that can be used to identify an account. The authorization request message can also include additional data elements, such as one or more of a service code, an expiration date, and the like. The authorization request message can also include transaction information, such as any information associated with the current transaction, such as a transaction amount, a merchant identifier, a merchant location, and the like, as well as any other information that can be used to determine whether to identify and / or authorize a transaction. The authorization request message can also include other information, such as information that identifies the access device that generated the authorization request message, information about the location of the access device, and the like.

[0040] An "authorization response message" can be an electronic message reply to an authorization request message. The authorization response message can be generated by a financial issuer or a payment processing network. The authorization response message can include, by way of example only, one or more of the following status indicators: approved - the transaction is approved; declined - the transaction is not approved; or call center - more information is needed for the response, the merchant must call a toll-free authorization phone number. The authorization response message can also include an authorization code, which can be a code returned (directly or through a payment processing network) by a credit card issuing bank to a merchant computer in response to an authorization request message in an electronic message that indicates that a transaction is approved. The code can be used as proof of authorization. As noted above, in some embodiments, a payment processing network can generate or forward the authorization response message to a merchant.

[0041] The term "authenticate," and its derivatives, can refer to a process that can verify an endpoint (including, but not limited to, an application, a person, a device, a process, and a system) to ensure that the endpoint is who they claim to be.

[0042] The term "verify," and its derivatives, can refer to a process that utilizes information to determine whether a base subject is valid under a given set of circumstances. Verification can include any comparison of information to ensure that certain data or information is correct, valid, accurate, legal, and / or reputable.

[0043] A "token" can include a substitute identifier for some piece of information. For example, a payment token can include an identifier that is a substitute for an account identifier of a payment account, such as a primary account number (PAN). For example, a token can include a series of alphanumeric characters that can be used as a substitute for an original account identifier. For example, the PAN "4147 0900 0000 1234" can be replaced with the token "4900 0000 0000 0001." In some embodiments, a token can be "format protected" and can have a numeric format that conforms to an account identifier used in existing payment processing networks (e.g., the ISO 8583 financial transaction message format). In some embodiments, a payment transaction can be initiated, authorized, settled, or resolved using a token in place of a PAN. Tokens can also be used to represent original credentials that would normally be provided in other systems. In some embodiments, a token value can be generated such that recovery of the original PAN or other account identifier from the token value can not be computationally derived. Further, in some embodiments, a token format can be configured to allow an entity receiving the token to identify it as a token and to identify the entity that issued the token.

[0044] An "actual account identifier" can include an original account identifier associated with a payment account. For example, an actual account identifier can be a primary account number (PAN) issued by an issuer of a card account (e.g., a credit card, a debit card, etc.). For example, in some embodiments, an actual account identifier can include a sixteen-digit numeric value, such as "4147 0900 0000 1234." The first six digits of this actual account identifier (e.g., "414709") can represent an actual issuer identifier (BIN) that can identify an issuer of the actual account identifier associated with the actual account identifier.

[0045] An "account parameter" can refer to information related to an account that can be used to conduct transactions on the account. Examples of account parameters can include information that can be used to identify a user's account (e.g., an actual account identifier, a substitute account identifier, a token, etc.), data or information related to a status of the account, one or more keys that can be used to generate cryptographic information, data or information related to the one or more keys, etc. Account parameters can be semi-static or dynamic. A dynamic account parameter can be an account parameter that has a limited period of use and, once expired, can no longer be used to conduct transactions until the account parameter is replenished, refreshed, or replaced. Dynamic account parameters can be replenished frequently during the use period of an account. A semi-static account parameter can be an account parameter that has a longer extended period of use than a dynamic account parameter and is not replenished as frequently or at all during the use period of an account as a dynamic account parameter.

[0046] A "key" can refer to a piece of information that can be used in an encryption algorithm to transform input data into another representation. An encryption algorithm can be an encryption algorithm that transforms original data into an alternative representation, or a decryption algorithm that transforms encrypted information back into the original data. Examples of encryption algorithms can include Triple Data Encryption Standard (TDES), Data Encryption Standard (DES), Advanced Encryption Standard (AES), etc.

[0047] A "cryptogram" can refer to an encrypted representation of a piece of information. A recipient can use a cryptogram to determine whether a generator of the cryptogram possesses a proper key, e.g., by encrypting the underlying information using a valid key, and comparing the result to the received cryptogram.

[0048] A "usage-restricted threshold" can refer to a condition that displays the use of a piece of information. A usage-restricted threshold can be exceeded or exhausted when a base condition is met. For example, a usage-restricted threshold can include a lifetime that indicates an amount of time for which a piece of information remains valid, and once that amount of time has passed, the usage-restricted threshold is exceeded or exhausted, and the piece of information can become invalid and can no longer be used. As another example, a usage-restricted threshold can include a number of times a piece of information can be used, and once that number of times has been used by the piece of information, the usage-restricted threshold is exceeded or exhausted, and the piece of information can become invalid and can no longer be used.

[0049] Details of some embodiments of the present application will now be described.

[0050] I. Account Parameters

[0051] A cloud-based transaction system according to some embodiments provides a set of functions to manage the deployment and use of account parameters for transactions conducted using a portable communication device. An account parameter (which can also be referred to as an "account credential") is information associated with an account (e.g., a financial account, a bank account, a payment account, etc.) associated with a user that can be used to conduct transactions on the user's account. Account parameters can be provisioned or configured to a portable communication device in order to enable the portable communication device to conduct transactions on the user's account (e.g., by placing the portable communication device in proximity to a contactless reader of an access device, such as a point-of-sale (POS) terminal).

[0052] Account parameters can include a semi-static dataset and a dynamic dataset, and some or all account parameters can be use-limited account parameters. The semi-static dataset can include an identifier that can be used to identify an account associated with a user (e.g., an account identifier such as a primary account number (PAN), an alternative account identifier such as an alternative PAN, or a token that is a substitute for an account identifier, etc.), an expiration date, and / or other account details or data that do not necessarily change over an extended period of time, or in some embodiments, over the lifetime of an account. The dynamic dataset can include one or more keys, information associated with the one or more keys, and / or other dynamic data that has a valid usage period and is repeatedly updated or replenished during the lifetime of an account. The dynamic dataset can be used for or related to on-device generation of dynamic transaction cryptograms, or represent dynamic transaction data during a payment transaction.

[0053] The dynamic dataset can be use-limited in the sense that the dynamic dataset can only be used for a limited time or number of transactions, and can need to be replaced, refreshed, updated, or replenished when the dynamic dataset has exhausted its limited usage. For example, the dynamic dataset can include a use-limited key (LUK) that can be used as an encryption key to generate transaction cryptograms during a transaction. The LUK can be associated with a set of one or more use-limited thresholds that limit the usage of the LUK, and transactions conducted using that LUK will be declined once the usage of the LUK has exhausted or exceeded the set of one or more use-limited thresholds, even if the underlying account remains in good standing. The set of one or more use-limited thresholds for implementation can be determined, for example, by the issuer of the account or by a cloud-based payment platform that provides the cloud-based transaction device.

[0054] The set of one or more use-limited thresholds can include at least one of a lifetime that indicates a duration for which the LUK is valid, and / or a cumulative transaction amount that indicates one or more total transaction amounts that the LUK is valid for, or any combination thereof. For example, the LUK can be valid for a lifetime of five days, and transactions conducted using that LUK can be declined after five days have passed since the LUK was generated. As another example, the LUK can be valid for a predetermined volume of five transactions, and a sixth transaction (and any subsequent transactions) conducted using that LUK can be declined. As a further example, the LUK can be valid for a cumulative transaction amount of five hundred dollars, and transactions conducted using the LUK can be declined after that LUK has been used for transactions that aggregate to more than five hundred dollars.

[0055] It should be understood that the above use limit values are merely examples, and that other use limits can be used. For example, the number of transaction use limits can be set to a number in the range of 2 to 10 transactions, or a number in the range of 5 to 50 transactions, etc., and the cumulative transaction amount can be set to a value in the range of $100 to $5,000, or a value in the range of $10 to $1,000.

[0056] It should also be noted that, in some embodiments, the number of transaction use limit thresholds can be set to one transaction, such that each LUK is only valid for one transaction. However, in some embodiments, the network bandwidth available to the portable communication device can be limited, or the portable communication device can not always have uninterrupted network connectivity. As such, in some embodiments, the number of transaction use limit thresholds can be set to more than one transaction (e.g., five transactions) for example to reduce the frequency and amount of LUK replenishment over a period of time, and thus reduce the amount of network traffic used by the portable communication device over a period of time.

[0057] In some embodiments, the set of one or more use limit thresholds can also include a domestic use threshold and an international use threshold indicating separate limits for international transactions vs. domestic transactions. For example, if international transactions are considered to be higher risk, the LUK can remain valid for a higher number of transactions for domestic transactions than for international transactions. The set of one or more use limit thresholds can also include a low value transaction threshold and a high value transaction threshold indicating separate limits for low value transactions vs. high value transactions. For example, the LUK can remain valid for a higher number of transactions for low value transactions (e.g., the LUK is valid for ten transactions below $20) than for high value transactions (e.g., the LUK is valid for five transactions above $20), such that low value transactions will not trigger replenishment of the LUK as frequently as high value transactions.

[0058] In some embodiments, the set of one or more use limit thresholds associated with an account can change upon replenishment of the LUK, such that a new LUK replacing a previous LUK can have different one or more use limits than the previous LUK. This can occur, for example, based on changes in consumer spending habits, location of the portable communication device, or time of year, etc. For example, if the user has a current pattern of making many high value transactions, or when during the holiday season when transaction activity is expected to increase, the new LUK can have higher use limits. As another example, if the location of the portable communication device indicates that the user can have traveled to a high risk country where fraud is prevalent, the new LUK can have lower use limits.

[0059] In embodiments in which the LUK is associated with more than one use-restricted threshold, use of the LUK can be exhausted when any one of the use-restricted thresholds is exceeded, or when some combination of the use-restricted thresholds is exceeded. Thus, replenishment of the LUK can be triggered when any one of the use-restricted thresholds is exceeded or is about to be exceeded, or when some combination of the use-restricted thresholds is exceeded or is about to be exceeded.

[0060] In some embodiments, the use-restricted thresholds associated with the LUK of an account can have different usage limits configured in different components or entities of the cloud-based transaction system. In other words, different components or entities can have different usage limits for a particular use-restricted threshold to trigger replenishment of the LUK. These components or entities that can be configured with different usage limits can include, for example, the user's portable communication device, the cloud-based service provider, and / or the card issuer / host system. According to some embodiments, the usage limit at the portable communication device can be set lower than the usage limit at the cloud-based service provider, and the usage limit at the cloud-based service provider can be set lower than the usage limit at the card issuer. For example, the LUK can have a time-to-live use-restricted threshold, and the on-device usage limit for triggering replenishment of the LUK at the portable communication device can be set at 2 days, the usage limit at the cloud-based service provider can be set at 4 days, and the card issuer usage limit at the card issuer can be set at 5 days. In this example, the portable communication device will normally initiate replenishment of the LUK after 2 days. However, if the portable communication device is turned off or has lost network connectivity, the cloud-based service provider can initiate replenishment of the LUK after 4 days, or the card issuer can initiate replenishment after 5 days, if a new LUK has not already been exchanged to ensure that the LUK is not still stale.

[0061] In some embodiments, different components or entities of the cloud-based transaction system can be configured with different use-restricted thresholds that can trigger replenishment of the LUK. For example, the on-device set of one or more use-restricted thresholds configured on the portable communication device can include time-to-live and number of transactions that will trigger LUK replenishment initiated by the portable communication device, while the cloud-based service provider and / or the card issuer / host system can additionally or alternatively be configured with cumulative transaction amount that triggers LUK replenishment initiated by the cloud-based service provider and / or the card issuer / host system. In other words, different components or entities can monitor different types of conditions or use-restricted thresholds that trigger replenishment of the LUK.

[0062] In some embodiments, the set of one or more usage-restricted threshold values can be specific to an account (e.g., when different accounts can have different usage restrictions), specific to a portable communication device (e.g., when different portable communication devices of a user can have different usage restrictions, even if the underlying account is the same), and / or specific to a mobile application (e.g., when different mobile applications can have different usage restrictions, even if the mobile applications are installed on the same portable communication device and / or even if the underlying account is the same). In some embodiments, the LUKs can also have other usage restrictions, such as which type of merchant, which specific merchant, or which geographic location the LUKs can be used. The specific rules or risk parameters for triggering LUK replenishment and / or for setting the usage-restricted threshold values can be determined by the card issuer or the cloud-based transaction provider.

[0063] The dynamic dataset can also include a key index associated with the LUK. The key index can include information related to the generation of the LUK. For example, the key index can be used as a seed to generate its corresponding LUK. The key index can include time information (e.g., a timestamp) indicating when the LUK was generated, and / or can include a replenishment counter value indicating how many times the LUK has been renewed or replenished for a specific account, mobile application, or portable communication device. In some embodiments, the replenishment counter value can indicate how many times the LUK has been replenished within a predetermined time period, and the replenishment counter value can reset at the expiration of each predetermined time period. This predetermined time period can correspond to, for example, a minimum unit of time that can be determined from the time information, although other predetermined time periods can be used. As an example, if the time information included in the key index indicates until which hour the current LUK was generated, the counter value can indicate how many times the LUK has been replenished in that hour. In some embodiments, the LUK can include an application transaction counter value of the number of transactions that have been made before the mobile application of the portable communication device generates the LUK, or can include a pseudo-random number generated by the cloud-based transaction service provider or by a suitable entity such as the card issuer involved in processing the transaction. It should be understood that the key index can include one or more pieces of information related to the generation of the LUK, and one or more or all of the pieces of information included in the key index can be used as a seed to generate the LUK.

[0064] In some embodiments, the semi-static data set can also include a limited use account parameter that has its own set of limited use thresholds and / or its own set of use restrictions. While in some embodiments an account identifier, such as a PAN, can be used and stored on the portable communication device, the PAN can be valid for the life of the account and can be used for a wide variety of different types of transactions (e.g., card present transactions, online transactions, etc.). As such, to further enhance the security of the portable communication device and reduce the impact of a breach of an account parameter, in some embodiments, instead of using a PAN and storing it on the portable communication device, an alternative account identifier (e.g., an alternative PAN) or a token that is a substitute for an account identifier can be used.

[0065] An account can have one or more account identifiers and / or tokens associated with the account. Each alternative account identifier or token can be limited to a type of transaction in which the alternative account identifier or token is used. For example, an account can 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 will reject an online transaction using the cloud-based token. Other types of user restrictions can include restrictions on what type of merchant or what merchants and / or what geographic locations can use the alternative account identifier.

[0066] The alternative account identifiers and tokens can also have their own set of limited use thresholds (e.g., time to live, number of transactions, and / or cumulative transaction amount, etc.). In some embodiments, the limited use thresholds for an alternative account identifier or token can have higher usage limits than those of the dynamic data set (e.g., LUKs), such that replenishment of the alternative account identifier or token occurs less frequently. For example, an alternative account identifier or token can have a time to live of one year, while the time to live for a LUK can be five days. As another example, an alternative account identifier or token can be valid for up to two thousand transactions, while a LUK can be valid for up to five transactions. It should be understood that in some embodiments, the usage limits for an alternative account identifier or token can also be set the same as those of the dynamic data set (e.g., LUKs), such that replenishment of the alternative account identifier or token occurs at the same time as the dynamic data set.

[0067] II. Overview of Cloud-Based Transaction System

[0068] In a cloud-based transaction system, the issuer of an account can configure service portfolio features to define risk parameters and, therefore, use- limited threshold values for account parameters of accounts belonging to a specific portfolio. The use-limited threshold values can be used to manage triggers for refreshing or replenishing account parameters on a portable communication device. To ensure that cloud-based transactions are processed according to the risk parameters specified in the service profile of the account, several core functions are implemented in the system to manage the deployment and use of account parameters. These functions can include configuring active account management, payment verification, transaction processing, life cycle management, and post-payment processing.

[0069] Configuration can entail considering the enrolled account, creating account parameters (such as identifiers) to identify the enrolled account for cloud-based transactions (e.g., alternative account identifiers, such as alternative PANs or tokens), and an initial dynamic dataset to ensure that account parameters have limited use only after being transferred to a portable communication device, and inheriting the service profile (e.g., use-limited threshold values) that has been established for the portfolio to which the enrolled account belongs. Depending on the types of transactions supported, the dynamic dataset can include LUKs and / or other dynamic data, such as key indices. The portable communication device uses, for example, LUKs to compute transaction cryptograms or use-limited dynamic data, such as verification values, to support legacy transactions that use verification values (e.g., dynamic card verification values (dCVVs)) during a transaction.

[0070] After an account is configured to a portable communication device, the relevant service profile details (e.g., use-limited threshold values) can be shared between transaction processing software and entities in the system to ensure that transaction authorization decisions are made correctly. In addition, the service profile details (e.g., use-limited threshold values) can be provided to the device-based cloud transaction software installed in the mobile application of the portable communication device, thereby ensuring that account parameters are properly managed on the portable communication device. As discussed above, different use limitations for triggering account parameter replenishment can be set at different entities in the cloud-based transaction system, and, therefore, the service profile can define different use limitation settings for each use-limited threshold value at different entities that can initiate account parameter replenishment (e.g., portable communication device, cloud-based service provider, issuer, etc.).

[0071] After configuration, the cloud-based transaction system can perform active account management to initiate refresh or replenishment of account parameters. The active account management process can be triggered by transaction processing activity or initiated by the mobile application running on the portable communication device. If the service profile parameters for a particular account indicate that the account parameters on the device should be replaced (e.g., have exhausted their usage limits), the active account management capability recognizes this and attempts to connect to the portable communication device to replenish the account parameters. Additionally or alternatively, if the mobile application managed service profile on the device indicates that account parameter replenishment is needed or will be needed, the mobile application can request account parameter replenishment.

[0072] To provide authentication for payments, the cloud-based transaction system also has the capability to provide on-device authentication functionality to the payment processing network prior to or during a transaction to provide some level of authentication that the correct user of the portable communication device initiated and intended the transaction. The on-device authentication can include cardholder verification methods (CVMs) that can be used as payment authentication for the configured account. As part of the service profile for the portfolio, specific rules for what can be used as a CVM (e.g., screen lock, application password) can be established and shared between the configuration capability, the active account management capability, and the transaction processing capability.

[0073] After an account is configured, the transaction processing capability of the system can provide awareness of ongoing transactions being performed using the cloud-based account. When a cloud-based account is identified, the transaction processing capability of the cloud-based account can ensure authentication, apply service portfolio parameters (e.g., spend limit thresholds), and communicate them to the issuer in the transaction processing messages. This capability also ensures that any necessary active account management actions are initiated. For example, if the account identification information corresponds to a range of account identifiers (e.g., PAN range) that are dedicated to cloud-based transactions, or if the account identification information corresponds to an alternate PAN or token that is only used for cloud-based transactions, the provided account identification information during the transaction can be used to identify the account as a cloud-based account.

[0074] After an account has been configured for cloud-based transactions, a lifecycle management function can allow a user or issuer to manage the lifecycle of the configured account. Lifecycle management events, such as a freeze or deletion of the account, can be initiated by the consumer. For example, a report by the consumer that the portable communication device and / or associated card is lost or stolen can trigger a freeze and / or deletion of the account from the portable communication device, or the user can choose to remove the configured account from the portable communication device. Lifecycle management events can also be initiated by the issuer, for example, based on risk management or account replenishment activities. In some embodiments, other parties that can be involved in processing cloud-based transactions or managing cloud-based accounts, including merchant or multi-issuer mobile wallet providers, can also initiate lifecycle actions.

[0075] Figure 1 A cloud-based transaction system 100 according to some embodiments is illustrated. Core components of the system 100 can include a cloud-based payment platform (CBPP) 180 and a mobile application platform (MAP) 170 to manage cloud-based transactions conducted using a portable communication device 101. The CBPP 180 can be referred to as a remote computer and can be implemented using one or more computing devices or computers, such as one or more server computers, and can be associated with or operated by a cloud-based service provider, such as an issuer, payment processor, payment processor, and / or other suitable entity. The CBPP 180 can manage cloud-based accounts, provide authentication functionality for cloud-based transactions, manage lifecycle messages from an issuer / host system 172 or MAP 170, and initiate lifecycle management events. The CBPP 180 can also help an issuer / host system 172 with post-payment functionality to mitigate risks that prevent counterfeit account parameters and limit exposure of account parameters stored on the device. For example, the CBPP 180 can be used to facilitate an issuer / host system 172 requesting periodic post-payment verification of payment transactions and / or account parameter replenishment requests using post-payment information.

[0076] The CBPP 180 can also implement a set of key management functions that manage issuer-led derivation of a master derivation key (MDK) from which a limited use key (LUK) for cloud-based transactions is derived. The CBPP 180 can implement a set of provisioning functions that manage preparation and delivery of cloud-based account parameters (e.g., alternative account identifiers or tokens, initial LUKs and associated key indices, etc.) to the MAP 170 for initial setup of a mobile application 112 on a portable communication device 110. The CBPP 180 can also manage cloud-based accounts for processing by an issuer / host system 172 and can perform active account management functions, such as generating account parameters for a risk profile based on a request or risk management parameters for each CBPP 180-based account. The CBPP 180 can also maintain account status for each cloud-based account and manage replenishment or refresh of account parameters.

[0077] In some embodiments, CBPP 180 can also implement or be provided access to a token service 182 and / or a token vault 184. Token service 182 can be used to generate, process, and maintain tokens that are substitute identifiers for account identifiers. During a transaction, instead of using an actual account identifier (e.g., a primary account number (PAN)) to identify a user's account, a token can be used to identify the account. By using a token as a substitute for an account identifier, risks including actual account information can be mitigated. As indicated above, a token can have a set of its own usage restrictions, and token service 182 can manage the deployment and use of tokens according to the usage restrictions of the tokens. Token service 182 can communicate with a token vault 184 that stores the generated tokens. Specifically, token vault 184 can maintain a mapping between a token and an actual account identifier (e.g., a PAN) that the token represents. During transaction processing, token vault 184 can be queried to retrieve the actual account identifier or PAN associated with a token.

[0078] MAP 170 is used to facilitate communications between mobile application 112 executing on portable communication device 101 and other entities in cloud-based transaction system 100, such as CBPP 180 and / or issuer / host system 172, among others. MAP 170 can communicate with portable communication device 101 via a communication network 192, such as the Internet. In some environments, portable communication device 101 can not always have constant network connectivity, and thus one of the primary roles of MAP 170 is to act as a broker for requests between mobile application 112 and other entities in cloud-based transaction system 100 to ensure that requests and responses involving mobile application 112 are satisfied as soon as network connectivity to portable communication device 101 is established. MAP 170 can be referred to as a remote computer and can be implemented using one or more computing devices or computers, such as one or more server computers, and can be associated with or operated by a provider of mobile application 112. The provider of mobile application 112 can be, for example, an issuer, a bank, a third-party mobile wallet provider, a merchant, or other suitable entity. In some embodiments, MAP 170 can be associated with or operated by the same entity as CBPP 180, or they can be separate. Although MAP 170 is shown as a separate logical entity in FIG. 1, it should be understood that in some embodiments, some or all of the functionality of MAP 170 can be integrated as part of CBPP 180. Examples of MAP 170 can include a mobile banking platform and a mobile wallet platform. Figure 1 Although MAP 170 is shown as a separate logical entity in FIG. 1, it should be understood that in some embodiments, some or all of the functionality of MAP 170 can be integrated as part of CBPP 180. Examples of MAP 170 can include a mobile banking platform and a mobile wallet platform.

[0079] In some embodiments, the MAP 170 can implement authentication functions to authenticate the portable communication device 101 when the portable communication device 101 communicates with the cloud-based transaction system 100 via the MAP 170. These authentication functions can ensure that the portable communication device communicating with the system is an authorized portable communication device and / or that the portable communication device has not been compromised or infected by malware or viruses or otherwise been compromised. For example, the MAP 170 can perform, request, or facilitate a device fingerprint of the portable communication device 101 that captures a state of the portable communication device 101 when the portable communication device 101 communicates with the MAP 170. The device fingerprint may, for example, capture information about the portable communication device 101 such as the operating system and version, applications installed on the portable communication device 101, memory usage, whether the portable communication device 101 has been jailbroken, a device identifier such as a portable communication device identifier, and / or other suitable device characteristics.

[0080] The MAP 170 can verify the device fingerprint of the portable communication device 101 for each communication session established with the portable communication device 101 (e.g., once every five communication sessions, once a month, etc.). If the device fingerprint of the portable communication device indicates that the portable communication device is not an authorized device for the account (e.g., the portable communication device requesting a replenishment of account parameters is a different device than the original device used to enroll the account), or if the device fingerprint indicates that the portable communication device can be potentially compromised, the MAP 170 can prevent the portable communication device from communicating with the system and alert the issuer that the portable communication device can have been compromised.

[0081] The MAP 170 can perform enrollment functions to enroll a mobile cardholder into the cloud-based transaction program and perform a set of provisioning functions that facilitate the preparation and delivery of account parameters, configurations, and cloud-based payment device threshold parameters to the mobile application 112. The MAP 170 can perform account parameter replenishment functions to facilitate account parameter replenishment processes for the cloud-based account configured on the portable communication device 101 and perform lifecycle management functions that manage lifecycle messages from the issuer / host system 172, the CBPP 180, and / or the mobile application 112. The MAP 170 can also perform post-payment functions to mitigate the risk of counterfeit account parameters and limit the exposure of account parameters stored on the portable communication device 101, such as periodic post-payment verifications or post-payment information for validating account parameter replenishment requests that facilitate payment transactions.

[0082] In the cloud-based transaction system 100, the portable communication device 101 can be used to conduct cloud-based transactions facilitated by the CBPP 180 and / or the MAP 170. Components in the portable communication device 101 can include a device hardware 103, a mobile operating system (OS) 114, and an application environment 110 in which a mobile application 112 can reside. The device hardware 104 can include a contactless interface 108 that can interact with a contactless reader 162 of an access device 160. Examples of the contactless interface 108 can include one or more radio frequency (RF) transceivers that can transmit and receive communications using near field communication (NFC), or other radio frequency or wireless communication protocols such as Bluetooth, Bluetooth Low Energy (BLE), Wi-Fi, iBeacon, etc. In some embodiments, the contactless interface 108 can include an optical interface (e.g., a display screen) for presenting payment information to the contactless reader 162 of the access device 160 in the form of an image (e.g., a quick response (QR) code, or a barcode, etc.) when the contactless reader 162 includes an optical code scanner or reader.

[0083] The application environment 110 of the portable communication device 101 can host the mobile application 112 provided by a mobile application provider. For example, if the provider of the mobile application 112 is an issuer, the mobile application 112 can be a mobile banking application or a separate mobile payment application. If the provider is a mobile wallet provider that supports multiple issuers, such as a mobile network operator or a third party wallet provider, the mobile application 112 can be a mobile wallet application. For a merchant, the mobile application 112 can be the merchant’s own mobile application from which a consumer can conduct e-commerce or point-of-sale transactions with that merchant, or can be a mobile wallet application that supports multiple merchants.

[0084] According to some embodiments, the mobile application 112 can include a device- on-cloud transaction software 113 (e.g., can be in the form of a software developer kit (SDK)) integrated into the mobile application 112 to support cloud-based transaction functionality. The device-on-cloud transaction software 113 can perform a variety of functions to facilitate cloud-based transactions, such as employing account parameters (e.g., LUKs and associated key indices), generating transaction cryptograms, and delivering them to the mobile operating system 114 for transmission through the contactless interface 108. The device-on-cloud transaction software 113 can also manage initial service profile parameters (e.g., purpose restricted threshold values) provided after an account has been configured to ensure that requests to supplement account parameters and other account parameter management activities are initiated.

[0085] The mobile application 112 can perform a variety of functions to manage risk profiles for cloud-based accounts, maintain account states, and supplement account parameters for each cloud-based account based on device- on-threshold management parameters. The mobile application 112 can also manage lifecycle messages from the issuer / host system 172 or from the MAP 170. The mobile application 112 can perform a set of functions to enroll the mobile cardholder into the cloud-based transaction program and perform a set of functions to manage the receipt and configuration of cloud-based account parameters and cloud-based payment device threshold parameters received from the MAP 170. The mobile application 122 can also provide consumer device cardholder verification method (CDCVM) functionality for cloud-based transactions and perform a set of functions to process and respond to messages that support post payment processing to limit exposure of account parameters stored on the portable communication device. For example, post payment processing can include periodic post payment verification of payment transactions or validation of account parameter supplement requests using post payment information.

[0086] In a secure element-based implementation, a contactless application (e.g., a mobile wallet or payment application for contactless transactions) that uses a contactless interface to communicate with a contactless reader of an access device will have to be encoded for and executed on a secure element in order to gain access to the contactless interface. In some embodiments, the portable communication device 101 can include a mobile operating system (OS) 114 that implements a set of card emulation application programming interfaces (APIs) 116, such as a host card emulation (HCE) API, to allow the mobile application 112 to gain access to the contactless interface 108 without requiring the use of a secure element. For example, the card emulation APIs 116 can be encoded for and executed from the mobile OS 114 of the portable communication device 101 and can include programmatic function calls to allow the mobile application 112 to receive, process, and respond to transaction communications, such as application protocol data unit (APDU) commands issued from the contactless reader 162. In this way, the portable communication device 101 is able to conduct contactless transactions without requiring access to a secure element on the portable communication device 101.

[0087] Once the account parameters have been configured for the portable communication device 101 and the mobile application 112, the portable communication device 101 can conduct a cloud-based transaction (e.g., at a merchant point-of-sale (POS) location) by interacting with a contactless reader 162 of an access device 160. The contactless reader 162 can include one or more RF transceivers that can transmit and receive communications using NFC or other radio frequency or wireless communication protocols (e.g., Bluetooth, BLE, Wi-Fi, iBeacon, etc.). In some embodiments, the contactless reader 162 can include an optical code scanner or reader for conducting transactions using QR codes, barcodes, and the like. The access device 160 can also include a POS acceptance device 164 and / or an electronic cash register 166.

[0088] To conduct a cloud-based transaction, a user of the portable communication device 101 can place the portable communication device 101 in proximity to the contactless reader 162 of the access device 160, or display an image (e.g., a QR code or barcode) on the screen of the portable communication device 101 for scanning by the contactless reader 162 of the access device 160. The portable communication device 101 can provide an identifier (e.g., an account identifier such as a PAN, an alternative account identifier such as an alternative PAN, or a token, etc.) to the access device 160 to identify the user's account and additional information such as the limited use account parameters or information derived from the limited use account parameters (e.g., a transaction cryptogram generated from a LUK). For example, in some embodiments, the account identifier or token, and the additional information (e.g., transaction cryptogram, account parameters, etc.) can be transmitted to the access device 160 in APDU responses in response to a series of APDU commands received from the access device 160. In some embodiments, the account identifier or token, and the additional information can be encoded with a QR code or barcode that is scanned and processed by the access device 160 to retrieve the encoded information. The access device 160 or a merchant computer coupled to the access device 160 can then generate an authorization request message including the account identifier or token, and the additional information (e.g., transaction cryptogram and other transaction data), and forward the authorization request message to an acquirer 174 associated with the merchant. The acquirer 174 can then send the authorization request message to a payment processing network 194.

[0089] The payment processing network 194 can include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, transaction processing services, and clearing and settlement services. An exemplary payment processing network can include VisaNet® TM The payment processing network (e.g., VisaNet® TM ) is able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet® TMSpecifically, the VIP system (Visa Integrated Payments System) that processes authorization requests and the Base II system that performs clearing and settlement services can be included.

[0090] Upon receipt of the authorization request message, the payment processing network 194 can forward the authorization request message received from the acquirer 174 to the respective issuer / host system 172 of the user of the portable communication device 101. Upon receipt of the authorization request message by the issuer / host system 172, the authorization request message can be parsed and the information in the authorization request message can be verified. For example, the issuer / host system 172 can verify a valid LUK-generated transaction cryptogram and that the set of one or more usage-restricted thresholds associated with the LUK have not been exceeded. 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 cryptogram, the payment processing network 194 or the issuer / host system 172 can forward the transaction cryptogram to the CBPP 180 for verification.

[0091] The authorization request message is then sent back to the payment processing network 194 to indicate whether or not the current transaction is authorized (or not authorized). The payment processing network 194 then forwards the authorization request message back to the acquirer 174. In some embodiments, the payment processing network 194 can decline the transaction even if the issuer / host system 172 has authorized the transaction based on the fraud risk score value or based on whether or not the CBPP 180 verified the usage-restricted account parameter. The acquirer 174 then sends the authorization request message to the merchant computer and / or the access device 160. An authorization response result, which can include transaction data for the transaction, can be displayed by the access device 160 or printed on a physical receipt.

[0092] At the end of the day, the payment processing network 194 can perform a clearing and settlement process. The clearing process is the process by which the acquirer exchanges financial details with the issuer to facilitate the posting to the user's payment account and the settlement of the user's location of settlement. It should be understood that any of the acquirer 174, the payment processing network 194, the issuer / host system 172, the CBPP 180, and / or the MAP 170 can be referred to as a remote computer and can include one or more computing devices, such as one or more computer or server computers capable of communicating with other entities in the system 100 and / or performing one or more of the functions described herein.

[0093] III. Enrollment and Configuration

[0094] Figure 2A communication flow diagram illustrating an example enrollment and configuration process according to some embodiments is shown. The enrollment and configuration process can be initiated from a portable communication device 201 that has a mobile application installed that is programmed with cloud-based transaction capabilities. The mobile application can be pre-installed on the portable communication device 201 during the manufacturing process or by a retailer, or by the user downloading the mobile application from an app store or from an issuer or cloud-based transaction service provider and installing the mobile application on the portable communication device 201. The user can launch the mobile application and initiate an enrollment request 222 from the mobile application to add an account to the cloud-based transaction service. The enrollment request 222 is sent from the portable communication device 201 to the MAP 270 and can include information that can be used to identify the user and the user's account, as well as device information about the portable communication device 201.

[0095] According to some embodiments, to facilitate communication with the portable communication device 201, the MAP 270 (or the issuer / host system 272, or the CBPP 280) can generate a device identifier from the device information or assign a device identifier to the portable communication device 201 during the enrollment and configuration process. The device identifier is provided to the mobile application on the portable communication device 201 and can be used by the mobile application to identify the portable communication device 201 to other entities in the cloud-based transaction system for subsequent interactions with the system.

[0096] When the MAP 270 receives the enrollment request 222, the MAP 270 can process the request, capture device information about the portable communication device 201, and route the enrollment request 224 with the relevant information to the issuer / host system 272. The issuer / host system 272 can perform identification and verification (ID&V) of the user account and send a configuration request 226 to the CBPP 280. The configuration request 226 can include account identification information, such as a PAN, for identifying the user account. In embodiments that use an alternative account identifier or token, the CBPP 280 or the issuer / host system 272 can generate the alternative account identifier, or call a token service to generate a token to be used as a substitute for the account identifier. Upon receiving the configuration request 226, the CBPP 280 can generate an initial account parameter set (e.g., a LUK) using a master derivation key (MDK) associated with the issuer / host system 272 for configuration to the portable communication device 201. In some embodiments, if the issuer / host system 272 can maintain or manage the MDK, the issuer / host system 272 can provide the MDK to the CBPP 180, or the issuer / host system can generate the LUK and provide the generated LUK to the CBPP 180. In either case, whether the LUK is generated by the CBPP 180 or by the issuer / host system 272, the LUK can be generated based on a key index that serves as a seed for the generation of the LUK, and the key index can be shared between the CBPP 180 and the issuer / host system 272 to facilitate processing of transactions that use the LUK.

[0097] The CBPP 280 then packages the configuration data 228, which can include the alternative account identifier or token, the initial account parameter set (e.g., the LUK) and the key index, and relevant other information for performing and / or processing transactions (e.g., a set of one or more spend limits associated with the LUK), and sends the configuration data 228 to the MAP 270. The MAP 270 can then send this information as configuration data 330 to the portable communication device 201. The mobile application then stores the account parameters and the relevant information on the portable communication device 201 to enable the portable communication device 201 for use in contactless transactions on the user account.

[0098] It should be noted that in some embodiments, different entities in the system (e.g., the portable communication device 201, the CBPP 280, and the issuer / host system 272) can be provided with usage limits for the set of one or more spend limits during the enrollment and configuration process, and the corresponding entity can trigger a subsequent account parameter replenishment under different usage limits.

[0099] Once the configuration data 330 has been successfully configured onto the portable communication device 201, the portable communication device 201 can send a confirmation notification or acknowledgement 332 to the MAP 270. The MAP 270 can also send an acknowledgement 334 to the CBPP 280, which in turn sends an acknowledgement 336 to the issuer / host system 272 to complete the enrollment and configuration process.

[0100] It should be understood that the above-described enrollment and configuration process is merely an example, and that the messaging sequence can have different variations in some embodiments. In some embodiments, the roles of the CBPP 280 and the issuer / host system 272 can be interchanged. For example, the CBPP 280 can receive the enrollment request 324 from the MAP 270 and send the configuration request 326 to the issuer / host system 372. As another example, the MAP 270 can send the acknowledgement 334 to the issuer / host system 272, and the issuer / host system can send the acknowledgement 336 to the CBPP 280.

[0101] IV. Transaction Execution

[0102] Once the portable communication device has been configured with the appropriate account parameters, the portable communication device can be used to perform a contactless transaction, for example, by placing the portable communication device in proximity to a contactless reader of an access device. Contactless transactions performed using the techniques described herein can be processed depending on the capabilities of the access device, either like a transaction using an integrated chip card (referred to as an "integrated chip-based transaction"), or like a transaction using a magnetic stripe card (referred to as a "magnetic stripe-based transaction"). In some embodiments, the contactless transaction time using the card emulation techniques described herein can be similar to that of a secure element-based implementation. For example, according to some embodiments, a contactless transaction using card emulation can take less than 500 milliseconds to complete.

[0103] In some embodiments, the performance of a contactless transaction using a portable communication device can be implemented by providing or exchanging messages (e.g., application protocol data unit (APDU) messages) between a mobile application running on the portable communication device and a contactless reader of an access device over a contactless medium (e.g., radio frequency waves). These messages can be in the form of APDU commands sent from the contactless reader to the portable communication device and APDU responses sent from the mobile application to the contactless reader in response to the APDU commands. To provide additional security, the mobile application can be configured to respond only 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 APDU commands that the mobile application does not recognize. In some embodiments, if 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 using a default status word.

[0104] In some embodiments, when the mobile application interacts with an external entity for which the mobile application can change its state or information it stores (e.g., a MAP, a CBPP, or an issuer / host server via a MAP, or a contactless reader of an access device), the mobile application processes the interaction atomically. In other words, the mobile application can process all or none of the functions required for the interaction. In this way, the mobile application can maintain a consistent state as seen from the external entity.

[0105] During installation of the mobile application, the mobile application can register its proximity payment system environment (PPSE) name and all of the application identifiers (AIDs) that the mobile application covers to ensure that transactions using those AIDs are routed to the mobile application (e.g., this can be accomplished by announcing to the mobile operating system in the manifest of the mobile application). For example, in some embodiments, the mobile application can be registered to receive APDU commands for one or more AIDs of a PPSE having a name such as "2PAY.SYS.DDF01."

[0106] In some embodiments, a mobile application can be registered to receive and process APDU commands for multiple AIDs (e.g., AIDs defined for a specific issuing bank, payment processor or processing network, service provider, etc.) and, in some scenarios, the multiple AIDs can be associated with a single account. A single account can have multiple AIDs associated with it, for example, if transactions conducted on that account can be processed by different payment processing networks and / or if the account can have different services, features, product types, and payment capabilities associated with the account. For example, a single account can have a common debit AID and a payment processing network specific AID (e.g., a Visa AID) associated with the single account. As another example, a single account can support different payment products and each payment product can have its own AID. The multiple AIDs can be conveyed to the access device to allow the access device to select a preferred AID to select how to process a transaction (e.g., which payment processing network) and / or what services or features are associated with or provided for the transaction. The multiple AIDs can be populated in the directory entry of the PPSE and conveyed to the access device for this purpose.

[0107] A mobile application on a portable communication device can receive, store, and / or support the generation of account related information to enable the mobile application to respond to a contactless reader and provide a cardholder with information about an account via a user interface of the portable communication device using the necessary information. Part or all of this information can be provided to the mobile application during an enrollment and configuration process. Account related information can include card art or other visual material that identifies the account to a consumer, account identification information that can identify the account to a user (e.g., an alias or last 4 digits of the account), a status of the account (e.g., active, frozen, etc.), account configuration information, transaction flow parameters (e.g., information provided to a contactless reader during a transaction process), a set of account parameters (e.g., LUKs and key indices) and their associated one or more usage limited thresholds and corresponding usage limitations, and a transaction verification log, etc. Account configuration information can include an AID of the account, which consumer verification method (CVM) (e.g., online PIN, consumer device CVM, signature, etc.) and its priority the account (or the corresponding AID if there are multiple AIDs) supports, whether the account supports magnetic stripe based transactions, and a derivation key index (DKI) associated with the issuer master key used in the process of verifying a transaction cryptogram. For a mobile application that supports multiple accounts that support the same or different account AIDs, the mobile application can also support the concept of which account is currently the active account and be able to populate responses to a contactless reader with data according to the currently active account.

[0108] The mobile application can also implement one or more counters to track transactional activity of the mobile application. For example, the mobile application can implement a sequential counter (SC) to count how many times the mobile application has successfully requested new account parameters for a particular account. The mobile application can also implement an application transaction counter (ATC) to count how many times the mobile application has been used to initiate a transaction.

[0109] During a transaction, the mobile application can receive, store, and / or dynamically build information, such as transaction flow parameters related to a contactless transaction, in order to return the necessary information to the contactless reader for a transaction to be successfully performed. Some of the transaction flow parameters can be received, stored, and / or built prior to initiating the contactless transaction, while some transaction flow parameters (e.g., transaction keys) can be dynamically built at the time of the transaction. For mobile applications that support multiple AIDs, each AID can store and / or generate different transaction flow parameters. Example details of the transaction flow parameters (e.g., including the transaction processing information and / or account data referenced below) and example details of the communication exchange between the mobile application and the contactless reader are described with respect to Figure 3 Example details of the transaction flow parameters (e.g., including the transaction processing information and / or account data referenced below) and example details of the communication exchange between the mobile application and the contactless reader are described with respect to Figure 4 Example details of the transaction flow parameters (e.g., including the transaction processing information and / or account data referenced below) and example details of the communication exchange between the mobile application and the contactless reader are described with respect to

[0110] Integrated chip-based transactions

[0111] Figure 3 An example communication flow between a portable communication device 301 and an access device 360 during an integrated chip-based transaction is illustrated in accordance with some embodiments. In some embodiments, these communications 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 conduct a transaction. These communications can be implemented between a mobile application running on the portable communication device 301 and a contactless reader of the access device 360. In some embodiments, the mobile application can communicate with the contactless reader using a card emulation API of the mobile operating system of the portable communication device 301, and thus the transaction can be implemented without the need to use a secure element (although a secure element can be used).

[0112] When the access device 360 detects the presence of the portable communication device 301 in the vicinity of the access device 360's contactless reader, the access device 360 can initiate a transaction by sending an available application request 302 to the portable communication device 301 to request information about which payment application(s) (e.g., a list of AIDs) are available on the mobile application of the portable communication device 301. In some embodiments, the available application request 302 can be in the form of a Select PPSE command. The available application request 302 can include a payment environment identifier (e.g., a PPSE name, such as "2PAY.SYS.DDF01") to identify the access device 360 and the payment environment supported by the mobile application.

[0113] When the available application request 302 is received, the mobile application of the portable communication device 301 can identify and process the request by recognizing the payment environment identifier (e.g., the PPSE name) included in the request, and respond by sending an available application response 304 back to the access device 360. The available application response 304 can include a list of available AIDs, and can include a payment environment identifier (e.g., a PPSE name), such as a dedicated file name. In some embodiments, the available application response 304 can be in the form of a Select PPSE Response and can include PPSE file control information (FCI). 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 AID. If the mobile application supports accounts with multiple AIDs, the mobile application can respond with a directory entry for each supported AID. Each directory entry can include information such as the AID, an application label associated with the AID (e.g., a mnemonic associated with the AID), an application priority indicator indicating the priority of the AID, a kernel identifier indicating the kernel preference of the application, and / or additional information related to the specific AID. The available application response 304 can also include other data, such as FCI issuer customizable data.

[0114] When the access device 360 receives the available application response 304, the access device 304 can select an appropriate application from the list of applications received in the available application response 304 (e.g., by selecting an AID from the available AIDs received in the available application response 304). In some embodiments, the selected AID can be the highest priority AID available on the mobile application that is supported by the access device 360. The access device 360 can send an application selection 306 to the mobile application of the portable communication device 301 with the selected AID to continue the transaction. In some embodiments, the application selection 306 can be in the form of a Select AID command.

[0115] When the application selection 306 is received, the mobile application of the portable communication device 301 can send a terminal transaction data request 308 to the access device 360 requesting transaction data that can be required to perform a transaction using the selected application / AID. In some embodiments, the terminal transaction data request 308 can be in the form of a select AID response and can include the selected AID as an AID file control information (FCI) of a dedicated file name. The terminal transaction data request 308 can include a list of transaction data identifiers to request appropriate data from the access device 360 and can include the list of transaction data identifiers in the form of a processing options data object list (PDOL). The transaction data requested by the mobile application for the transaction can include a terminal transaction qualifier (TTQ), an authorized amount, an additional amount, a terminal country code, a terminal verification result, a transaction currency code, transaction data, a transaction type, and / or an unpredictable number. The terminal transaction data request 308 can also include other data such as FCI issuer discretionary data, an application program identifier, and a language preference.

[0116] 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 can be sent in the form of a get processing options (GPO) and can include the requested terminal transaction data in a processing options data object list (PDOL). In some embodiments, the terminal transaction data 310 (e.g., a terminal transaction qualifier (TTQ)) can include a transaction type indicator indicating whether the access device 360 supports an integrated chip based transaction or a magnetic stripe based transaction. Accordingly, in some embodiments, the terminal transaction data 310 can be sent in the form of a get processing options (GPO) and can include the transaction type indicator in the processing options data object list (PDOL). Figure 3 In the illustrated integrated chip based transaction, the access device 360 can send a transaction type indicator in the terminal transaction data 310 indicating that the access device 360 supports an integrated chip based transaction. In some embodiments, the terminal transaction data 310 (e.g., a terminal transaction qualifier (TTQ)) can also include a CVM requirement indicator indicating whether the access device 360 requires a consumer verification method (CVM) for the transaction and can also include one or more CVM type indicators indicating the type of CVM supported by the access device 360. Examples of CVMs that can be supported by the access device 360 can include an online PIN, a signature, and / or a consumer device CVM (CDCVM) such as a password used on the portable communication device 301 to unlock a screen or a mobile application.

[0117] Once the mobile application of the portable communication device 301 receives the terminal transaction data 310, the mobile application can increment its application transaction counter (ATC), generate dynamic transaction processing information using at least some of the received terminal transaction data 310, and send a set of transaction processing information 312 including the generated dynamic transaction processing information to the access device 360. In some embodiments, the transaction processing information 312 can be sent in the form of a GPO response. In some embodiments, the transaction processing information 312 can include one or more application file locators (AFLs) that can be used by the access device 360 as file addresses to read account data on the portable communication device 301, and an application interchange profile (AIP) that can be used to indicate capabilities of the mobile application.

[0118] For integrated chip based transactions, the transaction processing information 312 can include a transaction cryptogram dynamically generated using the LUK, 2 track equivalent data, and additional data such as issuer application data (IAD), a form factor indicator (FFI), a card transaction qualifier (CTQ), cryptogram information data (CID), an updated ATC, and / or an application PAN sequence number (PSN). In some embodiments, the issuer application data (IAD) can include a length indicator indicating a length of the IAD, a cryptogram version number (CVN) indicating a version of the transaction cryptogram, a derived key indicator (DKI) that can be used to identify a master key (e.g., a master key associated with the issuer used in generating the LUK), a card verification result (CVR), a wallet provider ID, and / or derived data (e.g., a key index used in generating the LUK).

[0119] The card verification result (CVR) can include information about a CVM verification entity and a CVM verification type for the transaction. The CVM verification entity is used to indicate which entity performs verification of the CVM for the transaction. The verification entity can be the access device (or terminal), a co-resident secure application, a trusted execution environment application, the mobile application itself, a remote server or computer (e.g., a cloud), or a mobile operating system. The CVM verification type is used to indicate a CVM method used for the transaction. The CVM method can be a password, a biometric (e.g., a fingerprint), a pattern lock (e.g., a screen lock), a signature, or an online PIN. In some embodiments, if the terminal transaction data 310 received from the access device 360 indicates that the CVM supported by the access device 360 is an online PIN or a signature, the CVM verification entity in the CVR can be set to the access device (or terminal) to indicate that the access device 360 is the verification entity, and the CVM verification type can be set accordingly (e.g., online PIN or signature).

[0120] 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, the CVM verification entity and the CVM verification type can be set according to the configuration parameters of the account. For example, if the account supports CVMs using passwords verified by the mobile operating system of the portable communication device 301, the CVM verification entity can be set to the mobile operating system and the CVM verification type can be set to indicate that the CVM is a password. In some embodiments, an indicator of the CDCVM performed can be included in the card transaction qualifier (CTQ) to indicate whether the user using the CDCVM indicated by the CVM verification type has been successfully verified by the CVM verification entity.

[0121] If the terminal transaction data 310 received from the access device 360 indicates that no CVM is required, the CVM verification entity and the CVM verification type can be set to indicate that no CVM is verified. In some embodiments, the CVR can include additional data, such as a threshold indicator indicating whether one or more usage-restricted thresholds associated with the LUK have been exceeded.

[0122] The form factor indicator (FFI) can include information about the portable communication device 301, such as a form factor indicator indicating the version of the form factor indicator being used, a consumer payment device form factor indicator indicating the device type of the portable communication device 301, and a consumer payment device feature indicator indicating what payment features are supported by the portable communication device 301. The consumer payment device form factor can indicate that the portable communication device 301 is a standard card (e.g., an ID-1 card type specified by ISO 7811), a mini card, a non-card form factor (e.g., a key fob, a watch, a wristband, a ring, a sticker, etc.), or a mobile phone. The consumer payment device feature indicator can indicate whether the portable communication device 301 is capable of using a password (which can be separate from a PIN used during a transaction), whether it has a signature pad, whether it has a hologram, whether it supports a card verification value (e.g., CVV2), whether it is capable of two-way messaging to exchange identification information between the issuer and the user, and / or whether it supports the use of a cloud-based credential (e.g., LUK, token, etc.). The form factor indicator (FFI) can also include a payment transaction technology indicator indicating that the portable communication device 301 supports contactless transactions (e.g., NFC).

[0123] It should be appreciated that, in some embodiments, the transaction processing information 312 sent from the portable communication device 301 to the access device 360 can include some or all of the information described above, and in some embodiments, can include additional information not specifically described.

[0124] After receiving the transaction processing information 312 at the access device 360, the access device 360 can transmit an account data request 314 to the mobile application of the portable communication device 301 to read additional account data that can be stored on the portable communication device 301. In some embodiments, the account data request 314 can be in the form of a read record command and can include an application file locator (AFL) that indicates a location of the account data that the access device 360 is attempting to read. The AFL included in the account data request 314 can correspond to the AFL in the transaction processing information 312 provided from the portable communication device 301 to the access device 360.

[0125] After receiving the transaction processing information 312 at the access device 360, the access device 360 can transmit an account data request 314 to the mobile application of the portable communication device 301 to read additional account data that can be stored on the portable communication device 301. In some embodiments, the account data request 314 can be in the form of a read record command and can include an application file locator (AFL) that indicates a location of the account data that the access device 360 is attempting to read. The AFL included in the account data request 314 can correspond to the AFL in the transaction processing information 312 provided from the portable communication device 301 to the access device 360.

[0126] In response to receiving the account data request 314 from the access device 360, the portable communication device 301 can transmit account data 316 stored at the location indicated by the AFL to the access device 360. In some embodiments, the account data 316 can be transmitted in the form of a read record response. The account data 316 can include, for example, application usage controls that indicate the card issuer's restrictions on the usage and services allowed for the application, the cardholder's name, consumer exclusive data, the card issuer country code, a token requestor ID (e.g., if a token is used), and / or other account related data accessible at the AFL location.

[0127] It should be appreciated that in some embodiments, the account data 316 transmitted from the portable communication device 301 to the access device 360 can include some or all of the information described above, and in some embodiments, can include additional information not specifically described.

[0128] In some embodiments, more than one pair of account data request 314 and account data 316 communication exchanges between access device 360 and portable communication device 301 exist, for example, if access device 360 requires additional stored account-related data to complete the transaction. Once access device 360 has received the necessary data from the transaction processing information 312 and / or one or more account data 316 transmissions, some or all of the data elements in the transaction processing information 312 and / or one or more account data 316 transmissions can be used by access device 360 to generate a transaction authorization request message that requests the issuing bank to authorize the transaction. For example, in some embodiments, the transaction authorization request message can include at least the 2-track equivalent data and a transaction cryptogram generated using the LUK, and the transaction can be authorized based at least on verifying that the transaction cryptogram was correctly generated and that the LUK used in generating the transaction cryptogram has not exhausted a set of one or more usage-restricted thresholds for the LUK.

[0129] Magnetic stripe-based transactions

[0130] Figure 4 An example communication flow between portable communication device 401 and access device 460 during a magnetic stripe-based transaction is illustrated in accordance with some embodiments. In some embodiments, these communications 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 conduct a transaction. These communications can be implemented between a mobile application running on portable communication device 401 and a contactless reader of access device 460. In some embodiments, the mobile application can communicate with the contactless reader using a card emulation API of the mobile operating system of portable communication device 401, and thus the transaction can be implemented without the need to use a secure element (although a secure element can be used).

[0131] For magnetic stripe-based transactions, the available application request 402, available application response 404, application selection 406, and terminal transaction data request 408 communications and the relevant data elements included in these communications are similar to those described above with reference to Figure 3 Similarities in the described integrated chip card-based transactions, and thus a detailed description thereof need not be repeated.

[0132] In response to receiving the terminal transaction data request 408 from the mobile application of portable communication device 401, access device 460 can send the requested terminal transaction data 410 to portable communication device 401. For magnetic stripe-based transactions, the terminal transaction data 410 provided to portable communication device 401 is similar to that described above with reference to Figure 3Similar to the described integrated chip card based transaction, with the exception that the transaction type indicator (e.g., Terminal Transaction Qualifier (TTQ)) provided in the terminal transaction data 410 can indicate that the access device 360 supports magnetic stripe based transactions.

[0133] Once the mobile application of the portable communication device 401 receives the terminal transaction data 410 and determines that the access device 460 supports magnetic stripe based transactions, the mobile application can increment its application transaction counter (ATC) and send a set of transaction processing information 412 to the access device 360. In some embodiments, the transaction processing information 412 can be sent in the form of a GPO response. In some embodiments, the transaction processing information 412 can include one or more application file locators (AFL) that can be used by the access device 460 as file addresses to read account data on the portable communication device 401, and an application interchange file (AIP) that can be used to indicate the capabilities of the mobile application. In some embodiments, the one or more AFLs provided to the access device 460 during a magnetic stripe based transaction can be different than the AFLs provided during an integrated chip based transaction, such that the mobile application maintains different locations to store separate sets of data for use in magnetic stripe based transactions vs. integrated chip based transactions. The mobile application can also generate dynamic transaction processing information that can or can not use at least some of the data in the received terminal transaction data 410, and store the generated information at a location accessible by the one or more application file locators (AFL). The dynamic transaction processing information can include, for example, a transaction cryptogram generated using a LUK.

[0134] After the access device 460 receives the transaction processing information 412, the access device 460 can send an account data request 414 to the mobile application of the portable communication device 401 to read account data that can be stored on the portable communication device 301. In some embodiments, the account data request 414 can be in the form of a read record command, and can include an application file locator (AFL) that indicates the location of the account data that the access device 460 attempts to read. The AFL included in the account data request 414 can correspond to the AFL in the transaction processing information 412 provided to the access device 460 from the portable communication device 401.

[0135] In response to receiving the account data request 414 from the access device 460, the portable communication device 401 can transmit the account data 416 stored at the location indicated by the AFL to the access device 460. In some embodiments, the account data 416 can be transmitted in the form of a read record response. The account data 416 can include, for example, 2 track equivalent data and the cardholder name, among others. In some embodiments, for a magnetic stripe based transaction, a transaction cryptogram generated using the LUK and / or a key index associated with the LUK can be embedded in the 2 track equivalent data.

[0136] It should be appreciated that, in some embodiments, the account data 416 transmitted from the portable communication device 401 to the access device 460 can include some or all of the above-described information, and in some embodiments, can include additional information not specifically described.

[0137] In some embodiments, for example, if the access device 460 requires additional account related data stored to complete the transaction, there is more than one pair of account data request 414 and account data 416 communication exchanges between the access device 460 and the portable communication device 401. Once the access device 460 has received the necessary data from the transaction processing information 412 and / or one or more account data 416 transactions, some or all of the data elements in the transaction processing information 412 and / or one or more account data 416 transmissions can be used by the access device 460 to generate a transaction authorization request message requesting the issuing bank to authorize the transaction. For example, in some embodiments, the transaction authorization request message can include at least 2 track equivalent data and a transaction cryptogram generated using the LUK, and the transaction can be authorized based at least on verifying that the transaction cryptogram was correctly generated and that the LUK used in generating the transaction cryptogram has not exceeded a set of one or more usage limited thresholds.

[0138] 2 track equivalent data

[0139] According to some embodiments, different data elements can be included in the 2 track equivalent data provided from the mobile application of the portable communication device to the access device depending on the type of transaction being performed (e.g., a magnetic stripe based transaction or an integrated chip based transaction). Table 1 illustrates an example of a 2 track equivalent data format with an embedded transaction cryptogram that can be used in a magnetic stripe based transaction or an integrated chip based transaction.

[0140]

[0141] Table 1: 2 track equivalent data with embedded transaction cryptogram

[0142] The key index is associated with the LUK used in generating the transaction cryptogram for a particular transaction, and can include information related to the generation of the LUK as described herein. For example, the key index can be a seed used to generate the LUK, and can include time information (e.g., a timestamp) indicating when the LUK was generated, and / or can include a replenishment counter value indicating the number of times the LUK has been replaced or replenished for a particular account, mobile application, or portable communication device. In some embodiments, the cryptogram index can include an application transaction counter value of the number of transactions that have been conducted prior to the generation of the LUK by the mobile application of the portable communication device, or can include a pseudo-random number generated by the cloud-based transaction service provider or a suitable entity such as an issuing bank participating in the processing of the transaction.

[0143] The transaction cryptogram embedded in the 2-track equivalent data can be a cryptogram generated by using the LUK as an encryption key. In some embodiments, the transaction cryptogram embedded in the 2-track equivalent data can be different from the transaction cryptogram provided in the transaction processing information 312 (e.g., GPO response). For example, the transaction cryptogram embedded in the 2-track equivalent data (which can be referred to as a "decimal transaction cryptogram") can have a reduced length (e.g., reduced to six digits), and / or can be generated by encrypting static data (e.g., a predetermined number string) rather than terminal transaction data.

[0144] In some embodiments in which a transaction is conducted using an optical non-contact interface, an optical image such as a QR code or a bar code can be generated to encode the 2-track equivalent data format shown in Table 1, and the optical image encoding the 2-track equivalent data can be displayed on the portable communication device and presented to a light scanner of an access device for the transaction.

[0145] Table 2 shows an example of a 2-track equivalent data format without an embedded transaction cryptogram that can be used in an integrated chip-based transaction.

[0146]

[0147] Table 2: 2-track equivalent data without embedded transaction cryptogram

[0148] For integrated chip-based transactions, the transaction cryptogram is already provided to the access device in the transaction processing information 312 (e.g., GPO response), and thus it can not be necessary to include the transaction cryptogram in the 2-track equivalent data for integrated chip-based transactions. Thus, although the 2-track equivalent data format shown in Table 1 can also be used, the 2-track equivalent data shown in Table 2 can be used for integrated chip-based transactions.

[0149] In some embodiments, the key index associated with the LUK can be embedded in the 2 track custom data of the 2 track equivalent data format shown in Table 2. The key index can include, for example, time information and / or a supplemental counter value, an application transaction counter value, or a pseudo-random number, or any of the examples described herein. In some embodiments, the key index can act as a seed for generating a transaction cryptogram. By including the seed in the 2 track custom data passed to the card issuer, the card issuer can verify the seed and, in some embodiments, regenerate the transaction cryptogram using the seed to verify the transaction cryptogram.

[0150] It should be understood that the 2 track equivalent data format described above is an example, and in some embodiments, some data elements can be omitted from the 2 track equivalent data, and / or additional data elements not specifically shown can be included.

[0151] V. Transaction Verification Log

[0152] According to some embodiments, the mobile application can update the transaction verification log maintained by the mobile application at the end of a transaction to include information about the transaction in the transaction verification log. The mobile application can identify the end of a transaction by identifying that all transaction processing information and / or account data that the access device can need to complete the transaction has been provided to the access device (e.g., identifying that the last record defined in the AFL has been successfully returned, or no ALF when the GPO response has been successfully returned).

[0153] Figure 5 An example of data elements that can be included in a transaction verification log according to some embodiments is shown. The mobile application can maintain one transaction verification log per LUK or per account parameter set. In some embodiments, the portable communication device can maintain multiple transaction verification logs for several LUKs or account parameter sets, or optionally, once the current LUK or account parameter has been replaced or replenished, the transaction verification log corresponding to the previous LUK or account parameter can be deleted to save memory space on the portable communication device.

[0154] The transaction verification log can include a cryptographic index corresponding to the LUK or account parameter set used in the transactions logged, and a sequence counter value associated with the key index or account parameter set indicating the number of times the LUK or account parameter set has been replenished. For each transaction conducted using a particular LUK or a particular account parameter set, the transaction verification log can include a transaction timestamp indicating the time of the respective transaction, an unpredictable number (UN) provided from the access device during the transaction if available, an application transaction counter (ATC) value associated with the respective transaction (e.g., a value indicating the number of transactions that have been conducted using the mobile application at the time of the transaction), and a transaction type indicator indicating whether the respective transaction has been conducted as an integrated chip-based transaction or a magnetic stripe-based transaction. The transaction timestamp can be a UTC time determined by the portable communication device at the time of the transaction. In some embodiments, additional information such as the location of the portable communication device at the time of the respective transaction can be included in the transaction verification log. It will be appreciated that in some embodiments, the transaction verification log can include fewer data elements, and / or can include other data elements not expressly shown.

[0155] The transaction verification log can be used for various purposes, such as post-payment verification and account parameter replenishment. Figure 6 A communication flow diagram illustrating an example of a post-payment verification process according to some embodiments is shown. The issuer and / or host system 672 can initiate the post-payment verification process as an anti-fraud measure when the issuer and / or host system 672 decides to check an account, when a transaction flagged as suspicious or potentially fraudulent is received, or when the issuer and / or host system 672 randomly or periodically checks an account.

[0156] The issuer and / or host system 672 can initiate the post-payment verification process by sending a transaction log request 622 to the CBPP 680 requesting the transaction verification log associated with the account. The transaction log request 622 can include information such as an account identifier that can be used by the CBPP 680 to identify the account. The CBPP 680 can identify the account in question and the mobile application to which the account is registered, and forward this information to the MAP 670 as a transaction log request 624. The MAP 670 can identify and authenticate the portable communication device associated with the account and the mobile application, and send a transaction log request 626 to the identified mobile application of the portable communication device 601.

[0157] Upon receiving the transaction log request 626, the mobile application of the portable communication device 601 can retrieve the transaction verification log from the portable communication device's memory and package the data into transaction log information 628 for transmission to the issuer and / or host system 672. The transaction log information 628 is derived from the transaction verification log stored on the portable communication device and can include some or all of the information contained in the transaction verification log, such as per-transaction details for each transaction, such as a transaction timestamp, an application transaction counter value, a transaction type indicator, an unpredictable number (e.g., nonce), and / or any combination thereof; a key index associated with the LUK or account parameter used for the transaction; an order counter associated with the LUK or account parameter; and / or any combination thereof. Alternatively or in addition, the transaction log information derived from the transaction verification log can include an authentication code (e.g., a message authentication code, a hash value, etc.) computed from some or all of the information in the transaction verification log. For example, the authentication code can be computed from the per-transaction details, or from the key index and / or order counter together with the per-transaction details. In some embodiments, the authentication code can be generated by using the LUK as an encryption key.

[0158] After deriving the relevant transaction log information 628 from the transaction verification log, the mobile application on the portable communication device 601 sends the transaction log information 628 to the MAP 670. The MAP 670 forwards the information as transaction log information 630 to the CBPP 680, and the CBPP 680 forwards the information as transaction log information 632 to the issuer and / or host system 672. In some embodiments, the CBPP 680 can perform a verification of the received transaction log information, e.g., if the CBPP 680 tracks transaction activity for the account, and can in addition or alternatively provide a result of the verification in the transaction log information 632 transmitted to the issuer and / or host system 672.

[0159] Upon receiving the transaction log information 632, the issuer and / or host system 672 can compare the information to suspicious transactions, and / or compare the information to transaction activity for the current LUK or account parameter set. If the transaction log information 632 indicates that the mobile application of the portable communication device 601 performed a suspicious transaction and / or the transaction log information 632 matches transaction activity, the issuer and / or host system 672 completes the payment verification process and maintains the account in an active state.

[0160] If the transaction log information 632 indicates that the suspicious transaction did not originate from the mobile application of the portable communication device 601 or if the transaction log information 632 does not match transaction activity at the issuer, the issuer and / or the host system 672 can freeze the account and send a freeze notification to the CBPP 680. The CBPP 680 can freeze the account in its own system and send a freeze notification to the MAP 670. The MAP 670 then forwards the freeze notification to the mobile application of the portable communication device 601. In response to receiving the freeze notification, the mobile application can delete the current set of account parameters from the mobile application and display a message requesting the user to contact the issuer.

[0161] VI. Account Parameter Replenishment

[0162] When a set of account parameters (e.g., a LUK) expires because the age of the account parameters or the usage of the account parameters has exhausted a set of one or more usage limited thresholds associated with the set of account parameters, subsequent transactions using the expired set of account parameters can be denied. To enable continued use of the mobile application of the portable communication device for transactions, the mobile application can need to update, replace, refresh, or replenish the set of account parameters available to the mobile application. In some embodiments, the transaction verification log can also be used in the account parameter replenishment process to verify that the mobile application or portable communication device requesting the new set of account parameters is the same application or device that previously received and used the previous set of account parameters.

[0163] To facilitate the account parameter replenishment process, the mobile application of the portable communication device can track the usage of a set of account parameters (e.g., a LUK) and maintain an account parameter status indicating whether one or more usage limited thresholds associated with the set of account parameters or LUK have been or will be exhausted. For example, the mobile application can track how many transactions have been conducted using the set of account parameters or LUK, how much time has passed since the set of account parameters or LUK was generated, and / or a cumulative transaction amount within all transactions conducted using the set of account parameters or LUK. At the end of each transaction, the mobile application can update the usage of the set of account parameters or LUK tracked by the mobile application and compare the usage to the on-device set of one or more usage limited thresholds. In some embodiments, the mobile application can initiate an account parameter replenishment request if the mobile application determines that the usage of the current set of account parameters or LUK has exhausted the on-device set of one or more usage limited thresholds or exceeds the usage limit. In some embodiments, the mobile application can initiate an account parameter replenishment request if the mobile application determines that the next transaction conducted using the set of account parameters or LUK will exhaust the set of one or more usage limited thresholds. This can accomplish, for example, helping to ensure that the mobile application always has a valid set of account parameters or LUK so that the next transaction conducted using the mobile application is not denied.

[0164] Figure 7 A communication flow diagram illustrating an example of an account parameter replenishment process according to some embodiments is shown. In this example, the account parameter replenishment process is initiated by the mobile application of the portable communication device 701 and can be referred to as a replenishment-pull process. When the mobile application determines that the set of one or more usage-limited thresholds associated with the current account parameter set has been or will be exhausted, the mobile application of the portable communication device 701 can send an account parameter replenishment request 722 to the MAP 770 to replenish the account parameter set or LUK available to the mobile application. Figure 7

[0165] The account parameter replenishment request 722 can include information identifying the relevant account, mobile application, and / or portable communication device 701, and can include transaction log information derived from a transaction verification log stored on the portable communication device. The transaction log information provided in the account parameter replenishment request 722 can include some or all of the information contained in the transaction verification log, such as the per-transaction details (e.g., transaction timestamp, application transaction counter value, transaction type indicator, unpredictable number (e.g., nonce), and / or any combination of the above) for each transaction conducted using the current account parameter set or LUK. The transaction log information can include the key index associated with the current account parameter set or LUK, and / or the sequence counter associated with the current account parameter set or LUK. Alternatively or in addition, the transaction log information derived from the transaction verification log and provided in the account parameter replenishment request 722 can include an authentication code (e.g., message authentication code, hash value, etc.) computed from some or all of the information in the transaction verification log. For example, the authentication code can be computed from the per-transaction details, or from the key index and / or sequence counter together with the per-transaction details. In some embodiments, the authentication code can be generated by using the LUK as an encryption key.

[0166] ​When the MAP 770 receives the account parameter replenishment request 722, the MAP 770 forwards the request as an account parameter replenishment request 724 to the CBPP 780. Upon receiving the account parameter replenishment request 724, the CBPP 780 can verify the transaction log information or request the issuer / host system 772 to verify the transaction log information. If the transaction log information matches the transaction activity at the CBPP 780 or the issuer / host system 772, the CBPP 780 can then generate a new set of account parameters (e.g., a new key index and a new LUK) to replenish the current set of account parameters at the mobile application. The CBPP 780 can send a replenishment notification 726 to the issuer / host system 772 to notify the issuer of the new set of account parameters replenished to the mobile application. In some embodiments, the replenishment notification 726 can include the new set of account parameters (e.g., the new key index and the new LUK) so that the issuer / host system 772 can perform its own update. The issuer / host system 772 can respond by sending a confirmation notification 728 to the CBPP 780.

[0167] After generating the new set of account parameters, the CBPP 780 can send the new set of account parameters 730 to the MAP 770. The new set of account parameters 730 can include the new key index, the new LUK, etc., and in some embodiments, a new set of one or more usage-limited thresholds associated with the account parameters or LUK that can have different usage limits than the previous thresholds. The MAP 770 then forwards the new set of account parameters 732 to the mobile application of the portable communication device 701.

[0168] When the mobile application of the portable communication device 701 receives the new set of account parameters (e.g., the new LUK and the new key index associated with the LUK), the mobile application deletes the previous set of account parameters and the associated transaction verification log details and usage tracking, and stores the new set of account parameters. If the new set of account parameters has different usage limits for the set of one or more usage-limited thresholds, the one or more usage-limited thresholds can be updated with the new usage limits. The mobile application also increments the sequence counter for each successful account parameter replenishment. Once the mobile application has updated the set of account parameters, the mobile application of the portable communication device 701 can send a confirmation 734 to the MAP 780, and the MAP 780 can forward this as a confirmation 736 to the CBPP 770 to confirm that the account parameter replenishment process was successful.

[0169] In some embodiments, the card issuer / host system 772 is responsible for generating account parameters, rather than sending a supplemental notification 726 to the card issuer / host system 772, the CBPP 780 can forward the account parameter supplemental request 724 to the card issuer / host system 772 and let the card issuer / host system 772 generate a new set of account parameters (e.g., a new key index and a new LUK). In such embodiments, the card issuer / host system 772 can provide the new set of account parameters to the CBPP 780 and / or to the MAP 770 for forwarding to the mobile application on the portable communication device 701.

[0170] According to some embodiments, the account parameter supplemental process can be initiated by the CBPP 770 and / or the card issuer / host system 772. An account parameter supplemental process that is not initiated by the mobile application can be referred to as a supplemental push process. For example, the account parameter supplemental process can be triggered by transaction activity monitored by the CBPP 770 and / or the card issuer / host system 772. In some embodiments, the CBPP 770 and / or the card issuer / host system 772 can maintain its own set of one or more usage limited thresholds, which can or can not have the same usage limitations as the on-device usage limited thresholds maintained at the mobile application. The CBPP 770 and / or the card issuer / host system 772 can track usage of the current set of account parameters (e.g., LUK).

[0171] When the CBPP 770 determines that the set of one or more usage limited thresholds associated with the current set of account parameters at the CBPP 770 has been or will be exhausted, the CBPP 770 can send a push message to the MAP 780 to request the mobile application to supplement its current set of account parameters. When the card issuer / host system 772 determines that the set of one or more usage limited thresholds associated with the current set of account parameters has been or will be exhausted, the card issuer / host system 772 can send a push message to the CBPP 770 and / or the MAP 780 to request the mobile application to supplement its current set of account parameters.

[0172] When a push message is received from the CBPP 770 or the issuer / host system 772 that supplements the account parameter set, the MAP 780 forwards the push message to the mobile application of the portable communication device 701. In some scenarios, the portable communication device 701 can be powered off or the mobile application can not be active at the portable communication device 701 when the CBPP 770 and / or the issuer / host system 772 initiates the replenishment process. In such scenarios, the MAP 780 can queue the push message for delivery to the mobile application at a later time and can periodically attempt to reach the mobile application until the MAP 780 establishes communication with the mobile application. When the mobile application receives the push message requesting replenishment of the mobile application of the portable communication device 701 account parameters (e.g., LUK and associated key index), in response, the mobile application of the portable communication device 701 can send an account parameter replenishment request to the MAP 780 with the relevant transaction log information. The replenishment process can continue in a similar manner as described above with reference to the replenishment push process. Figure 7 In some embodiments, the CBPP 770 and / or the issuer / host system 772 can generate new account parameter sets and provide them to the MAP 780 with the push message so that when communication with the mobile application is established, the MAP 780 can provide the new account parameter sets to the mobile application.

[0173] Although the above description of the account parameter replenishment process has been described with reference to replenishing LUKs and key indices associated with LUKs, it should be understood that the account parameter replenishment process can be used to, for example, replenish other account parameters or related information to replenish tokens used as a substitute for account identifiers. In some embodiments, tokens can be replenished concurrently with LUKs and key indices or separately from LUKs and key indices.

[0174] VII. Transaction Cryptograms

[0175] According to some embodiments, because a secure element need not be present to protect account credentials stored on the portable communication device, account parameters used to conduct cloud-based transactions can have a limited lifetime of use so that even if a given account parameter set is compromised, the stolen account parameters will have little use because they can have already expired or will expire soon. For example, instead of using a static key stored in a secure element to generate a cryptogram during a transaction as used in some secure element implementations, the cloud-based transaction system uses a limited use key to generate a transaction key.

[0176] In some embodiments, two types of transaction cryptograms can be used - one type of transaction cryptogram for 2-track data used in magnetic stripe based transactions, and one type of transaction cryptogram for integrated chip based transactions. For both types of transaction cryptograms, the transaction cryptogram is generated using a limited use key (LUK). The difference between the two types of transaction cryptograms is the input data used to generate the cryptogram and / or the final format of the transaction cryptogram transmitted to the access device for the transaction. For integrated chip based transactions, the input data used to generate the cryptogram can include dynamic data (e.g., data that changes for each transaction) received from the access device's contactless reader during the transaction (e.g., terminal transaction data), while the input data for magnetic stripe based transactions can be static data (e.g., data that does not change from one transaction to another, such as a predetermined string of numbers). This means that in some embodiments, for magnetic stripe based transactions, the CBPP or mobile application itself can generate the transaction cryptogram since the generation of the transaction cryptogram does not rely on data from the access device's contactless reader; and for integrated chip based transactions, the mobile application provides the generation of the transaction cryptogram.

[0177] It should also be noted that in some embodiments, the input used to generate the transaction cryptogram in magnetic stripe based transactions can alternatively or additionally include dynamic data (e.g., terminal transaction data) received from the access device's contactless reader during the transaction. Additionally, the input used to generate the transaction cryptogram in integrated chip based transactions can alternatively or additionally include static data.

[0178] In addition to use for the generation of transaction cryptograms, in some embodiments, the LUK can be used to generate authentication codes when the mobile application communicates with other components or entities of the cloud based transaction system. For example, in an account parameter replenishment process, the LUK can be used as a key to generate an authentication code or hash code from transaction verification log details.

[0179] Figure 8 A block diagram illustrating an example of a process 800 for generating a transaction key in accordance with some embodiments is shown. Any of the encryption functions 806, 812, 818, and / or 824 can be the same as or different from any of the other encryption functions. For example, any of the encryption functions 806, 812, 818, and / or 824 can be implemented in accordance with triple data encryption standard (TDES), data encryption standard (DES), advanced encryption standard (AES), or other suitable encryption algorithm.

[0180] The process 800 can be divided into two parts - a first part related to the generation of the LUK (blocks 802-814) and a second part related to the generation of the transaction cryptogram (blocks 816-828). The first part related to the generation of the LUK can be performed once to generate the LUK (e.g., by the CBPP or the issuer and / or host system), and the second part related to the generation of the transaction cryptogram can be performed multiple times using the LUK generated from the first part (e.g., by the mobile application) until the LUK has exceeded a set of one or more usage limit thresholds, at which point, the first part related to the generation of the LUK can be performed again to replenish, replace, or refresh the LUK.

[0181] The process 800 can begin with the generation of a second encryption key 808 using an encryption function 806 to encrypt account information 804 with a first encryption key 802. The first encryption key 802 can be a base key associated with an issuer of the user account, and the base key can be associated with a set of accounts. For example, the first encryption key 802 can be associated with a set of accounts within a BIN or PAN range designated for a cloud-based transaction service. In some embodiments, the first encryption key 802 can be a master derivation key (MDK) associated with the issuer of the account associated with the account information 804, and the first encryption key 802 can be maintained at the CBPP or at the issuer / host system.

[0182] The account information 804 can include account identification information, such as an account identifier (e.g., a PAN), an alternative account identifier (e.g., an alternative PAN), or a token that is a substitute for an account identifier, and can in addition include user identification information, such as a serial number (e.g., a PAN serial number (PSN)) that identifies a specific user of the account (e.g., when multiple users use the same account). For example, the account information 804 used as 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.

[0183] In some embodiments, the second encryption key 808 generated from the account information 804 can include multiple portions each generated from a different permutation of the account information 804. For example, the second encryption key 808 can be split into two portions. A first portion of the second encryption key 808 can be generated by encrypting the account information 804 using the first encryption key 802. A second portion of the second encryption key 808 can be generated by reversing the account information 804 and encrypting the reversed account information using the first encryption key 802. The encryption function 806 used to generate the second encryption key 808 can be, for example, Triple Data Encryption Standard (TDES) or other suitable encryption algorithm, and can use an initial chaining vector of binary zeros. In some embodiments, the second encryption key 808 generated from the account information 804 can correspond to a unique derived key (UDK) for the account.

[0184] The process 800 can continue with the encryption function 812 using the second encryption key 808 to encrypt the key index information 810 to generate a limited use key (LUK) 814. The key index information 810 can be derived from a key index that includes information related to the generation of the LUK 814, and can be used as a seed to generate the LUK 814. For example, the key index can include time information indicating when the LUK 814 was generated. In some embodiments, the time information can be represented as the numeric string 'YHHHH', where 'Y' (0-9) represents the least significant digit of the current year and 'HHHH' (0001-8784) represents the number of hours since January 1 of the current year expressed as digits (e.g., the first hour of January 1 = 0001). In some embodiments, the key index can also include a refresh counter value indicating the number of times the LUK 814 has been refreshed or replenished within a predetermined time period (e.g., the number of times the LUK 814 has been generated within each hour). For example, the refresh counter value can be represented as the numeric string 'CC' (00-99). At the beginning of each hour, 'CC' starts at 00 and is incremented by 1 each time the LUK 814 is generated. In some embodiments, the key index can include an application transaction counter value, or a CBPP or issuer generated pseudo-random number.

[0185] 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 numeric values. For example, the key index can be padded with a numeric value (e.g., 1 or 2 shown as'm' or 'n' in Figure 8 and / or at the end of the key index (e.g., at the end of the hour). In some embodiments, the key index information 810 provided as input to the encryption function 812 can be generated by padding the key index with a numeric value (e.g., 1 or 2 shown as'm' or 'n' in Figure 880000000) that is displayed as 'xxxxxxxx'. In some embodiments, the LUK 814 generated from the key index information 810 can include multiple portions each generated from a different variation of the key index information 810. For example, the LUK 814 can be divided into two portions. A first portion of the LUK 814 (e.g., 1 YHHHHCC 80000000) can be generated by padding the key index with a first value and encrypting the first padded key index using the second encryption key 808. A second portion of the LUK 814 (e.g., 2 YHHHHCC 80000000) can be generated by padding the key index with a second value and encrypting the second padded key index using the second encryption key 808. The encryption function 812 used to generate the LUK 814 can be, for example, TDES or other suitable encryption algorithm, and can use an initial chaining vector of binary zeros. It should be understood that the numeric values described herein are examples only, and other numeric values can be used.

[0186] After the LUK 814 is generated (e.g., by the CBPP or the card issuer), the LUK 814 and the key index including information related to the generation of the LUK 814 can be provided to the portable communication device in order to facilitate generation of a transaction cryptogram for a transaction conducted using the portable communication device. The LUK can be associated with a set of one or more usage-limited thresholds (such as those described herein) that limit the number of transactions that can be conducted using the LUK 814. During transaction execution, the transaction cryptogram and / or the key index can be provided from the portable communication device to the access device, and the transaction can be authorized based on verification of the transaction cryptogram and whether the LUK 814 used to generate the transaction cryptogram has exceeded one or more of the usage-limited thresholds of the LUK.

[0187] As discussed above, in some embodiments, two types of transaction cryptograms can be generated. For magnetic stripe based transactions, the transaction cryptogram 828 can be a reduced length transaction cryptogram (may also be referred to as a decimal transaction cryptogram). The transaction cryptogram 828 can be generated by encrypting the static data 822 using the LUK 814 as an encryption key in an encryption function 824 to form an encrypted static data or encrypted numeric string expressed in hexadecimal (0-F) (e.g., can be a predetermined numeric string such as '0000000000000001'). The encryption function 824 can be, for example, TDES or other suitable encryption algorithm, and can use an initial chaining vector of binary zeros. The transaction cryptogram 828 can then be generated by converting the encrypted static data (or encrypted numeric string) to decimal using a decimal function 826.

[0188] In some embodiments, the transaction cryptogram 828 can be split into two data blocks. The decimal function 826 used to generate the two data blocks of the transaction cryptogram 828 can include forming a first data block by extracting numeric digits (0-9) from the encrypted static data or encrypted numeric string; and for a second data block, extracting hexadecimal digits (A-F) from the encrypted static data or encrypted numeric string, and converting each extracted hexadecimal digit into a numeric string by subtracting ten from the corresponding hexadecimal digit to form the second data block. The first data block is then concatenated with the second data block to form the transaction cryptogram 828. In some embodiments, the decimal transaction cryptogram 828 can have six digits, and can be embedded with a key index (e.g., 'YHHHHCC') in the 2-track equivalent data provided in the transaction authorization request message to request transaction authorization from the issuer.

[0189] For integrated chip-based transactions, the transaction cryptogram 820 can be generated by encrypting the dynamic transaction data 816 using the LUK 814 as an encryption key in the encryption function 818. The dynamic transaction data 816 can 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 performance of a transaction. In some embodiments, the dynamic transaction data 816 can include the following data elements: an authorized amount, an additional amount, a terminal country code, a terminal verification result, a transaction currency code, a transaction date, a transaction type, and / or an unpredictable number; and / or can include an application interchange profile (AIP), an application transaction counter (ATC), and issuer application data (IAD). In some embodiments, some data elements can be omitted, and / or additional data elements not specifically described can be included. The set of data comprising the dynamic transaction data 816 can be provided as input to the encryption function 818. In some embodiments, the transaction cryptogram 820 can be generated by encrypting the dynamic transaction data 816 using a first portion of the LUK 814, decrypting the encrypted dynamic transaction data using a second portion of the LUK 814, and then re-encrypting the decrypted dynamic transaction data using the first portion of the LUK 814.

[0190] It should be noted that, according to some embodiments, in addition to the transaction cryptogram 820, a decimal transaction cryptogram 828 can also be used and generated in integrated chip-based transactions, and the decimal transaction cryptogram 828 can be inserted in the 2-track equivalent data.

[0191] Figure 9A block diagram illustrating an example of an encryption function 900 according to some embodiments is shown. In some embodiments, encryption function 900 can be used as encryption function 818. For example, the datasets comprising dynamic transaction data 816 can be concatenated together (e.g., in the order described above) and then divided into a set of data blocks D1 to D2 of equal length. N (For example, an 8-byte data block). If the dynamic transaction data 816 is not divided into equal block lengths, then the final data block D... N Missing least significant bits can be filled with zeros. The first key KA can correspond to the first part of LUK 814 (e.g., the most significant 8 bytes), and the second key KB can correspond to the second part of LUK 814 (e.g., the least significant 8 bytes). An iterative encryption process can be applied to this group of data blocks D1 to D2. N The iterative encryption process may include encrypting the first data block D1 using the key KA as the encryption key in the data encryption algorithm (DEA(e)). The result of the encryption is then XORed with the next data block D2. The result of the XOR operation is then used as the input for the next iteration of the encryption process. The encryption process continues until all data blocks D1 through D2 have been processed. N And the output I of the final XOR operation on the last data block. N Encrypted to form the output O of the iterative encryption process N The key KB can then be used as the decryption key in the data decryption algorithm (DEA(d)) to decrypt the output O of the iterative encryption process. N Decrypt. Then, use the key KA as the encryption key in the data encryption algorithm (DEA(e)) to re-encrypt the output O of the decryption process. N+1 To generate output O N+2 According to some embodiments, the output is O. N+2 It can be used as the transaction password 820.

[0192] It should be noted that in some embodiments, reference is made to... Figure 9 The described encryption function 900 can be used, for example, to generate an authentication code used in post-payment verification and / or account parameter supplementation processes by applying the encryption function 900 at least within a transaction verification log stored on a portable communication device. In some embodiments, reference is made to... Figure 9 The described encryption function 900 can also be used for any of the encryption functions 806, 812, 818, and / or 824.

[0193] VIII. Exemplary Methods

[0194] Figure 10An exemplary flowchart illustrating a method 1000 for enhancing the security of a communication device (e.g., a portable communication device) when conducting transactions using the communication device is shown in accordance with some embodiments. The process 1000 can be performed, for example, by a mobile application executing on a portable communication device, and can be performed without the use of a secure element (although a secure element can be used in some embodiments).

[0195] At block 1002, the communication device can receive a limited use key (LUK) associated with a set of one or more limited use thresholds that limit the use of the LUK. The LUK can be received from a remote computer (e.g., a remote computer associated with a MAP, CBPP, or issuer / host system). In some embodiments, the set of one or more limited use thresholds can include at least one of a time to live indicating a duration for which the LUK is valid, and / or a predetermined number of transactions for which the LUK is valid, and / or a total transaction amount for which the LUK is valid. In some embodiments, the set of one or more limited use thresholds can include an international use threshold and a domestic use threshold.

[0196] According to some embodiments, the communication device can also receive the LUK and a key index including information related to the generation of the LUK. For example, the key index can include time information indicating when the LUK was generated, a replenishment counter value indicating a number of times the LUK has been replenished, a pseudo-random number used as a seed to generate the LUK, a transaction counter value indicating a number of transactions that have been conducted prior to the mobile application of the communication device at the time the LUK was generated, and / or any combination of the above.

[0197] At block 1004, a transaction (e.g., a payment transaction, an access transaction, or other transaction performed using an account) can be initiated, for example, by placing the communication device in proximity to a contactless reader of an access device (e.g., a POS terminal). At block 1006, the communication device can generate a transaction cryptogram using the LUK. At block 1008, the communication device can transmit the transaction cryptogram to the access device to conduct the transaction. In some embodiments, the communication device can also transmit a token (e.g., a substitute for the actual account identifier) to the access device in place of the actual account identifier to conduct the transaction. In some embodiments, the process 1000 does not store the token or the LUK in the communication device using a secure element. The transaction can be authorized based at least on whether the use of the LUK has exceeded the set of one or more limited use thresholds and / or a verification of the transaction cryptogram.

[0198] At block 1010, after conducting the transaction, the process 1000 can determine whether the set of one or more usage-limited thresholds associated with the LUK has been exhausted or exceeded (or will be exhausted or exceeded). If it is determined that the set of one or more usage-limited thresholds associated with the LUK has not been exhausted or exceeded (or will not be exhausted or exceeded), the process 1000 can continue to block 1004 to conduct another transaction.

[0199] If it is determined that the set of one or more usage-limited thresholds associated with the LUK has been exhausted or exceeded (or will not be exhausted or exceeded), at block 1012, the communication device can send a replenishment request for a new LUK to the remote computer. The replenishment request can be sent in response to determining that the set of one or more usage-limited thresholds associated with the LUK has been exhausted, or in response to determining that the next transaction conducted using the LUK will exhaust the set of one or more usage-limited thresholds. In some embodiments, the replenishment request can be sent in response to receiving a push message requesting that the communication device replenish the LUK.

[0200] The replenishment request can include transaction log information derived from a transaction log (e.g., a transaction verification log) stored on the communication device. In some embodiments, the transaction log stored on the communication device can include, for each transaction conducted using the LUK, a transaction timestamp indicating a time of the respective transaction, an application transaction counter value associated with the respective transaction, and / or a transaction type indicator indicating whether the respective transaction was a magnetic stripe-based transaction or an integrated chip-based transaction. In some embodiments, the transaction log information sent to the remote computer can include at least an authentication code computed using the LUK within the transaction log. If the transaction log information in the replenishment request matches transaction log information at the remote computer, the process 1000 can continue to block 1002, and the communication device can receive a new LUK and a new key index associated with the new LUK.

[0201] Figure 11 An exemplary flowchart illustrating a method 1100 for enhancing security of a communication device when conducting transactions using the communication device is shown in accordance with some embodiments. The process 1100 can be performed, for example, by a computer associated with a CBPP or an issuer.

[0202] At block 1102, an account information associated with an account is encrypted using a first encryption key to generate a second encryption key. In some embodiments, the account information can include an account identifier (e.g., a PAN), an alternative account identifier (e.g., an alternative PAN), or a token that is a substitute for an account identifier. In some embodiments, the first encryption key can be a master derivation key associated with an issuer of the account. According to some embodiments, encrypting the account information to generate the second encryption key can include encrypting the account information using the first encryption key to generate a first portion of the second encryption key, inverting the account information, and encrypting the inverted account information using the first encryption key to generate a second portion of the second encryption key. In some embodiments, the second encryption key can be a unique derivation key for the account.

[0203] At block 1104, a limited use key (LUK) is generated using the second encryption key encrypting key index information. The key index information can include a key index having information related to generation of the LUK. For example, the key index information can include a counter value indicating a number of times the LUK has been replaced or replenished within a predetermined time period and / or time information indicating when the LUK was generated. In some embodiments, encrypting the key index information to generate the LUK can include padding the key index with a first value to generate first padded key index information, and encrypting the first padded key index information to generate a first portion of the LUK. Encrypting the key index information to generate the LUK can also include padding the key index with a second value to generate second padded key index information, and encrypting the second padded key index information to generate a second portion of the LUK.

[0204] At block 1106, the process 1100 associates the LUK with one or more sets of limitations on use of the LUK. At block 1108, the LUK and the key index are provided to a communication device (e.g., a portable communication device) to facilitate generation of a transaction cryptogram for a transaction conducted using the communication device. The transaction can be authorized based on the LUK and the transaction cryptogram (e.g., whether use of the LUK has exceeded one or more sets of limited use thresholds and / or verification of the transaction cryptogram).

[0205] In some embodiments, when the transaction is an integrated chip based transaction, the transaction cryptogram can be generated by encrypting transaction information (e.g., dynamic transaction information, such as terminal transaction data received from an access device during the transaction) using the first portion of the LUK, decrypting the encrypted transaction information using the second portion of the LUK, and re-encrypting the decrypted transaction information using the first portion of the LUK.

[0206] When the transaction is a magnetic stripe based transaction, the transaction cryptogram can be generated by encrypting the predetermined numeric string using the LUK and converting the encrypted predetermined numeric string to decimal. In some embodiments, converting the encrypted predetermined numeric string to decimal can include extracting numeric digits from the encrypted predetermined numeric string to form a first data block, extracting hexadecimal digits from the encrypted predetermined numeric string and converting each extracted hexadecimal digit to a numeric string to form a second data block, and concatenating the first data block and the second data block to form the transaction cryptogram. The transaction cryptogram and / or the key index can be embedded in the 2-track equivalent data of the authorization request message.

[0207] IX. Cloud-Based Payment Platform (CBPP)

[0208] This section describes additional details of some of the functions that a cloud-based payment platform (CBPP) (e.g., CBPP 180) can perform. In some embodiments, these functions can include key management, active account management and account parameter replenishment, payment and payment transaction processing, payment validation, provisioning, lifecycle management, and post-payment validation. Communications between the CBPP and a mobile application platform (MAP) can be established using secure channels, such as those that comply with the Transport Layer Security (TLS) protocol, the Time-Limited Secure Socket Layer (SSL) protocol, or the Hypertext Transfer Protocol Secure (HTTPS) protocol. Communications between the CBPP and an issuer / host system can be established using secure channels that comply with the issuer's security requirements.

[0209] Key Management

[0210] An issuer of an account can use a dedicated key set (e.g., MDK) for each bank identification number (BIN) range or each primary account number (PAN) range for cloud-based payment transactions in order to avoid the same key being used for both secure element-based transactions and cloud-based transactions. The MDK can be used as a base key to generate the LUK that is provided to the portable communication device. In some embodiments, the CBPP can provide its own issuer MDK key set (specific to the cloud-based environment) that is stored in its own hardware security module. In some embodiments, instead of generating the LUK using its own MDK set, the CBPP can request the issuer / host system to retrieve the LUK that is stored in the hardware security module of the issuer / host system.

[0211] Active Account Management and Account Parameter Replenishment

[0212] The cloud-based payment techniques described herein do not require the use of a secure element to securely store data, such as a locally unique key (LUK). As such, the portable communication device can not have access to all capabilities associated with a secure element, such as the ability to generate an application cryptogram (AC) for a transaction using only securely stored information. To mitigate the risk of account parameters being compromised, the CBPP can periodically generate limited-use account parameters and replenish in the mobile application of the portable communication device and refresh in the issuer / host system to maintain the account in an active state.

[0213] For an active account management process to be initiated, the CBPP can receive a request from the MAP or the issuer / host system to generate account parameters. For example, in response to a request for an account parameter data update from the mobile application, the MAP can request a new set of account parameters (such as a limited-use key) and associated key index from the CBPP. As another example, the issuer / host system can check during transaction processing whether the current set of account parameters is still valid (e.g., within its limited-use threshold, such as the number of transactions allowed, time to live, etc.). If a given risk setting threshold is exceeded, the issuer / host system can alert the CBPP to update the mobile application with a new set of account parameters.

[0214] In response to the request, the CBPP can generate a set of account-related data. The set of account-related data can include semi-static account information and dynamic account parameters that change with each replenishment, such as a LUK that can be used by the mobile application to generate a transaction cryptogram (e.g., an application cryptogram (AC)) when the portable communication device is presented to a contactless reader of an access device. The account parameters can be account-specific (e.g., different account parameters for different user accounts), portable communication device-specific (e.g., different account parameters for different portable communication devices of a user, even when the underlying account is the same), and / or mobile application-specific (e.g., different account parameters for different mobile applications, even when the different mobile applications are within the same portable communication device).

[0215] The set of account-related data can also include risk management parameters (e.g., limited-use thresholds, such as the number of consecutive transactions allowed and time to live) that will indicate to the issuer / host system how transaction data should be used. The risk parameters can be account-specific (e.g., all cloud-based transactions using the account are combined for evaluation of the risk parameters), portable communication device-specific (e.g., all cloud-based transactions using a particular portable communication device are combined for evaluation of the risk parameters), mobile application-specific (e.g., all cloud-based transactions via a particular mobile application are combined for evaluation of the risk parameters), and / or account parameter-specific (e.g., each set of account parameters has its own set of risk parameters).

[0216] In some embodiments, the issuer / host system can implement its own set of risk limits or use- limited threshold values per account application to have a uniform view of all transactions performed on that account, as the same account can be configured in different mobile applications that can have their own risk limits, while all transactions performed by different mobile applications using that account can be authorized by the same issuer / host system. Risk management parameters can be predefined in both the mobile application and the issuer / host system, or can be managed separately by other systems such that the CBPP can not need to generate them. The account-related data set can also include device threshold management parameters for triggering updates of account parameters in the mobile application and for updating risk management parameters in the issuer / host system when possible.

[0217] The mobile application can store or receive from the cloud a number of risk management parameters (e.g., use-limited threshold values) that trigger an update to the current set of account parameters. When the account parameters approach the point in time at which they become outdated (e.g., when the next transaction performed using the LUK will exhaust a set of one or more use-limited threshold values), the mobile application can request an update from the CBPP via the MAP to replenish the account parameters. The device threshold management parameters monitored by the mobile application can include, for example, a number of transactions with a given set of account parameters that can be performed before the account parameters need to be updated (e.g., five transactions). The mobile application can send a warning to the mobile wallet platform before this limit is exceeded in order to allow the portable communication device for one or more transactions before they are declined (e.g., the warning can be sent after four transactions to allow the portable communication device for more than one transaction). Thus, if the account parameters are valid for a predetermined number of transactions within the CBPP risk management parameters, the number of transactions for the on-device threshold management parameters managed by the mobile application can be configured with a threshold value lower than the value in the CBPP to trigger replenishment.

[0218] The device threshold management parameters can also include a time-to-live for a given set of account parameters before they need to be updated (e.g., five days). The mobile application 114 can notify the mobile wallet platform before this limit is exhausted in order to request a new set of account parameters (e.g., after four days). Thus, if the account parameters time out in the CBPP, the time-to-live value for the device threshold management parameters managed by the mobile application before that specified time in the CBPP triggers replenishment can be configured with a threshold. In some embodiments, the device threshold management parameters can also include, but are not limited to: a transaction amount for which the mobile application makes a determination of whether the account parameters should be updated (e.g., smaller transaction amounts can not require immediate updating of the account parameters); a cumulative transaction amount that serves as a trigger for updating the account parameters based on a sum of individual transaction amounts; and / or a domestic vs. international risk setting in order to trigger updates more frequently for international transactions if international transactions are deemed to be higher risk.

[0219] Because the account parameters are expected to have limited use, the issuer / host system can implement and enforce additional risk management parameters specific to the cloud-based environment. These risk management parameters can be provided to the issuer / host system by the CBPP during the active account management process, or they can be defined and managed separately. For example, the issuer / host system can verify that a current set of account parameters (e.g., LUK and associated key index) can be used only a limited number of times (e.g., five times) before the issuer / host system raises a flag to request that the CBPP generate a new set of account parameters to be replenished in the mobile application. The issuer / host system can also check that the current set of account parameters can be used only for a limited period of time (e.g., five days) before a new set of account parameters needs to be generated by the CBPP and sent to the mobile application.

[0220] Additional risk management parameter checks such as individual transaction amounts and cumulative total transaction amounts can also be performed by the issuer / host system. For example, smaller transaction amounts can not require immediate updating of the account parameters, while high value transactions can require more frequent updating. As another example, when a cumulative total transaction amount based on a sum of individual transaction amounts is exceeded, the issuer / host system can notify the CBPP that a new set of account parameters needs to be generated and replenished in the mobile application. A domestic vs. international risk setting can also be checked in order to trigger updates more frequently for international transactions if international transactions are deemed to be higher risk.

[0221] Upon receiving a request from the MAP or the issuer / host system to update the account parameters, the CBPP can proceed with the generation of data for the given account. The CBPP can use its own set of issuer MDK keys (specific to the cloud-based environment), which it stores in its own hardware security module, and generate the LUKs derived from the MDKs using the newly generated key index, or the CBPP can retrieve the LUKs derived from the MDKs using the newly generated key index from the hardware security module of the issuer / host system.

[0222] After generating or otherwise retrieving the new set of account parameters, the CBPP can send the account parameters to the entity that has requested it. The MAP can receive the new set of account parameters and device threshold management parameters and further send it to the mobile application. In some embodiments, the set of risk parameters or use-restricted threshold values for a given account can change over time, and the new set of account parameters can have different threshold values than the previous set of account parameters. These threshold limits can change, for example, based on the spending habits of the consumer, or whether the consumer is traveling abroad. The issuer / host system can also receive the new set of account parameters from the CBPP. In some embodiments, the CBPP can be disconnected from the issuer / host system or can not be connected in real-time. In this case, the issuer / host system can use the timestamp in the authorization message to determine whether the data has been generated. Specifically, the key index can be generated to contain a date concept of when the account parameters were generated.

[0223] After the MAP and the issuer / host system receive the new account parameter set and the device threshold management parameters from the CBPP, they can perform certain actions. The MAP can deliver and apply the new account parameter set to the mobile application over the communication network. After the account parameter set is supplemented in the mobile application, the old account parameter set is discarded and can be deleted from the mobile application. If the MAP is unable to immediately communicate to the mobile application, it can keep trying to do so until it establishes its communication to the mobile application; otherwise, the issuer / host system can reject transactions performed using the old account parameter set from that point in time. In some embodiments, the MAP can receive confirmation from the mobile application that the account parameters have been updated in order to inform the issuer / host system to start using the new account parameter set. As soon as the issuer / host system gets the update, it can also update the risk management parameters of a given account parameter set. In case the issuer / host system receives the update from the CBPP directly in real time or with some delay, it can refresh the risk management parameters of the new account parameter set, for example, if the issuer / host system receives confirmation from the CBPP that the new data set has been successfully applied to the mobile application. In case the issuer / host system does not receive the update directly from the CBPP, the issuer / host system can receive the new account parameter set in the first transaction performed using the portable communication device after the update. After that moment, the processing authorization system can activate the new risk management parameters of the new account parameter set and apply different policies or discard the old account parameter set.

[0224] The issuer / host system can operate in synchronization with the CBPP and thus with the MAP to ensure that the transaction data processing process is synchronized with the account parameter generation process. The data generation system and the data host processing system can also use algorithms, timestamps, and other mechanisms to ensure that the data in the issuer / host system and the mobile application are consistent, up to date, and compliant with the same risk model.

[0225] Payment and payment transaction processing

[0226] When a payment transaction can be initiated at an access device and then processed by a processing authorization system, the mobile application and the issuer / host system can take additional actions to process the cloud-based transaction. When a payment transaction occurs and the portable communication device and the contactless reader exchange data, the mobile application can generate a transaction cryptogram (e.g., application cryptogram (AC)) using the LUK or and the key index associated with it stored in the mobile application. From the reader’s perspective, the transaction can appear as a regular contactless transaction. For integrated chip-based transactions, the access device can provide an unpredictable number (UN) for the generation of the transaction cryptogram. For magnetic stripe-based transactions, the transaction cryptogram can be generated by the mobile application without using input from the access device. In some embodiments, the dynamic card verification value (dCVV) can be omitted.

[0227] After the mobile application sends the transaction cryptogram and other transaction data to the access device, the mobile application can check whether the account parameters are still valid by checking the on-device threshold management parameters (e.g., on-device use-restricted threshold) on the device. The mobile application can alert the MAP when the on-device threshold management parameters are exceeded and request a new set of account parameters from the CBPP. The mobile application can check that even if the account parameters have not been updated in the mobile application, the old set of account parameters can still be used in subsequent transactions in order to let the issuer / host system authorize and make risk decisions.

[0228] After the interaction between the mobile application and the access device, the merchant and acquirer pass the transaction data to the issuer / host system. When the issuer / host system receives the transaction data in the authorization request message, the issuer / host system can validate the transaction cryptogram and other transaction data, convert the surrogate account identifier or token (e.g., actual PAN) assigned to the actual account identifier if needed, perform risk parameter checks, and verify that the account is in good standing. The issuer / host system can specifically verify that the data in the transaction cryptogram and key index are still valid for the given account by checking the risk management parameters. The CBPP can be alerted when the risk management parameters are exceeded and a new set of account parameters to be supplemented in the mobile application is requested from the CBPP via the MAP. The issuer / host system can verify that even if the account parameters have not been updated in the mobile application, the old set of account parameters can still be used in subsequent transactions if the issuer believes that such risk is acceptable for the given account, BIN or PAN range, or specific transaction environment (e.g., domestic vs. international).

[0229] Although it can have exceeded the account parameters from the issuer / host system perspective because the account parameters have not been updated in the mobile application, the issuer / host system can allow the transaction and provide a certain level of tolerance. If the account parameters have not been updated in the mobile application, the CBPP can be notified that the issuer / host system can start rejecting additional transactions. A threshold is set in the issuer / host system for each risk management parameter, as will the number of transactions and survival time that will allow the CBPP to be notified in advance before the actual risk management parameter is exceeded. This can give the CBPP additional time to generate a new set of account parameters and supplement the account parameters in the mobile application by the MAP.

[0230] Verification of payment

[0231] To conduct a transaction, the consumer can activate the portable communication device prior to presenting the portable communication device to the contactless reader in order to continue the transaction. In some embodiments, activation of the portable communication device can involve the consumer entering an input corresponding to a consumer device cardholder verification method (CDCVM) on a user interface of the portable communication device. Depending on the mobile application configuration, the CDCVM can be at the device level (e.g., screen lock) or at the mobile application level (e.g., application password / pin). The mobile application can be set to use the CDCVM for each transaction, or for each transaction greater than a certain transaction amount. If the mobile application is configured to use the CDCVM, the consumer can be prompted to enter an input corresponding to the CDCVM prior to or during the mobile payment transaction in order to authenticate. If the CDCVM is used for the transaction and the CDCVM is obtained prior to presenting the portable communication device to the contactless reader, the transaction can continue to completion. If the CDCVM is used for the transaction and the CDCVM is not obtained prior to presenting the portable communication device to the contactless reader, the transaction process can depend on the merchant access device version.

[0232] The CBPP can provide a set of functions in which the card issuer can set the CDCVM, and this CDCVM configuration information (e.g., screen lock, password, etc.) is configured onto the mobile application. The CBPP can support card issuer CDCVM requirements and allow the card issuer to configure the CDCVM data in the configuration data. In some embodiments, the card issuer / host system can determine whether to enter an input corresponding to the CDCVM. When the input corresponding to the CDCVM is captured by the device, the result can be passed to the card issuer / host system in the authorization message in order to process the transaction.

[0233] Configuration

[0234] CBPP can provide a set of provisioning functions that allow cloud-based account data to be sent to the MAP. CBPP can manage data for each cloud-based account and ensure that data is sent to the MAP whenever requested. CBPP can support provisioning functions in preparation of data sent to the MAP, and can support provisioning functions where the issuer can initiate a request to supplement or update cloud-based account data. CBPP can provide provisioning functions whereby each account holder provisions account parameter data to the MAP, and prepares and packages data before sending to the MAP. For example, CBPP can provide functions for provisioning semi-static data portions (e.g., account identifiers or tokens) and dynamic data portions (e.g., LUKs and key indices) to the MAP. CBPP can maintain a state machine per account and provide push or pull functions to / from the MAP in order to initiate provisioning / supplement requests. CBPP can provide supplement functions for each account holder to provision account parameter data to the MAP. CBPP can provide push features from the issuer for provisioning / supplement functions. CBPP can provide provisioning / supplement functions for a single account that can be supported by either the MAP or the issuer / host system. In some embodiments, CBPP can provide updated account parameters as part of a provisioning / supplement request, as long as invoked by the mobile application.

[0235] Life Cycle Management

[0236] Life cycle management is a set of functions that perform account life cycle events. CBPP can receive and process life cycle event messages from the MAP or from the issuer / host system. For some cases, life cycle requests can be initiated by the consumer, as in the case of deleting an account from the mobile application or blocking an account from the issuer outside of resolving fraud activity. CBPP 180 can perform life cycle management functions per account and provide account life cycle events such as adding, deleting, freezing, and unfreezing an account. In some embodiments, account life cycle events can include replacing or blocking an account, and / or managing a lost or stolen account. CBPP can provide an interface for the MAP and / or the issuer / host system to perform life cycle updates for a consumer account. A query can trigger provisioning or supplement of new account parameters. In some embodiments, CBPP can act on life cycle events such as deleting or freezing an account immediately under such a request. CBPP can provide notification of all life cycle events to affected systems such as the issuer / host system and the MAP.

[0237] Post-Payment Processing

[0238] Post payment verification can mitigate the risk of counterfeit account parameters. It can also reduce exposure of account parameters stored on the portable communication device, e.g., the portable communication device can perform periodic verification, which limits exposure associated with account parameters stored on the portable communication device. The CBPP can define a protocol to exchange post payment verification messages. The post payment verification protocol can be based on a real-time interface and can follow Transport Layer Security (TLS). The issuer / host system and / or the CBPP can trigger the post payment verification message exchange. The CBPP can provide options for the issuer to configure post payment verification parameters that trigger the post payment verification message exchange with the CBPP. For example, the issuer can configure the parameters such that the CBPP triggers post payment verification for transactions above a threshold (e.g., $100). The issuer can configure the parameters such that the CBPP triggers post payment verification upon each reissue of account parameters or after a number of reissues (e.g., after five reissues). In some embodiments, the issuer can configure the parameters such that the issuer / host system initiates post payment verification. In this case, the CBPP facilitates the message exchange between the issuer / host system and the mobile application.

[0239] In some embodiments, the CBPP can refrain from taking any action based on the verification result and can instead notify the issuer / host system of the suspicious activity. The issuer / host system can decide on the appropriate action based on its procedures and the risk profile of the account. The CBPP can support post payment processing handling using the transaction verification log to verify that the appropriate device made the payment. The CBPP can support post payment processing handling using the transaction verification log to verify that the appropriate device initiated the request for account parameter replenishment, e.g., by verifying that a given set of account parameters stored on the portable communication device matches a transaction at the issuer / host system. The CBPP can provide options to configure thresholds that trigger post payment verification messages from the CBPP. The CBPP can take lifecycle management actions based on the results of the post payment verification. If the verification fails, the CBPP can notify the issuer / host system of the suspicious activity. The CBPP can provide options to provide additional information in the transaction verification log, such as location information or a unique device identifier about the transaction.

[0240] X. Mobile Application Platform (MAP)

[0241] This section describes additional details of some of the functions that can be performed by a mobile application platform (MAP) (e.g., MAP 170). According to some embodiments, the MAP can manage the intermediate communication between the mobile application and the CBPP and the mobile application. The MAP can support cloud-based payment interactions such as entering a cloud-based payment service, configuring a cloud-based payment account, active account management (i.e., account parameter replenishment, account lifecycle management, and post payment transaction validation log requests). The MAP and CBPP can communicate using a secure transport channel such as time-limited SSL or HTTPS. The MAP and CBPP can exchange secure web service messages using web service security (WSS).

[0242] To communicate with the mobile application, the MAP can use single or multi-factor authentication to authenticate the user, the portable communication device, and / or the mobile application to establish a secure channel between the mobile application and the MAP. To support this, the MAP can establish an account for the consumer with a unique username and password. The password can be stored and verified by the MAP. The consumer can create their mobile application credentials (username / password) via an enrollment process. In some embodiments, this username and password can be different or the same as the portable communication device or CDCVM.

[0243] Enrollment and account configuration

[0244] The MAP can forward account and consumer enrollment data received from the mobile application to the CBPP or the issuer / host system in order to validate the enrollment request and perform issuer-defined identification and verification processes. The issuer can participate in the enrollment process (e.g., the issuer makes an accept / reject enrollment decision or delegates the decision to a third party under pre-defined conditions). In both cases, the issuer can control the criteria and precisely define the account verification method and the consumer authentication method. The MAP can support the acceptance of enrollment requests and associated enrollment data from the mobile application.

[0245] The MAP can route the enrollment request and associated data to the CBPP and / or the issuer / host system. When the enrollment is successful, the MAP can initiate a configuration request with the CBPP. If the CBPP configuration is successful, the MAP can receive data from the CBPP to configure the new cloud-based payment account in the mobile application. The MAP can receive a configuration confirmation or failure notification from the mobile application. The MAP can route the confirmation or failure notification from the mobile application to the CBPP and / or the issuer / host system. If the CBPP configuration is not successful, the MAP can receive an enrollment failure notification from the CBPP, and the MAP can route a configuration failure notification to the mobile application. The mobile application can display an appropriate message to the consumer.

[0246] Active account management

[0247] To mitigate the risk of leaking account parameters, the CBPP (or issuer / host system) can periodically generate account parameters and replenish them in the mobile application of the portable communication device and refresh them in the issuer / host system in order to maintain the account in an active state. To initiate the active account management process, the CBPP can receive a replenishment request for new account parameters from the mobile application via the MAP. The CBPP can also act on replenishment requests received from the issuer / host system. For active account management interactions, the MAP acts as a broker and routes communications to and from the mobile application and to and from the CBPP.

[0248] In a pull implementation, the MAP receives an account parameter replenishment request from the mobile application. Prior to initiating the exchange of messages from the mobile application, the MAP can establish a secure communication channel. Upon receiving the replenishment request, the MAP forwards the replenishment request message to the CBPP. After processing the replenishment request, the CBPP sends new account parameters to the MAP, which then forwards them to the mobile application. If necessary, the MAP can reestablish a secure connection with the mobile application. If the MAP does not successfully send an account parameter replenishment response from the CBPP to the mobile application after a predetermined number of attempts within a time window, the MAP can notify the CBPP that the account parameter replenishment delivery attempt was not successful.

[0249] In a push implementation, the CBPP (or issuer / host system) initiates the process to update account parameters. The CBPP sends a push message to the MAP to initiate a replenishment push. The MAP then sends the push message to the mobile application. The mobile application then generates an account parameter replenishment request at each of the above pull processes. Prior to initiating the exchange of sensitive messages, the MAP can perform user-level, portable communication device-level, and / or application-level authentication whenever security requirements dictate. If the MAP does not successfully send an account parameter replenishment response from the CBPP to the mobile application after a predetermined number of attempts within a specified time window, the MAP can notify the CBPP that the account parameter replenishment attempt was not successful.

[0250] When the mobile application receives and processes a new set of account parameters from either the push or pull implementation, the mobile application can generate a status or confirmation notification to the MAP, which then forwards the status or confirmation notification to the CBPP.

[0251] Life Cycle Management

[0252] When a consumer initiates account deletion, the MAP can facilitate the exchange of messages from the mobile application to the CBPP and issuer / host system. The MAP can delete account data associated with the account from its database and forward a deletion message from the mobile application to the CBPP.

[0253] When a consumer initiates an account deletion, the MAP can facilitate the exchange of a deletion message from the CBPP or the issuer / host system to the mobile application. The issuer / host system can send a deletion request to the CBPP or to the MAP. The MAP can forward the deletion message from the issuer / host system or the CBPP to the mobile application. After receiving a confirmation notification from the mobile application, the MAP can send the confirmation notification 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. The MAP can delete data associated with the deleted account from its records to ensure that the previously configured account of the specific consumer's mobile application profile is no longer an active cloud-based payment account.

[0254] When the issuer / host system or the CBPP initiates an account freeze, the MAP can facilitate the exchange of a freeze message from the CBPP or the issuer / host system to the mobile application. The issuer / host system can send a freeze request to the CBPP or to the MAP. The MAP can forward the freeze message from the issuer / host system or the CBPP to the mobile application. After receiving a confirmation notification from the mobile application, the MAP can send the confirmation notification to the CBPP or the issuer / host system. The MAP can ensure that the account freeze request is sent to the appropriate mobile application installed on the appropriate portable communication device.

[0255] When the issuer / host system or the CBPP initiates an account recovery, the MAP can facilitate the exchange of a recovery message from the CBPP or the issuer / host system to the mobile application. The issuer / host system can send a recovery request to the CBPP or to the MAP. The MAP can forward the recovery message from the issuer / host system or the CBPP to the mobile application. After receiving a confirmation notification from the mobile application, the MAP can send the confirmation notification to the CBPP or the issuer / host system. The MAP can ensure that the account recovery request is sent to the appropriate mobile application installed on the appropriate portable communication device.

[0256] Post-Payment Processing

[0257] Post-payment interactions can help card issuers mitigate the risk of account parameters being compromised and thus can help limit exposure of account parameters stored on portable communication devices. For purposes of ensuring the authenticity of account parameter replenishment requests, the MAP can support accepting information captured from a transaction verification log on the device (e.g., corresponding to a specific key index). A card issuer / host system working in conjunction with CBPP has the option to initiate a request through the MAP for transaction verification log data captured and stored by the mobile application. The mobile application can respond to the request with the requested transaction verification log data via the MAP. The card issuer / host system can then verify this data in order to confirm whether a specific transaction originated from the portable communication device being queried. Examples of data elements that can be used for this purpose for each transaction conducted using a set of account parameters can include the time of the transaction (e.g., the time of a contactless interaction), an application transaction counter (ATC) that counts the number of transactions conducted from the mobile application, the transaction amount, and / or the number of terminal unpredictable (UN) received from the access device during the transaction.

[0258] For purposes of using the transaction verification log to determine whether a transaction was conducted from a certain portable communication device, the MAP can receive a request for mobile application transaction verification log data from CBPP originating from the card issuer / host system. For purposes of using the transaction verification log to provide CBPP with a certain degree of assurance that a request originated from an appropriate portable communication device, the MAP can use information provided from the transaction verification log in an account parameter replenishment request from the mobile application. The MAP can identify and authenticate the portable communication device prior to transmitting or receiving post-payment interaction messages to and from the mobile application.

[0259] XI. Mobile Application

[0260] This section describes additional details of some of the functions that can be performed by a portable communication device and a mobile application installed on the portable communication device for conducting cloud-based transactions. Figure 12A detailed block diagram of a portable communication device 1201 is shown in accordance with some embodiments. The portable communication device 1201 can include a device hardware 1204 and a memory 1202. The device hardware 1204 can include a processor 1205, a communication subsystem 1209, a user interface 1206, a display 1207 (which can be part of the user interface 1206), and a contactless interface 1208. The processor 1205 can be implemented as one or more integrated circuits (e.g., one or more single-core or multi-core microprocessors and / or microcontrollers) and is used to control the operation of the portable communication device 1201. The processor 1205 can respond to program code or computer-readable code stored in the memory 1202 to perform various programs and can maintain a plurality of concurrently executing programs or processes. The communication subsystem 1209 can include one or more RF transceivers and / or connectors that can be used by the portable communication device 1201 to connect with external networks (e.g., the communication network 192) and communicate with other devices. The user interface 1206 can include any combination of input and output elements that allow a user to interact and invoke functionality of the portable communication device 1201. In some embodiments, the display 1207 can be part of the user interface 1206.

[0261] The contactless interface 1208 can include one or more RF transceivers for interacting with a contactless reader of an access device. In secure element-based implementations, only the secure element can access the contactless interface 1208. In the cloud-based payment techniques described herein, the contactless interface 1208 can be accessed by the mobile OS 1214 without the need for a user of a secure element. In some embodiments, the display 1207 can also be part of the contactless interface 1208 and used to perform transactions, for example, using QR codes, bar codes, and the like.

[0262] The memory 1202 can be implemented using any number of non-volatile memory (e.g., flash memory) and volatile memory (e.g., DRAM, SRAM), or any other non-transitory storage medium, or a combination of media of the same. The memory 202 can store a mobile OS 1214 and a mobile application environment 1210 in which one or more mobile applications can reside, including a mobile application 1212 (e.g., a mobile wallet application, a mobile payment application, and the like) to be executed by the processor 1205. The mobile OS 1214 can implement a set of card emulation APIs 1216 that can be called by the mobile application 1212 to access the contactless interface 208 for interacting with an access device.

[0263] For a cloud-based payment implementation, the payment system environment (e.g., PPSE) and mobile payment application functionality are combined into the mobile application 1212, while a secure element-based implementation can provide some or all of these functionalities from the secure element. The mobile application 1212 can include cloud-based payment logic 1250. The cloud-based payment logic 1250 can include contactless payment logic 1258, proximity payment system environment (PPSE) logic 1256, transaction verification log 1254, and account parameter thresholds 1252 (e.g., a set of one or more usage limited thresholds associated with the LUK 1242). The contactless payment logic 1258 can include functionality capable of conducting contactless communication to use a contactless transaction with a contactless reader of an access device. The PPSE logic 1256 is used to inform an access device which payment product on the mobile application 1212 is available. The access device then uses this information to select a payment account to initiate a contactless transaction. The transaction verification log 1254 can be used for post payment support. The mobile application 1212 can maintain the transaction verification log 1254 (which can be hidden from the consumer), retaining transaction details for transactions initiated from the mobile application 1212. The mobile application 1212 can also use the transaction verification log 1254 to support active account management processes and post payment interactions. The account parameter thresholds 1252 (e.g., usage limited thresholds) can be initially configured and can potentially be updated using different thresholds to inform the mobile application 1212 when to initiate a request for updated account parameters (e.g., time to live, number of transactions, cumulative transaction amount, etc.).

[0264] The mobile application 1212 can also include account parameter storage 1240 and mobile application platform (MAP) communication logic 1246. The account parameter storage 1240 stores account parameters (e.g., account identifier or alternative account identifier or token, LUK 1242, key index 1244, etc.) used to initiate cloud-based payment transactions. The MAP communication logic 1246 is used to enable secure communication with a mobile application platform (MAP) in order to request, send, and receive information to manage a user’s cloud-based payment account. This can include logic to consume and process information for the account management logic 1230.

[0265] Account management logic 1230 includes logic for handling information for a cloud-based payment service, such as enrollment logic 1232, configuration logic 1233, active account management logic 1236, lifecycle management logic 1234, and post payment interaction logic 1238. Enrollment logic 1232 includes logic for a consumer to initiate enrollment of an account with a cloud-based payment service. Configuration logic 1233 includes logic for processing card issuer data to configure an account on a mobile application 1212, including configuration of initial account parameters. Active account management logic 1236 can be used to initiate a request to update account parameters using a MAP when account parameter thresholds have been exceeded. Active account management logic 1234 can include logic for initiating and processing account lifecycle events, such as consumer initiated deletion, card issuer initiated deletion, card issuer initiated freeze, and / or card issuer initiated restoration, among others. Post payment interaction logic 1238 is used to support payment verification. Post payment interaction logic 1238 can include logic for receiving and responding to requests from a MAP for transaction verification logs 1254. Post payment interaction logic 238 can also be used to support account parameter replenishment, and can include logic for extracting required information from transaction verification logs 1254 to send to a MAP as part of an account parameter replenishment request.

[0266] Mobile application 1212 can also include mobile application features 1220. Mobile application features 1220 can include consumer verification method (CVM) logic 1224, payment modes 1222, and user settings 1226. CVM logic 1224 can include logic required to confirm mobile application 1212 supported mobile application passcodes or on-device verification methods (e.g., screen lock), or other verification information methods. Payment modes 1222 can include logic to support setting various ways in which mobile application 1212 and portable communication device 1201 are prepared to initiate transactions, and can include support for manual and / or always online modes.

[0267] The manual mode is a state in which the mobile application 1212 is configured to be accessible to make a payment after the consumer explicitly selects (1) to open the mobile application 1212, (2) to enter user input for a consumer verification method, if required, and (3) to select an account for a contactless payment transaction and for a single transaction or for a limited time. For the manual mode, a decision can be made as to whether a consumer device cardholder verification method (CDCVM) will be required before making a payment. If CDCVM is used, the two- split scenario for high value transactions can not be necessary. Conversely, to reduce use barriers, if the issuer decides to select not to require CDCVM in the manual mode, the consumer will be able to make a transaction once the conditions for manual mode operation are met. In this latter scenario, the mobile application 1212 can support entry of CDCVM if requested during a high value payment process.

[0268] The always on mode is a state in which an account (default account) on the portable communication device 1212 is expected to be accessible by a contactless reader without interruption. A portable communication device set in this state allows the consumer to initiate a contactless payment transaction by presenting the portable communication device to a contactless reader. The always on mode can also support device verification (hereinafter referred to as device on-verified always on mode). This setting allows for additional security. For example, the user can have to 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.

[0269] Figure 13 to Figure 15 The state machine of the mobile application 1212 is illustrated when the mobile application 1212 is in the manual mode Figure 13 ), the always on mode Figure 14 ), and the device on-verified always on mode Figure 15 . The various states shown in Figure 13 to Figure 15 are described below.

[0270] Downloaded: The consumer downloads the application. Depending on the application and OS design, the state after download can be transient. If the consumer taps the portable communication device on a contactless reader in this state, there is no exchange of information between the portable communication device and the reader.

[0271] Installed: The consumer performs installation. If the consumer taps the portable communication device on a contactless reader in this state, there is no exchange of information between the portable communication device and the reader.

[0272] Initialized: The consumer sets up an account using the MAP, but does not add a payment card. If the consumer taps the portable communication device on a contactless reader in this state, there is no exchange of information between the portable communication device and the reader.

[0273] Active: The consumer adds a payment card and valid account parameters are configured in the mobile application. If the consumer taps the portable communication device on a contactless reader in this state, the mobile application can respond whenever the active processing mode is in effect.

[0274] Ready to Pay (Manual Mode): The consumer activates the payment card for a payment. This is a transient state and the mobile application must set up a timer to exit this state. The mobile application moves to the Payment Sent state when the transaction is completed or to the Active state when the time is up, or to "CDCVM Input" if CDCVM input is required. If the consumer taps the portable communication device on a contactless reader in this state, the mobile application initiates the contactless time data exchange.

[0275] Ready to Pay (Two Always Online Modes): The portable communication device is ready to initiate a transaction using a contactless reader. The consumer selects the Always Online mode in the mobile application. The mobile application moves to the Payment Sent state when the transaction is initiated or to the CDCVM Input state if CDCVM input is required. If the consumer taps the portable communication device on a contactless reader in this state, the mobile application initiates the contactless time data exchange.

[0276] CDCVM Input: The contactless reader requires CDCVM. This is a transient state and the mobile application must set up a timer to exit this state. The mobile application moves to the Second Tap state when the consumer enters valid CDCVM, otherwise, after the timer expires, it moves to the Active state (Manual Mode) or Ready to Pay (in Two Always Online Modes). If the consumer taps the portable communication device on a contactless reader in this state, there is no exchange of information between the portable communication device and the reader.

[0277] Second Tap: The portable communication device is ready for a second tap to transmit CDCVM verification information to the contactless reader. This is a transient state and the mobile application can set up a timer to exit this state. The mobile application moves to the Payment Sent state when the consumer taps the portable communication device on a contactless reader, otherwise, after the timer expires, it moves to the Active state (Manual Mode) or Ready to Pay (in Two Always Online Modes). If the consumer taps the portable communication device on a contactless reader in this state, it sends the CDCVM verification flag to the contactless reader.

[0278] Payment sent: The consumer sends the payment payload to the contactless reader. This is a transient state. If the consumer taps the portable communication device on the contactless reader in this state, there is no exchange of information between the portable communication device and the reader.

[0279] Background: The mobile application is running in the background. If the consumer taps the portable communication device on the contactless reader in this state, the mobile application can respond whenever the validation processing mode is active.

[0280] Not running: The mobile application is not running on the portable communication device. If the consumer taps the device on the contactless reader in this state, there is no exchange of information between the portable communication device and the reader.

[0281] Mobile application security

[0282] To provide additional security, the mobile application 1212 can obfuscate and protect the stored keys through accepted mechanisms such as key wrapping. Code and data in the mobile application 1212 can be obfuscated to protect the code from reverse engineering. Communications between the mobile application 1212 and the MAP containing sensitive information can be exchanged after the MAP has made the channel secure (e.g., using TLS). The mobile application 1212 can adhere to the appropriate industry standards; such as FIPS-140-2. Error codes sent to the OS logging framework can only reveal information that would not be helpful to an attacker. Event logs and debug information can avoid direct or indirect exposure of any credentials. The logged information can also be encrypted. If the portable communication device is in a debug mode, the mobile application 1212 and the MAP can provide detection mechanisms, resistance mechanisms, and reporting mechanisms. The device state including jailbreaking, rooting, malware, mobile application runtime integrity, etc. can be checked before personalization and configuration of the mobile application 1212, and when new account parameters are sent to the mobile application 1212. If any compromise is detected, the mobile application 1212 can be deactivated, and the deactivation reason relayed back to the MAP. The mobile application security capabilities can be inherently built into the mobile application 1212 and can minimize reliance on the portable communication device and OS platform security capabilities. Device fingerprints and tools that support device analysis and attestation can be used to gain access for a rooted or stolen device.

[0283] In some embodiments, the MAP can use single or multi-factor authentication to authenticate the consumer and / or the portable communication device 1201. The storage device / memory used to store the keys in the mobile application 1212 can undergo attestation processes. For example, a root certificate can be generated. Inputs for generating the root certificate can be created from high-entropy properties, such as a hard-to-cloning function (UF) that resides on the portable communication device, and time-limited properties received and stored from a backend system. Subsequent certificates hosted in the key library can be generated from a generated key encryption key (KEK). User certificates can be used as inputs for generating the root certificate and KEK. Obfuscated permutation logic can be provided as inputs for generating the root certificate and KEK. The obfuscated permutation logic can be based on xx-morphing (polymorphic, metamorphic) mechanisms. The certificate library can be time-limited and volatile. When resident as in-use data, static data keys extracted from the key library can be encrypted and decrypted from yet another KEK. Binary properties of the application logic that processes the keys can be provided as inputs for generating KEKs for protecting in-use data. In-use data keys can be cleaned up by the application logic that processes the keys. The following protection profiles (PPs) can be established: a PP for KEK1-protected key library, a PP for KEK1 and 2 generation logic, a PP for KEK2-protected in-use data keys, and / or a PP for in-use data key cleanup.

[0284] Code and data in the mobile application 1212 can be obfuscated in order to protect the code from reverse engineering. The application logic that also drives key extraction can also be attested against tampering in order to ensure protection of the keys. The application logic that hosts the certificates used for authentication and the certificates themselves can be attested against tampering. Tamper-resistance / detection mechanisms can be implemented to protect the integrity of the code / application logic. User certificates can be used as inputs for encrypting sensitive portions of the code logic. Obfuscated permutation logic can be provided as inputs for generating KEKs. The obfuscated permutation logic can be based on xx-morphing (polymorphic, metamorphic) mechanisms. The code and application logic can be time-limited and volatile. The following protection profiles (PPs) can be established: a PP for tamper-resistance / detection, a PP for obfuscation generation logic, a PP for ensuring measurement initialization, and / or a PP for updates.

[0285] Mobile application launch and account preparation

[0286] At each consumer-initiated manual launch (i.e., by hard or soft key, or from the device's mobile application environment 1210), the mobile application 1212 can check and report to the MAP whether the portable communication device 1201 is in debug mode. The mobile application 1212 can check that the payment account configured in the mobile application 1212 is active and available, and check whether the account parameter threshold 1252 has been exceeded and determine whether an account parameter replenishment request is required. The mobile application 1212 can check the device state, including jailbreaking, rooting, malware, mobile application runtime integrity, and whether new account parameters have been sent to the mobile application 1212. If a device or application compromise is detected, the mobile application 1212 can be deactivated, and the deactivation reason relayed back to the MAP.

[0287] If the payment account managed by the mobile application 1212 is in a frozen state, the consumer can benefit from the information presented to take the necessary action or contact their issuer. To prepare a payment account configured in the mobile application 1212 for payment, the user can first select to use this payment account for payment. 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 for payment, navigates to the payment screen for the selected card or account and selects payment. In always online mode, the user selects a card or account to be used for payment as the default payment account. For on-device authenticated always online mode, the user selects a card or account to be used for payment as the default payment account. Once a card or account is selected for payment, the mobile application 1212 can configure the PPSE 1256 with the appropriate account details for the selected card or account. Once the PPSE 1256 is configured, the selected card or account is ready for payment when the user taps the portable communication device 1201 on an access device or otherwise communicates with an access device.

[0288] Mobile application user authentication

[0289] In some embodiments, the mobile application 1212 can support user authentication when interacting with the MAP and / or when interacting with an access device. When interacting with the MAP (e.g., configuring or replenishing account parameters stored in the account parameter storage device 1240), the MAP can authenticate a unique username and password depending on the context of that interaction and the requirements of the issuer. The mobile application 1212 can also provide the access device with a list of cardholder authentication methods supported by the mobile application 1212 when interacting with an access device. Card environment (e.g., online PIN and signature) supported cardholder authentication methods can also be supported by the cloud-based payment.

[0290] The portable communication device 1201 can also have a specific class of cardholder verification method, known as the consumer device cardholder verification method (CDCVM). There are multiple different methods that can be used to provide CDCVM for the mobile application 1212, which can include the same username / password utilized when authenticating with the MAP. The CDCVM method utilized by the mobile application 212 can provide different levels of security.

[0291] Cloud-based CDCVM performed by connection to an online service can provide the highest level of security. This can be the same username / password used for authentication to the MAP. However, if there is no data connectivity, this will cause payment failures that require CDCVM. Therefore, this option can be used in manual mode to prevent payment transactions from failing mid-way through a two- split process due to no data connectivity.

[0292] On-device CDCVM performed by the operating system at the portable communication device level can provide a better consumer experience. One example is the method required to unlock the portable communication device screen. The mobile application 1212 receives an indication from the portable communication device 1201 when the CDCVM has been successfully entered. The mobile application 1212 has no ability to change the on-device CDCVM. The mobile application CDCVM can be performed when the mobile application 1212 is opened and launched. One example is entering a numeric code to open the mobile application 1212. Since software-based CDCVM can not be as secure as other options, this method can be used in conjunction with a more secure option, such as cloud-based CDCVM, where the mobile application CDCVM is used when no data connectivity is available.

[0293] User Settings

[0294] The mobile application 1212 can receive these options, or a subset thereof, or take a default of one or more of these options, in a suitable manner. These options describe the general behavior of the mobile application 1212. For example, the user settings 1226 can include a payment method, such as manual, always online, or device-verified always online. The user settings 1226 can include whether the consumer can make changes to these initial preferences, how much time the consumer has to make a payment in each mode, how much time the consumer has to enter a passcode in a two- split transaction (which can apply to higher value transaction scenarios), what time period the mobile application 1212 should close if there is no interaction from the consumer, and the like. The user settings 1226 can also support passcode changes. The user can populate the mobile application passcode selected by the consumer by invoking a passcode change process and providing the current or default passcode and the new passcode selected by the consumer. The consumer can select these options to change a previously selected password / passcode. The mobile application 1212 can prompt the consumer to enter the current passcode and the new passcode (depending on the implementation and the manner in which the password is masked, the consumer can be prompted to enter the new passcode twice to ensure correct entry). The mobile application 1212 can replace the old password / passcode with the new password / passcode. The location of the password / passcode can be stored remotely from the device or locally.

[0295] If the consumer has selected to modify the always online mode setting, the PPSE 1256 can be configured appropriately (e.g., the file control information (FCI) template can be updated with the directory entry of the default payment account). This ensures that the default account is used when the portable communication device 1212 is brought into proximity of an access device when a transaction is conducted.

[0296] If the on-device verification setting is turned on, the mobile application 1212 can ensure that a transaction is not initiated until the verification method has been confirmed. In this case, the verification method can be the verification method that the user has set to unlock the phone. Upon successful verification, the cardholder verification method (CVM) verification field in the mobile application 1212 can be set. The successful verification of this setting can then be communicated to the access device and ultimately to the issuer via the CVM verification field.

[0297] Mobile application interaction events

[0298] The behavior of the mobile application interaction events can depend on whether the mobile application 1212 is currently running when the event occurs, or whether the event received by the underlying mobile application environment 1210 is a trigger that causes the mobile application 1212 to launch. Depending on the capabilities of the underlying mobile application environment 1210, the mobile application 1212 can be able to distinguish between different events.

[0299] Receipt of push notifications by the base mobile application environment 1210 can target the mobile application 1212. The mobile application 1212 can be reached in-band via the MAP to supplement account parameters of the cloud-based account or to push other data that the issuer and / or MAP can deem necessary. The communication channel with the MAP can also be used for the issuer to send lifecycle management events, such as freeze, thaw, delete.

[0300] When shutting down, the mobile application 1212 can ensure that the state of each payment account is in a suitable state. This can apply when the mobile application 1212 is going through an expected shutdown sequence and when the mobile application 1212 terminates unexpectedly. The previous account validation applied in the manual launch process can be reversed and the payment account CDCVM validation indicator can be set to negative. The mobile application 1212 can ensure that the settings reflecting the consumer's choices are preserved and that the payment account is in its regular idle state.

[0301] Mobile application shutdown / cleanup

[0302] Cleanup can be performed when the mobile application 1212 shuts down unexpectedly or intentionally, for example, because the portable communication device is shutting down due to low battery power. In any payment mode, the mobile application 1212 can save the payment mode, account parameters, associated thresholds, and default card settings so that they are available when the mobile application 1212 is launched again. The mobile application 1212 can terminate any ongoing transactions, close any open sessions with the MAP, save transaction logs if the mobile application 1212 is shut down immediately before a transaction is successfully completed, and free up any system and memory resources used by the mobile application 1212. In some embodiments, depending on how the CDCVM validation logic is implemented, the mobile application 1212 can choose to set or reset the "CDCVM successful execution" flag.

[0303] Depending on the payment mode selected when the mobile application 1212 is shut down, the implementation logic related to PPSE configuration can differ during the shutdown / cleanup process. In the always online mode, the mobile application 1212 can save the PPSE configuration so that when the mobile application 1212 is launched again, the PPSE selects the default card as the only active card for payments. In the manual mode, the PPSE configuration can not be saved when shutting down. Instead, the PPSE can be repopulated when the consumer selects a card to pay with when the mobile application 1212 is launched next time. When the mobile application 1212 is shut down, the mobile application 1212 can ensure that the settings reflecting the consumer's choices are preserved and that the payment account is in its regular idle state.

[0304] Navigation from the mobile application

[0305] When the consumer presses the home button or back button of the portable communication device to exit the mobile application 1212 and then returns to the mobile application, the mobile application 1212 can continue to run in the background and continue the operations being performed. The mobile application 1212 can be limited for additional security applications, such as a timeout setting, to limit the time it can continue to run in the background. If the consumer places the mobile application 1212 in the background while a transaction is in progress, the mobile application 1212 can continue the transaction processing.

[0306] Mobile application uninstallation

[0307] As part of the uninstallation process, the mobile application 1212 can purge any sensitive data, such as keys, credentials, and account parameters. The mobile application 1212 can notify the MAP so that the CBPP and the issuer / host system can perform the necessary lifecycle management processes for the accounts configured in the mobile application 1212 at the time of uninstallation. The mobile application 1212 can close any open sessions with the MAP, terminate ongoing transactions, if any, and release any system and memory resources being used by the mobile application 1212.

[0308] Account enrollment

[0309] The mobile application 1212 can include enrollment logic 1232 for enrolling / adding a payment account into the cloud-based payment program, unless the issuer has provided another channel to accomplish this. The issuer can be directly involved in the enrollment process (e.g., the issuer can directly make the accept / reject enrollment decision or delegate the decision to a third party under predefined conditions). In both cases, the issuer can have full control over the acceptance criteria and precisely define the card account verification method and the consumer authentication method.

[0310] The enrollment logic 1232 can allow the consumer to enter card details to initiate payment account enrollment. These details to be captured can be determined by the issuer / host system and / or the CBPP, but should be sufficient to uniquely identify and verify the payment account. The issuer / host system and / or the CBPP can determine the method and information needed to authenticate the consumer who owns that account. The mobile application 1212 can send the payment account enrollment data to the MAP, which will then use the issuer / host system and / or the CBPP to send and manage the account enrollment and account verification processes.

[0311] If the enrollment is successful, the mobile application 1212 can receive data from the MAP to configure the new payment account for payment, including payment account application ID (AID), PPSE AID, payment account issuer settings, payment account card art, account parameters, account parameter settings, and thresholds, etc. If the enrollment is successful, the enrollment logic 1232 can configure the payment account based on the information received from the MAP. The mobile application 1212 can also request the consumer to set the account verification method (e.g., password) as part of the configuration process if it has not been set. When the account configuration is complete, the mobile application 1212 can display a message to the consumer that the enrollment was successful. The mobile application 1212 can support and configure account parameter thresholds defined by the issuer / host system and / or CBPP. The account parameter thresholds can include number of transactions (i.e., the cumulative number of transactions that will trigger a replenishment request for a particular payment account), time to live (i.e., the amount of time that elapses before the mobile application 1212 will trigger a replenishment request for a particular payment account), and / or cumulative transaction amount (i.e., the total monetary amount of one or more transactions conducted on that account before the mobile application 1212 will trigger a replenishment request for a particular account). If the enrollment is not successful, the mobile application 1212 can receive and process the failure notification and reason code, and display a message to the consumer that the enrollment was not successful and request the consumer to take any appropriate action.

[0312] Payment using mobile application

[0313] The mobile application 1212 enables the user to perform contactless transactions at a contactless access device via the portable communication device 1201. The mobile application 1212 facilitates the above by using the account parameters provided by the CBPP for generating the data format for conducting payment transactions. To avoid consumer confusion as to where the payment will be allocated, the consumer can be required to select which mobile application to use for payment if multiple payment mobile applications are installed on the portable communication device 1212. There can be multiple options for how this can be implemented. The consumer can be able to set a default payment mobile application in the mobile OS settings at the time of consumer opt-in. The consumer can be able to set a default payment product in the settings of a particular mobile application. The consumer can be able to manually select a payment product within that mobile application. To ensure the use of the consumer selection, the mobile application 1212 can present the selected payment account to the access device. Depending on which type of transaction the access device supports, the mobile application 1212 can support either integrated chip based transactions or magnetic stripe based transactions. Integrated chip based transactions are the default path used by access devices that support chip cards, while magnetic stripe based transactions are the default path used by access devices that only support magnetic stripes.

[0314] In some embodiments, the mobile application 1212 can support multiple application identifiers (AIDs) for a single account. A single account can have multiple AIDs associated with it, for example, if transactions conducted on that account can be processed by different payment processing networks and / or if the account has different services, features, product types, and payment capabilities associated with the account. The multiple AIDs can be conveyed to the access device to allow the access device to select a preferred AID to select how to process the transaction (e.g., which payment processing network) and / or what services or features are associated with the transaction. The multiple AIDs can be populated in the directory entries of the PPSE and conveyed to the access device for this purpose.

[0315] For example, a single account can have a common debit AID and a payment processing network specific AID (e.g., a Visa AID) associated with the single account. These AIDs can be populated in the directory entries of the PPSE and the file control information (FCI) of each directory entry of the PPSE can include an issuing bank identification number (IIN) and an issuing bank country code (ICC). In some embodiments, the CVM for the debit AID can be an online CVM (e.g., an online PIN), while the CVM for the payment processing network specific AID can be a signature.

[0316] Contactless payments can be initiated by the consumer tapping the portable communication device 1201 to a contactless reader (e.g., an NFC reader), or otherwise communicating with the contactless reader of the access device (e.g., displaying a QR code or barcode). For transactions above a threshold amount (e.g., transactions above $20), the access device can request a cardholder verification method (CVM). The mobile application 1212 can support a variety of different CVMs, including a mobile specific consumer device cardholder verification method (CDCVM). Not all access devices can support the CDCVM, and in those cases, an alternative CVM, such as a signature or an online PIN, can be requested.

[0317] An indication that the CDCVM was entered successfully during the payment transaction is sent to the contactless reader. When the CDCVM has been successfully confirmed, the mobile application 1212 can configure the appropriate data in the account parameters at the time of payment. Whenever the CDCVM is entered successfully, the mobile application 1212 can store this information so that the CDCVM verification indicator and the CDCVM type indicator can be set and passed to the contactless reader during the payment transaction. This can prevent the access device from prompting the consumer to enter the CDCVM at the access device. The mobile application 1212 can have an indication of CDCVM success provided when requested by the access device during a two-tap payment transaction.

[0318] When the mobile application 1212 is locked due to inactivity, the mobile application 1212 can store this information such that the CDCVM verification indicator can be set to negative. If a contactless payment is initiated in this state, the access device can prompt the consumer for entry of the CDCVM. If the mobile application 1212 provides a consumer verification entry method for the CDCVM, it can provide the ability for CDCVM reset. The mobile application 1212 can set a limit on the number of consumer verification attempts and lock the mobile application 1212 if this limit is exceeded. For security purposes, the card issuer can request additional consumer verification before the mobile application 1212 is unlocked. In some embodiments, the mobile application 1212 can have a CDCVM that is not synchronized with the on-line PIN of the companion card.

[0319] In the manual mode, the consumer can open or launch the mobile application 1212 to enable payment functionality. When the mobile application 1212 is opened, the functionality can be enabled such that the consumer can initiate a payment by tapping the portable communication device 1201 to a contactless reader. If the mobile application 1212 is not open and active like a foreground application, the portable communication device 1201 can prevent the consumer from performing transactions based on any accounts stored in the mobile application 1212.

[0320] If the CDCVM indicator is not positive (i.e., a valid CDCVM entry has not been entered), the mobile application 1212 can request a CDCVM entry when opened. If this implementation path is selected, this can ensure that the consumer is not requested for a CDCVM entry during a payment transaction (i.e., avoid the two tap scenario for high value payments). Conversely, if this implementation path is not selected, the usability for the consumer can be improved by omitting the request for a CDCVM entry for transactions below the high value limit, where the compromise is that the consumer will be required to enter a CDCVM if a high value payment is made.

[0321] If there is more than one payment card or account available in the mobile application 1212, the card or account selected as the default card or account will be the card or account used for payment transactions unless the consumer selects an alternative card or account to be active for payment. Once the mobile application 1212 is open, the PPSE 1256 can be populated and the portable communication device 201 can initiate payment transactions. The mobile application 1212 can display a message to the consumer that the portable communication device 1201 is "ready to pay." The mobile application 1212 can define a time limit of inactivity after which the mobile application 1212 can lock. This ensures that the consumer still has control of the payment function and that the manual mode does not become a permanently online mode through inactivity. The mobile application 1212 can also enable the consumer to select a preferred time limit in the settings. Depending on whether CDCVM is required, the mobile application 1212 can require CDCVM entry to unlock the mobile application 1212 after it has been locked due to inactivity.

[0322] In the permanently online mode, the contactless payment capability is available whenever the phone screen is active. The contactless capability (e.g., NFC) can be available even if the phone screen is still in a locked state. To ensure that the consumer is aware of this capability and can choose to engage its use, the mobile application 1212 can exclude the permanently online mode from being set as the default mode. The PPSE 1256 can be activated and populated whenever the phone screen is active and the portable communication device 1201 is able to initiate payment transactions. When the consumer uses to initiate a contactless transaction while the screen is in a locked state, the contactless reader can request CDCVM entry. When a device-level CDCVM is used, an icon indicator can be displayed on the notification bar and the phone screen needs to be unlocked. The mobile application 1212 can then instruct the consumer to tap the portable communication device 1201 to the contactless reader. When a mobile application-level CDCVM is used, an icon indicator can be displayed on the notification bar. The mobile application 1212 can present a CDCVM entry screen to the consumer and then instruct the consumer to tap the portable communication device 1201 to the contactless reader once the CDCVM has been successfully entered.

[0323] In a device-verified always-on mode, the contactless payment capability is available whenever the phone screen is active and unlocked. When the phone screen is still in a locked state, the contactless capability is not available. Whenever the phone screen is unlocked, the PPSE 1256 can be activated and populated, and the portable communication device 1201 is able to initiate a payment transaction. If the consumer attempts to initiate a contactless payment when the screen is in a locked state, the contactless reader will not be able to communicate with the portable communication device 1201, and thus nothing will happen on the access device or on the portable communication device 1201. When the consumer uses to initiate a contactless payment when the screen is in an unlocked state, the contactless reader can request a CDCVM entry. When a device-level CDCVM is used, the mobile application 1212 can instruct the consumer to tap the portable communication device 1201 to the contactless reader. When a mobile application-level CDCVM is used, the mobile application 1212 can present a CDCVM entry screen to the consumer and then instruct the consumer to tap the portable communication device 1201 to the contactless reader once the CDCVM has been successfully entered.

[0324] When the mobile application 1212 and the access device have completed communication to provide data to complete the transaction, the mobile application 1212 can display a message that the payment has been sent. A contactless payment made using the integrated chip-based transaction path can provide the mobile application 1212 with some transaction data, such as the transaction amount and merchant information. The mobile application 1212 can populate the payment sent message with this information. A contactless payment made using the magnetic stripe-based transaction path does not provide the mobile application 1212 with any transaction data. After the payment, the mobile application 1212 can check the account parameter threshold and determine whether the mobile application 1212 needs to send a request for account parameter replenishment.

[0325] Active account management

[0326] When the account parameter threshold has been exceeded, the active account management logic 1236 of the mobile application 1212 initiates and manages the request for replenishment of the account parameter. To mitigate the risk of the account parameter stored in the account parameter store 1240 being compromised, the CBPP can periodically generate account parameters and replenish them in the mobile application 1212 and refresh them in the issuer / host system in order to maintain the account in an active state. To initiate the active account management process, the CBPP can receive a replenishment request for new account parameters from the mobile application 1212 through the MAP. The CBPP 180 can also act on requests received from the issuer / host system.

[0327] In some embodiments, the active account management logic 1236 of the mobile application 1212 can trigger an update or replenishment of the account parameters through an account parameter replenishment pull process. The active account management logic 1236 can attempt to initiate the account parameter replenishment process when the consumer launches the mobile application 1212, or after a transaction has been completed and the account parameter threshold 1252 has been exceeded. Upon receiving the updated account parameter set, the mobile application 1212 can process the account parameter payload and make the new account parameters available for payment. Upon successful processing of the new account parameter set, the mobile application 1212 can generate a notification to the MAP. The MAP can notify the CBPP that the account parameters were successfully delivered to the mobile application 1212. It should be noted that the updated account parameters can be accompanied by a new set of device threshold management parameters (e.g., a different usage-restricted threshold than the previous set of account parameters) that the issuer wants to use when the consumer is in a different environment (e.g., outside of the home market). Prior to initiating the exchange of sensitive information, the MAP can perform user-level, portable communication device-level, and / or application-level authentication.

[0328] The update or replenishment of the account parameters can also be performed with an account parameter replenishment push process. In this process, the CBPP initiates the process to update the account parameters. The CBPP sends a push message to the MAP to initiate the replenishment push. The MAP can then send the push message to the mobile application 1212. The mobile application 1212 then generates an account parameter update request as in each of the replenishment pull processes described above. Prior to initiating the exchange of sensitive information, the MAP can perform user-level, portable communication device-level, and / or application-level authentication. If user-level authentication is used because the previous authentication has expired, the mobile application 1212 can cache the request until the consumer opens the mobile application 1212 and performs user-level authentication. After successful authentication, the mobile application 1212 follows the same procedure as in the replenishment pull processes. If user-level authentication is not needed because the previous authentication has not expired, the mobile application 1212 can immediately follow the same procedure as in the replenishment pull processes.

[0329] Upon receiving the updated account parameter set, the active account management logic 1236 can check the validity of the new account parameters, make the new account parameters available for payment, reset the account parameter threshold, reset the account parameter threshold configuration, and delete the old account parameter set. In some embodiments, the mobile application 1212 can allow a transaction to be initiated even if the account parameters were not updated due to lack of network connectivity. The issuer / processor or payment processing network acting on behalf of the issuer can make a decision to approve or decline the transaction based on knowledge of the expired account parameters in conjunction with other issuer-defined risk metrics.

[0330] The mobile application 1212 can include a number of cloud-based payment device account parameter thresholds 1252 or risk limits that trigger updates of the current set of account parameters. This can include a number of transactions, a time to live, and / or a cumulative transaction amount, among others. If the account parameters are valid for a number of transactions in a CBPP, the account parameter threshold 1252 in the mobile application 1212 can be configured with a lower threshold number of transactions that triggers a replenishment (e.g., a threshold number of transactions that is less than the number of transactions in the CBPP). If the account parameters time out in the CBPP, the account parameter threshold 1252 in the mobile application 1212 can be configured with a threshold amount of time that is shorter than the time to live that triggers a replenishment. When available from a contactless reader, the transaction amount can be used by the active account management logic 1236 to make a decision whether the account parameters should be updated. A smaller transaction amount will not necessarily require an immediate update of the account parameters. However, this mechanism can not be reliable in an environment where the mobile application 1212 does not consistently receive the transaction amount from the access terminal. When reliable, the cumulative transaction amount can be used as a trigger for account parameter updates. This limit is based on the sum of individual transaction amounts. Unless this data is synchronized with the issuer / host system to ensure that the given transaction is agreed to, this data can not necessarily be reliable from the perspective of the mobile application 1212. Domestic vs. international risk settings can also be used to trigger updates more frequently for international transactions if international transactions are deemed to be higher risk.

[0331] Account Lifecycle Management

[0332] The mobile application 1212 can include lifecycle management logic 1234 to provide a user-initiated deletion option for the user to delete a card or account from the mobile application 1212 via the lifecycle management logic 1234. The account lifecycle logic 1234 can delete the account parameters associated with the account stored in the account parameter store 1240, and all other account configuration data or artifacts. The lifecycle management logic 1234 can initiate the account deletion process in the CBPP by initiating a deletion request via the MAP to the CBPP.

[0333] The lifecycle management logic 1234 can enable the issuer-initiated deletion mechanism of the issuer to delete the account. The issuer / host system can send a deletion request to the CBPP, and in turn, the CBPP can route the request to the mobile application 1212. The lifecycle management logic 1234 can delete the locally stored account parameters associated with the account, and all other account configuration data or artifacts. The mobile application 1212 can send a notification to the MAP indicating that the deletion has been completed. The mobile application 1212 can also display a message to the user notifying that the account was deleted.

[0334] The lifecycle management logic 1234 can enable a card issuer initiated freeze mechanism by the card issuer to freeze an account. The card issuer / host system can send a freeze request to the CBPP, and in turn, the CBPP can route the request to the mobile application 1212. The lifecycle management logic 1234 can freeze the card or account in the mobile application 1212. In the frozen state, the account can not be selectable for payment in the mobile application settings. The lifecycle management logic 1234 can send a confirmation notification to the MAP after freezing the account. The mobile application 1212 can display a message to the user that the account is frozen and can also notify the consumer to contact the card issuing bank.

[0335] When an account is frozen in the mobile application 1212, the lifecycle management logic 1234 can enable a card issuer initiated restore mechanism by the card issuer to restore the account. The card issuer / host system can send a restore request to the CBPP, and in turn, the CBPP can route the request to the mobile application 1212. The lifecycle management logic 1234 can restore the card or account in the mobile application 1212. After restoration, the card or account can be selectable for payment in the mobile application settings. The mobile application 1212 can send a confirmation notification to the MAP after restoring the account and display a message to the user that the account has been restored.

[0336] Post-Payment Interaction

[0337] The post-payment interaction or process can help the card issuer mitigate the risk of account parameters being compromised and thus can help limit exposure of account parameters stored on the portable communication device 1201. Information contained in the transaction verification log can be used to provide a reference point for the CBPP to help ensure that account parameter replenishment requests originate from the intended portable communication device. The mobile application 1212 can include post-payment logic 1238 for extracting information from the transaction verification log 1254 in order to construct an account parameter replenishment request.

[0338] Additionally, the issuer / host system working in conjunction with CBPP has the option to initiate a request through the MAP for the transaction verification log data captured and stored by the mobile application 1212 to verify a transaction. The mobile application 1212 can respond to the request using the requested transaction verification log data through the MAP. The issuer / host system can then verify this data to confirm whether a particular transaction originated from the queried portable communication device. Examples of data elements that can be included in the transaction verification log for each transaction can include the time of the transaction (e.g., the time of the contactless interaction, the transaction amount, and the unpredictable number received from the access device during the transaction), and account parameter information such as the key index associated with the LUK used to conduct the transaction. For payment transaction verification, the mobile application 1212 can receive and process requests from the MAP for the transaction verification log captured and stored by the mobile application 1212. The mobile application 1212 can respond to the request of the MAP using the requested transaction verification log data. The mobile application 1212 can sign the requested transaction verification log data using the current LUK of the account parameter or the equivalent in the dynamic data portion of the account parameter.

[0339] transaction verification log

[0340] The mobile application 1212 can maintain a transaction verification log 1254 to log all contactless interactions (e.g., NFC) in which payment account parameters are shared with an access device, regardless of whether the transaction was accepted or declined, or whether the mobile application 1212 has visibility into the transaction result (e.g., accepted or declined). The mobile application 1212 can store transaction verification log data for the current and previous account parameter sets for each payment account. In some embodiments, the transaction verification log data for the old account parameter set can be deleted once the mobile application 1212 receives a new account parameter set. The transaction verification log 1254 can or can not be accessible or visible to the user.

[0341] XII. Exemplary Computer System

[0342] Reference is made herein to Figure 1 The various entities or components described can be associated with or operate on one or more computer devices to facilitate the functions described herein. Figure 1 Any of the entities or components in the system, including any servers or databases, can use any suitable number of subsystems to facilitate these functions.

[0343] Figure 16 Examples of such subsystems or components are shown in the system. Figure 16The subsystems shown in FIG. 16 are interconnected via a system bus 1602. Additional subsystems such as a printer 1614, a keyboard 1606, a fixed disk 1608 (or other memory embodied in computer-readable media), and other devices can be connected to the computer system by any of a variety of means, such as a serial port 1616. For example, a serial port 1616 or other interface can be used to connect the computer system to a wide area network such as the Internet, to a mouse input device, or to a scanner of the type generally used in processing computer-readable instructions. The interconnection via system bus allows the central processor 1620 to communicate with each subsystem and to control the execution of instructions from system memory 1622 or the fixed disk 1608, as well as the exchange of information between subsystems. The system memory 1622 and / or the fixed disk 1608 can embody a computer-readable medium.

[0344] Embodiments of the application are not limited to the above-described embodiments. For example, although separate functional blocks are shown for the issuer, the payment processing network, and the acquirer, some entity performs all of these functions and can be included in embodiments of the application.

[0345] The above provides specific details regarding some of the aspects described above. The specific details of particular aspects can be combined in any suitable manner without departing from the spirit and scope of embodiments of the application. For example, back-end processing, data analysis, data collection, and other transactions can all be combined in some embodiments of the application. However, other embodiments of the application can relate to specific embodiments related to each individual aspect, or specific combinations of these individual aspects.

[0346] It should be understood that the above-described application can be implemented in a modular or integrated manner using control logic, which can be stored in the form of software instructions in tangible physical media when the application is implemented using computer software. Those having ordinary skill in the art will appreciate and recognize further forms and / or methods of implementing the application using hardware and combinations of hardware and software based on the disclosure and teachings provided herein.

[0347] Any software components or functions described in this specification can be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++, or Perl using, for example, conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer readable medium such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer readable medium can reside on or within a single computational apparatus, and can be present on or within different computational apparatuses that are coupled together through a network.

[0348] The above description is illustrative and not restrictive. Many variations of the application will become apparent to those of skill in the art upon review of this disclosure. The scope of the application should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

[0349] One or more features from any embodiment can be combined with one or more features of any other embodiment, without departing from the scope of the application.

[0350] Reference to "a," "an," or "the" is intended to mean "one or more" unless otherwise explicitly indicated to the contrary.

[0351] All patents, patent applications, publications, and descriptions mentioned herein are incorporated by reference for all purposes. None is admitted to be prior art.

Claims

1. A method for enhancing security of a communication device when using the communication device for transactions, the method comprising: receiving, by the communication device from a remote computer, a first LUK and a key index used as a seed for generating the first LUK, wherein the first LUK is associated with a set of one or more restricted use thresholds that limit use of the first LUK, wherein the first LUK can be used for more than one transaction, wherein the key index includes time information indicating when the first LUK was generated, a replenishment counter value indicating a number of times the first LUK has been replenished, a pseudo-random number, and a transaction counter value indicating a number of transactions the communication device’s mobile application has previously conducted when generating the first LUK, and wherein the first LUK is generated by encrypting account information using a first encryption key to generate a second encryption key and encrypting the key index using the second encryption key to generate the first LUK, wherein encrypting account information using a first encryption key to generate a second encryption key comprises encrypting the account information using the first encryption key to generate a first portion of the second encryption key, reversing the account information, and encrypting the reversed account information using the first encryption key to generate a second portion of the second encryption key, wherein the first encryption key is a master derivation key associated with an issuer of an account associated with the account information; receiving, by the communication device from a first access device, a first signal including first terminal transaction data for a first integrated chip-based transaction, wherein the first terminal transaction data is dynamic data that changes for each transaction; generating, by the communication device, a first type of transaction cryptogram for the first integrated chip-based transaction by encrypting the first terminal transaction data using the first LUK; sending, by the communication device to the first access device, a token in place of a real account identifier, the first type of transaction cryptogram, and the key index for the first integrated chip-based transaction, wherein the key index is verified, wherein the key index is used to regenerate the first type of transaction cryptogram and thereby verify the first type of transaction cryptogram, wherein the first integrated chip-based transaction is authorized based at least on whether use of the first LUK has exceeded the set of one or more restricted use thresholds, and wherein the set of one or more restricted use thresholds includes a restricted use threshold indicating a predetermined number of transactions for which the first LUK is valid, wherein the predetermined number of transactions is more than one transaction; generating, by the communication device, a second type of transaction cryptogram for a magnetic stripe based transaction by using the first LUK to encrypt static data without using any dynamic data, wherein the second type of transaction cryptogram has a different final format than the first type of transaction cryptogram, wherein the first type of transaction cryptogram and the second type of transaction cryptogram are generated using different types of input data, the first type of transaction cryptogram is generated based on the dynamic data received from the first access device, and the second type of transaction cryptogram is generated based on static data without using input from a second access device; sending, by the communication device, the second type of transaction cryptogram to the second access device for the magnetic stripe based transaction; sending, by the communication device, a replenishment request for a second LUK to the remote computer, wherein the replenishment request for the second LUK includes transaction log information derived from transaction data in a transaction log stored on the communication device, the transaction data being unique for each of a plurality of transactions conducted by the communication device using the first LUK, and wherein the remote computer verifies that the transaction log information in the replenishment request is consistent with previously received transaction information; and receiving, by the communication device, the second LUK from the remote computer, the second LUK being a different key than the first LUK.

2. The method of claim 1, wherein the communication device does not store the first LUK or the token in a secure element.

3. The method of claim 1, wherein the token is associated with a usage limit that matches the set of one or more restricted usage thresholds that limit usage of the first LUK.

4. The method of claim 1, wherein the predetermined number of transactions is a number in a range of 2 to 10 transactions.

5. The method of claim 1, wherein the predetermined number of transactions is a number in a range of 5 to 50 transactions.

6. The method of claim 1, wherein the set of one or more restricted usage thresholds further includes a time-to-live that indicates a duration of time for which the first LUK is valid.

7. The method of claim 6, wherein the duration of time is 2 days, 4 days, or 5 days.

8. The method of claim 1, wherein the set of one or more restricted usage thresholds further includes a cumulative transaction amount that indicates a total transaction amount for which the first LUK is valid.

9. The method of claim 8, wherein the cumulative transaction amount is a value in a range of 100 dollars to 5,000 dollars.

10. The method of claim 1, wherein the set of one or more restricted usage thresholds further includes an international usage threshold and a domestic usage threshold.

11. The method of claim 1, wherein the replenishment request further includes the key index, wherein the key index is a first key index, and wherein receiving the second LUK includes receiving a second key index that functions as a second seed used to generate the second LUK.

12. The method of claim 11, wherein the set of one or more restricted use thresholds is a first set of one or more restricted use thresholds, the second LUK is associated with a second set of one or more restricted use thresholds that restricts use of the second LUK, and the second set of one or more restricted use thresholds is different than the first set of one or more restricted use thresholds.

13. The method of claim 11, wherein the transaction log information sent to the remote computer includes an authentication code computed at least by the transaction log using the first LUK as an encryption key, wherein the remote computer has tracked transaction activity for an account associated with the first LUK.

14. The method of claim 12, wherein the transaction log stored on the communication device includes: for each transaction conducted using the first LUK: a transaction timestamp indicating a time of the corresponding transaction; an application transaction counter value associated with the corresponding transaction; and a transaction type indicator indicating whether the corresponding transaction was a magnetic stripe based transaction or an integrated chip based transaction.

15. The method of claim 1, wherein the replenishment request is sent in response to (a) a determination that a next transaction conducted with the first LUK will exhaust the set of one or more restricted use thresholds, (b) a determination that the set of one or more restricted use thresholds associated with the first LUK has been exhausted, or (c) receipt of a push message requesting that the communication device replenish the first LUK.

16. A communication device comprising: a processor; and a memory coupled to the processor and storing a mobile application that performs operations for enhancing security of the communication device when conducting transactions using the communication device, the operations implementing the method of any one of claims 1-15.

17. A method comprising: generating, by a remote computer, a first LUK, wherein a key index that functions as a seed used to generate the first LUK includes time information indicating when the first LUK was generated, a replenishment counter value indicating a number of times the first LUK has been replenished, a pseudo-random number, and a transaction counter value indicating a number of transactions a mobile application of a communication device has previously conducted at a time of generating the first LUK, wherein generating the first LUK includes: encrypting account information using a first encryption key to generate a second encryption key, including: encrypting the account information using the first encryption key to generate a first portion of the second encryption key; inverting the account information; and encrypting the inverted account information using the first encryption key to generate a second portion of the second encryption key. ​ encrypting the reversed account information using the first encryption key to generate a second portion of the second encryption key, wherein the first encryption key is a master derived key associated with an issuer of an account associated with the account information; encrypting the key index using the second encryption key to generate the first LUK; creating, by the remote computer, an association between the first LUK and a set of one or more restricted use thresholds that limit use of the first LUK, wherein the set of one or more restricted use thresholds includes a restricted use threshold that indicates a predetermined number of transactions for which the first LUK is valid, wherein the predetermined number of transactions is more than one transaction, such that the first LUK can be used for more than one transaction; providing, by the remote computer, the first LUK and the key index to the communication device, wherein the communication device receives a first signal from a first access device, the first signal including first terminal transaction data for a first integrated chip based transaction, wherein the first terminal transaction data is dynamic data that changes for each transaction, wherein the communication device uses the first LUK to generate a first type of transaction cryptogram for the first integrated chip based transaction by encrypting the first terminal transaction data; receiving, by the remote computer, the first type of transaction cryptogram, the key index, and a token in place of a real account identifier for the first integrated chip based transaction from the first access device; verifying, by the remote computer, the key index; verifying, by the remote computer, the first type of transaction cryptogram by regenerating the first type of transaction cryptogram based on the key index; determining, by the remote computer, that use of the first LUK has not exceeded the set of one or more restricted use thresholds; authorizing, by the remote computer, the first integrated chip based transaction based on determining that use of the first LUK has not exceeded the set of one or more restricted use thresholds and further based on verifying the transaction cryptogram, wherein the communication device generates a second type of transaction cryptogram for a magnetic stripe based transaction by encrypting static data using the first LUK without using any dynamic data, wherein the second type of transaction cryptogram has a different final format than the first type of transaction cryptogram, wherein the first type of transaction cryptogram and the second type of transaction cryptogram are generated using different types of input data, the first type of transaction cryptogram is generated based on the dynamic data received from the first access device, and the second type of transaction cryptogram is generated based on static data without using input from a second access device; receiving, by the remote computer, the second type of transaction cryptogram from the second access device to perform the magnetic stripe based transaction; receiving, by the remote computer, a replenishment request for a second LUK, wherein the replenishment request for the second LUK includes transaction log information derived from transaction data stored in a transaction log on the communication device, the transaction data being unique to each of a plurality of transactions conducted by the communication device using the first LUK; verifying, by the remote computer, that the transaction log information in the replenishment request is consistent with previously received transaction information; and in response to verifying the transaction log information in the replenishment request, providing, by the remote computer, the second LUK to the communication device, the second LUK being a different key than the first LUK.

18. The method of claim 17, wherein the key index is a first key index, the set of one or more limited use thresholds is a first set of one or more limited use thresholds, and the method further comprises: generating, by the remote computer, the second LUK, wherein a second key index operates on a second seed to generate the second LUK, the second key index including second time information indicating when the second LUK is generated, a second pseudo-random number, and a second transaction counter value indicating a number of second transactions that the mobile application of the communication device has previously conducted at the second time when the second LUK is generated; creating, by the remote computer, an association between the second LUK and a second set of one or more limited use thresholds that limit use of the second LUK; and providing, by the remote computer, the second key index to the communication device along with the second LUK.

19. The method of claim 18, wherein the second set of one or more limited use thresholds is different than the first set of one or more limited use thresholds.

20. The method of claim 17, wherein the communication device does not store the first LUK or the token in a secure element.

21. The method of claim 17, wherein encrypting the key index using the second encryption key to generate the first LUK comprises: padding the key index with a first value to generate first padded key index information; encrypting the first padded key index information to generate a first portion of the first LUK; padding the key index with a second value to generate second padded key index information; and encrypting the second padded key index information to generate a second portion of the first LUK.

22. A server computer comprising: a processor; and a memory and code coupled to the processor, the code, when executed by the processor, implements the method of any of claims 17 to 21.

23. A method comprising ​ ​ ​ receiving, by a communication device from a remote computer, a first LUK and a key index used as a seed for generating the first LUK, wherein the first LUK is usable for more than one transaction, wherein the key index includes time information indicating when the first LUK was generated, a replenishment counter value indicating a number of times the first LUK has been replenished, a pseudo-random number, and a transaction counter value indicating a number of transactions the communication device's mobile application has previously made at the time the first LUK was generated, and wherein the first LUK is generated by encrypting account information using a first encryption key to generate a second encryption key and encrypting the key index using the second encryption key to generate the first LUK; receiving, by the communication device from a first access device, a first signal for a chip- integrated transaction, the first signal being received over a first communication link and indicating that the chip-integrated transaction is supported by the first access device and the first signal including first terminal transaction data; in response to receiving the first signal: generating, by the communication device, a first type of transaction cryptogram for the integrated chip based transaction by encrypting the first terminal transaction data using the first LUK, wherein the first terminal transaction data is dynamic data that changes with each transaction; and sending, by the communication device to the first access device over the first communication link for the chip-integrated transaction, first transaction data including a transaction cryptogram of the first type, the first transaction data being formatted according to the chip-integrated transaction; generating, by the communication device, a transaction cryptogram of a second type for a magnetic stripe-based transaction using the first LUK to encrypt static data without any dynamic data being applied, wherein the transaction cryptogram of the second type has a different final format than the transaction cryptogram of the first type, wherein the transaction cryptogram of the first type and the transaction cryptogram of the second type are generated using different types of input data, the transaction cryptogram of the first type being generated based on the dynamic data received from the first access device, and the transaction cryptogram of the second type being generated based on static data without using input from a second access device; sending, by the communication device to a second access device over a second communication link for the magnetic stripe-based transaction, second transaction data including the transaction cryptogram of the second type, the second transaction data being formatted according to the magnetic stripe-based transaction; sending, by the communication device to the remote computer, a replenishment request for a second LUK, wherein the replenishment request for the second LUK includes transaction log information derived from transaction data in a transaction log stored on the communication device, the transaction data being unique for each of a plurality of transactions conducted by the communication device using the first LUK, and wherein the remote computer verifies that the transaction log information in the replenishment request is consistent with previously received transaction information; and receiving, by the communication device from the remote computer, the second LUK, the second LUK being a different key than the first LUK.

24. The method of claim 23, wherein the first transaction data includes a token that is used as a substitute for an account identifier. ​ 25. The method of claim 23, wherein at least one of the first communication link or the second communication link is a wireless communication link.

26. The method of claim 23, wherein the first communication link and the second communication link use the same type of communication protocol.

27. The method of claim 23, wherein the first type of transaction cryptogram and the second type of transaction cryptogram are generated using the same encryption function.

28. The method of claim 23, wherein the first type of transaction cryptogram and the second type of transaction cryptogram are generated using different encryption functions.

29. The method of claim 23, wherein the second type of transaction cryptogram is sent to the second access device with a key index, wherein the key index contains information about the generation of the first LUK.

30. The method of claim 23, further comprising: after sending the first transaction data including the first type of transaction cryptogram to the first access device over the first communication link, sending a first file locator for first account data at a first file location of the communication device over the first communication link; and and sending a second file locator for second account data at a second file location of the communication device over the second communication link, wherein the first file location is different than the second file location.

31. The method of claim 23, further comprising: sending a first file locator for first account data at a first file location of the communication device over the first communication link; and and sending a second file locator for second account data at a second file location of the communication device over the second communication link, wherein the first file location is different than the second file location; receiving a first account data request over the first communication link, the first account data request indicating the first file location; and and receiving a second account data request over the second communication link, the second account data request indicating the second file location.

32. The method of claim 23, further comprising: storing the second type of transaction cryptogram in a memory location corresponding to an application file locator; sending the application file locator to the second access device over the second communication link; and receiving the application file locator from the second access device, wherein sending the second transaction data is performed in response to receiving the application file locator.

33. The method of claim 23, wherein generating the second type of transaction cryptogram using the first LUK comprises encrypting a predetermined string of numbers using the first LUK, and wherein the second type of transaction cryptogram has a reduced length compared to the first type of transaction cryptogram.

34. A communication device, comprising: a processor circuit; and and A non-transitory computer-readable storage medium coupled to the processor circuit and storing code executable by the processor circuit for implementing the method of any of claims 23-33.

35. A method comprising: encrypting, by a computer system, account information with a first encryption key to generate a second encryption key, comprising: encrypting the account information using the first encryption key to generate a first portion of the second encryption key; inverting the account information; and encrypting the inverted account information using the first encryption key to generate a second portion of the second encryption key, wherein the first encryption key is a master derivation key associated with an issuer of an account associated with the account information; encrypting, by the computer system, key index information using the second encryption key to generate a first LUK, wherein the key index information comprises a key index having information about a generation of the first LUK, wherein the first LUK is associated with a set of one or more restricted use thresholds that limit use of the first LUK, wherein the first LUK is usable for more than one transaction, wherein the key index includes time information indicating when the first LUK was generated, a replenishment counter value indicating a number of times the first LUK has been replenished, a pseudo-random number, and a transaction counter value indicating a number of transactions a mobile application of a communication device has previously made at the time the first LUK was generated; providing, by the computer system, the first LUK and the key index to the communication device, wherein the communication device uses the first LUK to generate a transaction cryptogram for a transaction; receiving, by the computer system from the communication device, a replenishment request for a second LUK, wherein the replenishment request for the second LUK includes transaction log information derived from transaction data in a transaction log stored on the communication device; verifying, by the computer system, that the transaction log information in the replenishment request is consistent with previously received transaction information; and providing, by the computer system to the communication device, the second LUK, the second LUK being a different key than the first LUK.

36. The method of claim 35, wherein the information about the generation of the first LUK includes a counter value indicating a number of times the first LUK has been updated within a predetermined time period.

37. The method of claim 35, wherein the set of one or more restricted use thresholds limits a number of transactions that can be made using the first LUK.

38. The method of claim 35, further comprising: receiving, by the computer system, the key index information and the transaction cryptogram generated by the communication device, the transaction cryptogram including transaction data encrypted by the first LUK; verifying, by the computer system, that the transaction cryptogram was generated using the first LUK and that the first LUK has not exceeded the set of one or more restricted use thresholds; and based on the verification, authorizing the transaction. ​ 39. The method of claim 38, wherein verifying that the transaction cryptogram was generated using the first LUK comprises: regenerating the transaction cryptogram using the received key index information.

40. The method of claim 39, wherein verifying that the transaction cryptogram was generated using the first LUK further comprises: comparing the result of the regeneration to the transaction cryptogram.

41. The method of claim 35, wherein the transaction is conducted without use of a secure element, and wherein the account information comprises a token that is a substitute for an account identifier.

42. The method of claim 35, wherein the second encryption key is a unique derived key for the account.

43. The method of claim 35, wherein encrypting the key index information using the second encryption key to generate the first LUK comprises: padding the key index with a first value to generate first padded key index information; encrypting the first padded key index information to generate a first portion of the first LUK; padding the key index with a second value to generate second padded key index information; and encrypting the second padded key index information to generate a second portion of the first LUK.

44. The method of claim 35, wherein the transaction cryptogram is generated by: encrypting transaction information using the first portion of the first LUK; decrypting the encrypted transaction information using the second portion of the first LUK; and re-encrypting the decrypted transaction information using the first portion of the first LUK.

45. The method of claim 35, wherein the transaction cryptogram is generated by: encrypting a predetermined string of digits using the first LUK; and decimally converting the encrypted predetermined string of digits.

46. The method of claim 45, wherein decimally converting the encrypted predetermined string of digits comprises: extracting numeric digits from the encrypted predetermined string of digits to form a first data block; extracting hexadecimal digits from the encrypted predetermined string of digits and converting each extracted hexadecimal digit to a numeric digit to form a second data block; and concatenating the first data block and the second data block.

47. A computer system comprising: a processor; and a memory storing computer readable code that, when executed by the processor, causes the processor to perform the method of any one of claims 35 to 46. ​ ​ ​

Images