Method and apparatus for mobile application integration

Abstract

Methods and systems for implementing transaction processing using a single device are disclosed. A mobile device may store an application including a first software module and a second software module. One module may perform acceptance processing, while another software module may simulate a transaction device associated with a user. One or more identifiers (e.g., QR codes, bar codes) corresponding to one or more physical items may be obtained. Authorization may be requested via the mobile device. In response, data may be exchanged between the software modules, and this data (e.g., transaction data, payment tokens, passwords, etc.) may be provided to a remote computer (e.g., a cloud-based acceptance service), which may generate an authorization request message for the transaction.

Description

[0001] Cross-reference to related applications

[0002] This application is a PCT application of and claims the benefit of U.S. Provisional Application No. 62 / 884,432, filed on August 8, 2019, which is incorporated herein by reference in its entirety for all purposes. Background Art

[0003] Advances in mobile device capabilities have enabled mobile devices, such as smartphones, to be used as a tool for conducting contactless transactions. For example, a mobile device may be placed near an access device (e.g., a POS terminal or a transit terminal) to transfer account information from the mobile device to the access device to conduct the transaction. In conventional transactions such as this transaction, the user of the mobile device is required to pick up any items to be obtained and then bring them to the access device to conduct the transaction. This can be cumbersome and time consuming, especially if there is a queue at the access device.

[0004] Other ways have also been developed to be able to process the acquisition of resources more quickly. For example, some mobile phone applications can allow users to conduct transactions even at resource providers such as merchants. However, the methods and systems that can achieve this are not as secure (compared to transactions conducted using physical cards with stored credentials). In such cases, the user's credentials can be stored on a remote computer as archived credentials. When doing so, the remote computer may be hacked and needs to have strict data storage requirements.

[0005] Embodiments of the invention address these and other problems individually and collectively. Summary of the invention

[0006] One embodiment of the present invention relates to a method. The method includes receiving, at a first software module on a mobile device, one or more identifiers associated with one or more physical items external to the mobile device. The mobile device includes the first software module configured to perform acceptance processing and a second software module configured to simulate a user device associated with a user. The one or more identifiers are read by the mobile device using an input component. Then, the first software module can receive an indication that an authorization request is to be initiated. Then, the first software module and the second software module of the mobile device exchange the interaction data associated with the one or more physical items and the token associated with the user by first providing an API call including the interaction data to the second software module by the first software module and secondly receiving an API response including the token from the second software module by the first software module. Then, the first software module sends the interaction data and the token associated with the user to a remote computer so that the remote computer generates an authorization request message including the interaction data and the token.

[0007] Another embodiment of the present invention relates to a mobile device, which includes one or more processors and one or more memories storing computer executable instructions, which when executed by the one or more processors cause the mobile device to perform the following operations. The mobile device includes a first software module configured to perform an acceptance process and a second software module configured to simulate a user device associated with a user. The operation includes receiving one or more identifiers associated with one or more physical items external to the mobile device at the first software module on the mobile device. The one or more identifiers can be read by the mobile device using an input component. The operation also includes the first software module receiving an indication that an authorization request is to be initiated. Then, the first software module and the second software module of the mobile device can exchange interaction data associated with the one or more physical items and a token associated with the user. The exchange can be performed by the first software module providing an API call including the interaction data to the second software module. Then, the first software module receives an API response including the token from the second software module. After the exchange, the first software module sends the interaction data and the token associated with the user to a remote computer so that the remote computer generates an authorization request message including the interaction data and the token.

[0008] Another embodiment of the present invention relates to a system including a remote computer and a mobile device. The mobile device includes one or more processors and one or more memories storing computer executable instructions, which when executed by the one or more processors cause the mobile device to perform the following operations. The mobile device includes a first software module configured to perform an acceptance process and a second software module configured to simulate a user device associated with a user. The first software module on the mobile device receives one or more identifiers associated with one or more physical items external to the mobile device. The one or more identifiers are read by the mobile device using an input component. The first software module receives an indication that an authorization request is to be initiated. The first software module and the second software module of the mobile device exchange interaction data associated with the one or more physical items and a token associated with the user. The first software module and the second software module can exchange the data by the first software module providing an API call including the interaction data to the second software module and then receiving an API response including the token from the second software module. The operation also includes the first software module sending the interaction data and the token associated with the user to the remote computer so that the remote computer generates an authorization request message including the interaction data and the token.

[0009] For other details about the embodiments of the present invention, please refer to the detailed description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 A block diagram illustrating a cloud-based transaction system 100 according to an embodiment is shown.

[0011] Figure 2 A flowchart illustrating an interaction processing method according to an embodiment is shown.

[0012] Figure 3 A flow chart illustrating details of communication between a first software module and a second software module according to an embodiment is shown.

[0013] Figure 4 A block diagram of a building access system according to an embodiment is shown. DETAILED DESCRIPTION

[0014] Before discussing the embodiments of the present invention, some terms may be described in further detail.

[0015] A "mobile device" may be a device operated by a user. Examples of user devices may include mobile phones, smart phones, cards, personal digital assistants (PDAs), laptop computers, desktop computers, server computers, vehicles such as cars, thin client devices, tablet PCs, etc. In addition, the user device may be any type of wearable technology device, such as a watch, headphones, glasses, etc. The user device may include one or more processors capable of processing user input. The user device may also include one or more input sensors for receiving user input. As is known in the art, there are various input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. The user input obtained by the input sensor may come from various data input types, including but not limited to audio data, visual data, or biometric data. The user device may include any electronic device that can be operated by a user, which may also provide remote communication capabilities with a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, a wireless data network (e.g., 3G, 4G or similar networks), Wi-Fi, Wi-Max, or any other communication medium that can provide access to a network such as the Internet or a private network.

[0016] "User device" may include any suitable device that can be operated by a user. For example, a user device may be used to perform financial transactions, such as providing payment vouchers to a merchant. Suitable user devices may be handheld and compact, such that they can be placed in a user's wallet and / or pocket (e.g., pocket size). Example user devices may include smart cards, key chain devices (e.g., Speedpass™ available from Exxon-Mobil), etc. Other examples of user devices include payment cards, smart media, transponders, etc. If the user device is in the form of a debit card, credit card, or smart card, the user device may also optionally have features such as a magnetic stripe. Such devices may operate in contact or contactless mode.

[0017] An "interaction" may include a mutual effect or influence. An "interaction" may include a communication, contact, or exchange between parties, devices, and / or entities. Example interactions include a transaction between two parties and an exchange of data between two devices. In some embodiments, an interaction may include a user request to access secure data, a secure webpage, a secure location, etc. In other embodiments, an interaction may include a payment transaction in which two devices may interact to facilitate payment.

[0018] "Interaction data" may include data related to an interaction and / or data recorded during an interaction. In some embodiments, the interaction data may be transaction data. The interaction data may include data used to process and complete an interaction. For example, the interaction data may include an amount (e.g., a transaction amount, an amount of data, and an amount of time, etc.). The interaction data may include a transaction code, a currency code, a date and / or time, a resource provider identifier, and / or any other suitable data used in the interaction. The interaction data may include a value or amount, information associated with a first party (e.g., an alias, an identifier, a contact address, etc.), information associated with a second party (e.g., an alias, a device identifier, a contact address, etc.), a one-time value (e.g., a random value, a temporary value, a timestamp, a count, etc.), and / or any other suitable information.

[0019] A "credential" may be any suitable information that serves as reliable evidence of value, ownership, identity, or authority. A credential may be a string of numbers, letters, or any other suitable characters, as well as any object or document that may serve as confirmation.

[0020] "Payment credentials" may include any suitable information associated with an account (e.g., a payment account and / or a transaction device associated with the account). Such information may be directly related to the account, or may be derived from information associated with the account. Examples of account information may include a primary account number or "account number" (PAN), user name, expiration date, and verification values ​​such as card verification value (CVV), dCVV, CVV2, dCVV2, and card verification code 3 (CVC3) values.

[0021] A "token" may be a substitute value for a credential. A token may be a string of numbers, letters, or any other suitable characters. Examples of tokens include payment tokens, access tokens, personal identification tokens, and the like. For example, a token may include an identifier of an account, which is a substitute for an account identifier, such as a primary account number (PAN). For example, a token may include a series of alphanumeric characters that may be used as a substitute for an original account identifier. For example, the token "4900 0000 0000 0001" may be used in place of PAN "4147 0900 0000 1234". In some embodiments, a token may be "format-retained" and may have a digital format consistent with an account identifier used in an existing transaction processing network (e.g., ISO 8583 financial transaction message format). In some embodiments, a token may be used to initiate, authorize, settle, or resolve a transaction in place of a PAN, or to represent an original credential in other systems where an original credential would normally be provided. In some embodiments, a token value may be generated so that the recovery of a PAN or other account identifier by a token value cannot be obtained by computation. Furthermore, in some embodiments, the token format may be configured to allow an entity receiving a token to identify it as a token and to identify the entity that issued the token.

[0022] "User" may include an individual. In some embodiments, a user may be associated with one or more personal accounts and / or mobile devices. In some embodiments, a user may also be referred to as a cardholder, account holder, or consumer.

[0023] A "resource provider" may be an entity that can provide resources such as goods, services, information, and / or locations. Examples of resource providers include merchants, data providers, transportation agencies, government entities, venue and residential operators, etc. A "merchant" may generally be an entity that participates in a transaction and can sell goods or services or provide access to goods or services.

[0024] A "physical item" may include a tangible and / or visible object. A physical item may be a resource provided by a resource provider at a resource provider location (e.g., a physical item listed for purchase in a store). Examples of physical items may be a box, paper with printing on it, an object such as a household appliance, etc. In some embodiments, a physical item may have an identifier printed on a surface of the physical item.

[0025] An "acquirer" may generally be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities may perform the functions of both an issuer and an acquirer. Some embodiments may encompass such a single entity, an issuer-acquirer. An acquirer may operate an acquirer computer, which may also be generally referred to as a "transmitting computer."

[0026] An "authorized entity" may be an entity that authorizes a request. Examples of authorized entities may be issuers, government agencies, document repositories, access administrators, etc. An authorized entity may operate an authorized computer.

[0027] An "issuer" may generally refer to a business entity (e.g., a bank) that maintains a user's account. An issuer may also issue payment credentials to a user that are stored on a portable device such as a cell phone, smart card, tablet, or laptop.

[0028] An "access device" may be any suitable device that provides access to a remote system. The access device may also be used to communicate with a merchant computer, a transaction processing computer, an authentication computer, or any other suitable system. The access device may generally be located at any suitable location, such as at the merchant's location. The access device may be in any suitable form. Some examples of access devices include POS or point of sale devices (e.g., POS terminals), cellular phones, PDAs, personal computers (PCs), tablet PCs, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, and the like. The access device may use any suitable contact or contactless operating mode to send or receive data from a mobile communication device or transaction device or data associated with a mobile communication device or transaction device. In some embodiments where the access device may include a POS terminal, any suitable POS terminal may be used and it may include a reader, a processor, and a computer-readable medium. The reader may include any suitable contact or contactless operating mode. For example, an exemplary card reader may include a radio frequency (RF) antenna, an optical scanner, a barcode reader, or a magnetic stripe reader to interact with a transaction device and / or a mobile device. In some embodiments, a cell phone, tablet, or other dedicated wireless device used as a POS terminal may be referred to as a mobile point of sale or "mPOS" terminal.

[0029] An "authorization request message" may be an electronic message requesting authorization for a transaction. In some embodiments, the message is sent to a transaction processing computer and / or the issuer of a payment card to request authorization for the transaction. The authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems for exchanging electronic transaction information associated with payments made by a user using a transaction device or a payment account. The authorization request message may include an issuer account identifier that may be associated with the transaction device or payment account. The authorization request message may also include additional data elements corresponding to "identification information", including, by way of example only: service code, card verification value (CVV), dynamic card verification value (dCVV), primary account number or "account number" (PAN), payment token, user name, expiration date, etc. The authorization request message may also include "transaction information", such as any information associated with the current transaction, such as transaction amount, merchant identifier, merchant location, acquirer bank identification number (BIN), card acceptor ID, information identifying the physical item being purchased, etc., and any other information that may be used to determine whether to identify and / or authorize the transaction.

[0030] An "authorization response message" may be a message in response to an authorization request. In some cases, the authorization response message may be an electronic message reply to the authorization request message generated by the issuing financial institution or a transaction processing computer. By way of example only, the authorization response message may include one or more of the following status indicators: approved - the transaction is approved; rejected - the transaction is not approved; or call center - the response is awaiting more information, the merchant must call a toll-free authorization phone number. The authorization response message may also include an authorization code, which may be a code returned by the credit card issuing bank to the merchant's access device (e.g., PA device) in response to the authorization request message in an electronic message (directly or through a transaction processing computer) indicating that the transaction is approved. The code may serve as evidence of authorization.

[0031] A "rule engine" may be a computer code capable of executing rules. In some embodiments, a rule engine may be present on a thin client. The rule engine may process link messages and link events from and to a remote computer. In some embodiments, the rule engine may make limited local decisions based on rules obtained from a remote computer or any other suitable device. In other embodiments, rules may be sent from a remote computer to a rule engine on a thin client.

[0032] "Configuration data" may define a set of rules. For example, the configuration data may define a set of rules associated with processing an interaction. For example, the configuration data may include interaction scripts / rules and / or configuration information for an interaction processed between a first software module and a second software module. For example, upon receiving the configuration data, the first software module may be configured according to the configuration data (e.g., to prepare to process an interaction based on the transaction scripts / rules and / or configuration information received from the remote computer).

[0033] A "remote computer" may include a computer that is not located near another computer. An example of a remote computer may be a network server that is located far away from a client computer that is attempting to communicate with the network server.

[0034] An "application" may include a program and / or a piece of software designed and written to meet a specific purpose for a user. An application may be bundled with a computer (e.g., a mobile device) and its system software, or may be released separately. System software is involved in running the computer itself. An application may include one or more software modules that may provide functionality to the application. For example, an application may include two software modules that may communicate with each other via an application programming interface (API). Applications built for mobile platforms (e.g., mobile devices) may be referred to as mobile applications.

[0035] A "software module" may include a portion of an application. An application may include one or more independently developed software modules that are not combinable until linked and complete the application. A software module may include one or more routines. For example, a software module may encapsulate code and data to implement a specific function. A software module may be plug-in connected to another software module with which it is desired to interface (e.g., via an API).

[0036] An "application programming interface" or "API" may include a computing interface that defines interactions between multiple software modules. The API may define the types of API calls and / or API requests that may be made, how the API calls and / or API requests may be made, the data formats that should be used, the conventions that are followed, etc. Through information hiding, modular programming of the API is supported, which allows the application programming interface to be used independently of the implementation. In other words, a second software module may hide information from a first software module by exposing specific information to the first software module only through the application programming interface.

[0037] An "acceptance process" may include an acceptance of an interaction. An acceptance process may include any suitable active steps that may facilitate acceptance of a credential for the purpose of providing a resource, such as access to a location, or a good or service.

[0038] A "server computer" may include a powerful computer or computer cluster. For example, a server computer may be a large mainframe, a small computer cluster, or a group of servers that work as a unit. In one example, a server computer may be a database server coupled to a network server. The server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the foregoing for servicing requests from one or more client computers. The server computer may include one or more computing devices and may use any of a variety of computing structures, arrangements, and compilations to service requests from one or more client computers.

[0039] "Processor" may refer to any suitable one or more data computing devices. A processor may include one or more microprocessors working together to perform the desired functions. A processor may include a CPU including at least one high-speed data processor sufficient to execute program components for executing user and / or system generated requests. A CPU may be a microprocessor such as AMD's Athlon, Duron, and / or Opteron; IBM and / or Motorola's PowerPC; IBM and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

[0040] "Memory" may be any suitable device or devices that can store electronic data. Suitable memory may include a non-transitory computer-readable medium that stores instructions that can be executed by a processor to implement the desired method. Examples of memory may include one or more memory chips, disk drives, etc. Such memory may operate using any suitable electrical, optical, and / or magnetic operating modes.

[0041] Various embodiments provide systems and methods for securely providing a first software module and a second software module in a single mobile application on a user device. The first software module executes as a thin client that is capable of exchanging data (e.g., exchange of card data, terminal data, etc.) between the second software module and a remote computer (e.g., a Kernel-in-the-cloud receiving service). The second software module is configured to manage credentials, tokens, limited-use keys, and / or any suitable data corresponding to a user of the user device. The first software module and the second software module communicate directly with each other using API calls and API responses. This system provided by an embodiment allows a user to scan an identifier of a physical item using a user device and activate the first software module to obtain access to the physical item (e.g., a secure location, product, service, secure data, etc.). The first software module and the second software module exchange interaction data associated with one or more physical items and a token associated with the user. The token can be provided from the second software module to the first software module, so that the first software module provides the token and the interaction data to the remote computer. The remote computer requests authorization for the interaction from the authorization entity computer and provides an authorization response message back to the first software module. The first software module may notify a user of the user device whether the interaction is authorized.

[0042] Embodiments provide multiple technical advantages. For example, a user can use a single device to scan an identifier of a physical item to request authorization to access the physical item. The user does not need to communicate with the resource provider in person to access the physical item. In addition, the user does not need to provide his or her user device or other user devices (e.g., payment cards) to an access device (e.g., a point of sale terminal, a door card reader at a secure location, etc.). Interactions are performed using the user's credentials (e.g., a token) to obtain one or more physical items on the user device between the first software module and the second software module. In addition, embodiments can use specific APIs to allow the first software module and the second software module to communicate with each other, and the communication uses protocols and data sets associated with secure face-to-face transactions performed by the user at an access device such as a point of sale terminal with a user device such as a payment card. This allows users to conveniently conduct e-commerce transactions while maintaining the security of conventional face-to-face transactions using physical user devices such as payment cards.

[0043] Figure 1A cloud-based transaction system 100 is shown according to some embodiments. The core components of the cloud-based transaction system 100 may include a cloud-based platform 180 and a mobile application platform 170 to manage cloud-based transactions conducted using a mobile device 101. The cloud-based platform 180 may be a "remote computer" and may be implemented using one or more computing devices or computers, such as one or more server computers, and may be associated with or operated by a cloud-based service provider, such as an authorized entity (e.g., an issuer), a payment processor, and / or other suitable entity.

[0044] For simplicity, in Figure 1 A certain number of components are shown in FIG. However, it should be understood that embodiments of the present invention may include more than one of each component.

[0045] In some embodiments, the cloud-based platform 180 can manage cloud-based accounts, provide verification functions for cloud-based transactions, manage lifecycle messages from the authorized entity computer 172 or the mobile application platform 170, and initiate lifecycle management events. The cloud-based platform 180 can also use post-payment functions to help the authorized entity computer 172 mitigate the risk of counterfeit account parameters and limit the exposure of account parameters stored on the device. For example, the cloud-based platform 180 can be used to facilitate the authorized entity computer 172 to perform periodic post-payment verification of payment transactions and / or use post-payment information to verify account parameter replenishment requests.

[0046] In addition, the transmission computer 174 can facilitate the provision of messages (e.g., authorization request messages, authorization response messages, etc.) between the cloud-based platform 180 (e.g., from the KiC processing software 190) to the processing network 194. The transmission computer 174 can be operated and / or maintained by an acquirer associated with a resource provider of the application environment 110 deployed to and / or installed on the mobile device 101.

[0047] The cloud-based platform 180 may also implement a set of key management functions that manage an issuer master derivative key (MDK) from which a limited use key (LUK) for cloud-based transactions may be derived. The cloud-based platform 180 may implement a set of configuration functions that manage the preparation and delivery of cloud-based account parameters (e.g., replacement account identifiers or tokens, initial LUKs and associated key indexes, etc.) to the mobile application platform 170 for initial setup of the mobile application 112 on the mobile device 101. The cloud-based platform 180 may also manage cloud-based accounts processed by the authorized entity computer 172, and may perform active account management functions, such as functions that generate account parameters based on a request or risk profile of a cloud-based account according to the cloud-based platform 180 risk management parameters. The cloud-based platform 180 may also maintain the account status of each cloud-based account and manage the replenishment or refresh of account parameters.

[0048] In some embodiments, the cloud-based platform 180 may also implement or have access to a token service 182 and / or a token library 184. The token service 182 may be used to generate, process, and maintain tokens, which are alternative identifiers to account identifiers. During transactions, instead of using a real account identifier (e.g., a primary account number (PAN)) to identify a user's account, a token may be used to identify the account instead. By using a token as an alternative to an account identifier, the risk of including real account information may be mitigated. As indicated above, a token may have its own set of user restrictions, and the token service 182 may manage the deployment and use of the token according to its usage restrictions. The token service 182 may communicate with a token library 184 that stores the generated tokens. Specifically, the token library 184 may maintain a mapping between a token and a real account identifier (e.g., a PAN) represented by the token. During transaction processing, the token library 184 may be queried to retrieve a real account identifier or PAN associated with the token.

[0049] In some embodiments, the on-device cloud-based transaction software 113 (which may be an example of a “second software module”) may be configured to simulate a transaction device (e.g., a smart card, credit card, debit card, etc.). Functionality typically provided by a portable device (e.g., data exchange between a card and an access device) may be simulated by the on-device cloud-based transaction software 113.

[0050] In some embodiments, the cloud-based platform 180 may also implement a kernel acceptance service in the cloud (e.g., (KiC) processing software 190). In some embodiments, the KiC processing software 190 may be configured to provide a payment acceptance service accessible by the mobile device 101 (e.g., via the acceptance device software 115, which may be an instance of a "first software module"). In some embodiments, the KiC may include functionality, logic, and / or data for processing contact or contactless transactions initiated by a portable device (e.g., mobile device 101). The KiC processing software 190 may provide functionality that would conventionally be provided by an access device. In some embodiments, the KiC processing software 190 provides a registration function that enables the acceptance device software 115 to register on the KiC processing software 190. Once registered, the acceptance device software 115 may be used to transfer data between the cloud-based transaction software 113 on the device and the KiC processing software 190. In some embodiments, the acceptance device software 115 may be executed as a thin client that is capable of exchanging data (e.g., exchange of card data, terminal data, etc.) between the cloud-based transaction software 113 on the device and the KiC processing software 190. The acceptance device software 115 may be configured to convert data between the first communication protocol used by the cloud-based transaction software 113 on the device and the second communication protocol used by the KiC processing software 190 when the communication protocols are different. In some embodiments, the acceptance device software 115 may be configured to communicate directly with the KiC processing software 190 via a communication network 192 (e.g., the Internet, a cellular network, a wireless network, etc.). However, in some embodiments, the acceptance device software 115 may communicate with the KiC processing software 190 via a separate platform (not depicted) that hosts the acceptance device software 115 executed at the mobile device 101. Although depicted as part of the mobile application 112, the acceptance device software 115 may be executed as part of a different application executed on the mobile device 101.

[0051] In some embodiments, the receiving device software 115 can be at least partially executed as a rule engine. Although operating as a rule engine, the receiving device software 115 can process link messages and link events from and to the KiC processing software 190. In some embodiments, the receiving device software 115 can make limited local decisions based on rules obtained from or provided by the KiC processing software 190 or any other suitable device. Therefore, according to these rules, the specific message protocol followed by providing data to the cloud-based transaction software 113 and / or KiC processing software 190 on the device and / or obtaining data from it can be executed by the receiving device software 115. These rules can be provided in any suitable format (for example, provided by the KiC processing software 190), and the receiving device software 115 can be configured to interpret these rules so as to promote the message transmission protocol / data exchange between the cloud-based transaction software 113 and the KiC processing software 190 on the device. In some embodiments, the receiving device software 115 can be configured to use the KiC processing software 190 to establish a secure channel so that the data exchanged between the two is encrypted and secure.

[0052] In some embodiments, the mobile application platform 170 is used to facilitate communication between the on-device cloud-based trading software 113 (e.g., operating as part of the mobile application 112 or a separate application) executed on the mobile device 101 and other entities in the cloud-based trading system 100, such as the cloud-based platform 180 and / or the authorized entity computer 172. The mobile application platform 170 can communicate with the mobile device 101 via a communication network 192 such as the Internet. In some environments, the mobile device 101 may not always have a constant network connection, and therefore one role of the mobile application platform 170 may be to intermediate requests between the on-device cloud-based trading software 113 and other entities in the cloud-based trading system 100 to ensure that requests and responses involving the on-device cloud-based trading software 113 are satisfied immediately after the network connection with the mobile device 101 is established. The mobile application platform 170 may be referred to as a remote computer and may be implemented using one or more computing devices or computers such as one or more server computers, and may be associated with or operated by the provider of the mobile application 112. The provider of the mobile application 112 may be, for example, an issuer, a bank, a third-party mobile wallet provider, a merchant, or other suitable entity. In some embodiments, the mobile application platform 170 may be associated with or operated by the same entity as the cloud-based platform 180, or they may be separate. However, the mobile application platform 170 may be associated with or operated by the same entity as the cloud-based platform 180. Figure 1180 is illustrated as a separate logical entity because the cloud-based platform 180 cannot communicate directly with the mobile device in some cases. Although in some use cases, the cloud-based platform 180 can communicate directly with the mobile device (e.g., via the receiving device software 115), it should be understood that in some embodiments, some or all of the functionality of the mobile application platform 170 can be integrated as part of the cloud-based platform 180. Examples of the mobile application platform 170 can include a mobile banking platform, a mobile wallet platform, etc.

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

[0054] The mobile application platform 170 may verify the device fingerprint of the mobile device 101 for each communication session established with the mobile device 101 or periodically (e.g., once every five communication sessions, once a month, etc.). If the device fingerprint of the mobile device indicates that the mobile device is not an authorized device for the account (e.g., the mobile device requesting to replenish the account parameters is a different device from the original device used to register the account), or if the device fingerprint indicates that the mobile device may have been hacked, the mobile application platform 170 may prevent the mobile device from communicating with the system and alert the issuer that the mobile device may have been compromised.

[0055] The mobile application platform 170 may perform enrollment functions to enroll a mobile cardholder into a cloud-based transaction program, and perform a set of configuration functions that facilitate the preparation and delivery of account parameters, configurations, and cloud-based payment device threshold parameters to the mobile application 112. The mobile application platform 170 may perform account parameter replenishment functions to facilitate the account parameter replenishment process for cloud-based accounts configured on the mobile device 101, and perform lifecycle management functions that manage lifecycle messages from the authorization entity computer 172, the cloud-based platform 180, and / or the mobile application 112. The mobile application platform 170 may also perform post-payment functions to mitigate the risk against counterfeit account parameters and limit exposure to account parameters stored on the mobile device 101, such as facilitating periodic post-payment verification of payment transactions or using post-payment information to verify account parameter replenishment requests.

[0056] In the cloud-based transaction system 100, the mobile device 101 can be used to perform cloud-based transactions facilitated by the cloud-based platform 180 and / or the mobile application platform 170. The components in the mobile device 101 may include device hardware 103, a mobile operating system (OS) 114, and an application environment 110 where the mobile application 112 resides. The mobile application 112 may include multiple different software modules (e.g., cloud-based transaction software 113 on the device and acceptance device software 115), or a separate application that provides the functions described in conjunction with these software modules may be included in the application environment 110. The device hardware 104 may include a contactless interface 108. An example of the contactless interface 108 may include one or more radio frequency (RF) transceivers configured to send and receive communications using near field communication (NFC) or other radio frequency or wireless communication protocols (e.g., Bluetooth, Bluetooth Low Energy (BLE), Wi-Fi, iBeacon, etc.). In some embodiments, the contactless interface 108 may include a contactless reader (not shown), or the contactless interface 108 may communicate with a contactless reader. The device hardware 104 may also include a network interface 109 , which may be configured to communicate via any suitable communication protocol, such as a protocol used by a communication network 192 (eg, the Internet, a cellular network, a wireless network, etc.).

[0057] The application environment 110 of the mobile device 101 may host a portion of a mobile application 112 provided by a mobile application provider (e.g., cloud-based transaction software 113 on the device). For example, the mobile application 112 may be a user's own mobile application from which the user may conduct e-commerce transactions or point-of-sale transactions with a merchant. In some embodiments, the mobile application 112 may support multiple merchants (e.g., via multiple instances of the acceptance device software 115 that may be individually hosted and / or provided by separate merchants).

[0058] According to some embodiments, the mobile application 112 may include a cloud-based transaction software 113 on the device. The cloud-based transaction software 113 on the device may be in the form of a software development kit (SDK) integrated into the mobile application 112 to support cloud-based transaction functions. The cloud-based transaction software 113 on the device may perform functions to facilitate cloud-based transactions in order to obtain account parameters (e.g., LUK and associated key index), generate transaction passwords, and deliver them to the mobile operating system (OS) 114 for transmission via the network interface 109. The network interface 109 may be configured to use any suitable wireless communication protocol. The cloud-based transaction software 113 on the device may also manage initial service profile parameters (e.g., limited use thresholds) provided after the account has been configured to ensure that requests for account parameter replenishment and other account parameter management are initiated.

[0059] The mobile application 112 may perform functions for managing the risk profile of the cloud-based account, maintaining the account status, and replenishing the account parameters for each cloud-based account based on the threshold management parameters on the device. The mobile application 112 may also manage lifecycle messages from the authorization entity computer 172 or lifecycle messages from the mobile application platform 170. The mobile application 112 may perform a set of functions for enrolling the mobile cardholder into the cloud-based transaction program, and a set of functions for managing the receipt and configuration of cloud-based account parameters and cloud-based payment device threshold parameters received from the mobile application platform 170. The mobile application 122 may also provide a consumer device cardholder verification method (CDCVM) function for cloud-based transactions, and perform a set of functions for processing and responding to messages to support post-payment processing to limit the exposure of account parameters stored on the mobile device. For example, post-payment processing may include periodic post-payment verification of payment transactions or using post-payment information to verify account parameter replenishment requests.

[0060] According to some embodiments, the mobile application 112 may include acceptance device software 115. The acceptance device software 115 may also be in the form of a software development kit (SDK) integrated into the mobile application 112 (e.g., the SDK is different from the SDK of the cloud-based transaction software 113 on the device) to support cloud-based transaction functions. In some embodiments, the acceptance device software 115 can communicate with the KiC processing software 190 to exchange transaction data and / or card data.

[0061] In some embodiments, an API 116 is provided to enable data to be exchanged between the on-device cloud-based transaction software 113 and the acceptance device software 115. For example, the API 116 may be coded and executed in accordance with the mobile operating system 114 of the mobile device 101, and may include programming function calls to allow the on-device cloud-based transaction software 113 and the acceptance device software 115 to exchange transaction data and / or card data between each other.

[0062] Once the mobile device 101 and mobile application 112 have been configured with account parameters, the cloud-based transaction software 113 on the device can conduct cloud-based transactions by interacting with the KiC processing software 190 via the receiving device software 115. The portable communication device 101 may include an input component, such as one or more RF transceivers that can send and receive communications using NFC or other radio frequency or wireless communication protocols such as Bluetooth, BLE, Wi-Fi, iBeacon, etc. In some embodiments, the portable communication device 101 may include an input component, such as an optical code scanner or reader or camera, to conduct transactions using QR codes (Quick Response Codes), bar codes, etc.

[0063] To conduct a cloud-based transaction, a user can download and install a mobile application 112. Using the interface provided by the mobile application 112, the user can store payment credentials (e.g., payment account number, expiration date, CVV code, billing address, etc.). The mobile application 112 can be used to capture one or more identifiers (e.g., barcodes, QR codes, etc.) of one or more physical items. When the user is ready, a selection can be made at the user interface provided by the mobile application 112 to indicate that the transaction is about to begin. For example, the user can select a "checkout option" to initiate the transaction. The transaction can be performed using the cloud-based transaction software 113 on the device to simulate the card function, while the acceptance device software transmits data between the cloud-based transaction software 113 on the device and the KiC processing software 190 that performs cloud-based acceptance processing (e.g., functions traditionally provided by the merchant access device). Therefore, the user can use his own device to select the physical items to be purchased and conduct the payment transaction without having to do with the additional device operated by the merchant.

[0064] The mobile application 112 may be a merchant-specific application (e.g., an in-store application). Subsequently, the user of the portable communication device 101 may scan the physical item and initiate a transaction. The transaction data may be received by the accepting device software 115, and the payment credentials may be requested by the accepting device software 115 from the cloud-based transaction software 113 on the device. The cloud-based transaction software 113 on the device may provide (e.g., via the API 116) 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 accepting device software 115 to identify the user's account and additional information such as limited-use account parameters or information derived from the limited-use account parameters (e.g., a transaction password generated from a LUK). For example, in some embodiments, the account identifier or token and the additional information (e.g., transaction password, account parameters, etc.) may be sent to the KiC processing software 190 via the accepting device software 115 in a message in response to a series of commands received from the KiC processing software 190. The KiC processing software 190 may generate an authorization request message including an account identifier or token and additional information such as a transaction password and other transaction data, and forward the authorization request message to a transmission computer 174 associated with the merchant. The authorization request message may then be sent by the transmission computer 174 to the processing network 194.

[0065] The processing network 194 may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception file services, transaction scoring services, and clearing and settlement services. An exemplary payment processing network may include VisaNet ⑩. Payment processing networks such as VisaNet™ are capable of processing credit card transactions, debit card transactions, and other types of commercial transactions. Specifically, VisaNet™ may include a VIP system (Visa Integrated Payment System) that processes authorization requests and a Base II system that performs clearing and settlement services.

[0066] Upon receiving the authorization request message, the processing network 194 may forward the authorization request message received from the transmission computer 174 to the corresponding authorization entity computer 172 of the account of the user of the mobile device 101. After the authorization entity computer 172 receives the authorization request message, the authorization request message may be analyzed, and the information in the authorization request message may be verified. For example, the authorization entity computer 172 may verify that the transaction password is generated by a valid LUK and has not exceeded a set of one or more restricted use thresholds associated with the LUK. In some embodiments, some or all of the information in the authorization request message may also be sent to the cloud-based platform 180 for verification and processing. For example, if the authorization entity computer 172 cannot verify the transaction password, the processing network 194 or the authorization entity computer 172 may forward the transaction password to the cloud-based platform 180 for verification.

[0067] The authorization response message is then sent back to the transaction processing network 194 to indicate whether the current transaction is authorized (or not authorized). The processing network 194 then forwards the authorization response message back to the transmission computer 174. In some embodiments, even if the authorization entity computer 172 has authorized the transaction, the transaction processing network 194 may still deny the transaction, for example, depending on the value of the fraud risk score or depending on whether the limited-use account parameters are verified by the cloud-based platform 180. The transmission computer 174 then sends the authorization response message to the KiC processing software 190, which in turn sends an indication that the transaction is authorized or denied to the acceptance device software 115. This indication may be presented at the mobile device 101 by the acceptance device software 115 via any suitable interface.

[0068] At the end of the day, a clearing and settlement process may be performed by the processing network 194. The clearing process is the process of exchanging financial details between the acquirer and the issuer to facilitate issuance to the customer's payment account and to reconcile the user's settlement position. It should be understood that any of the transmission computer 174, the processing network 194, the authorization entity computer 172, the cloud-based platform 180, and / or the mobile application platform 170 may be referred to as a remote computer and may include one or more computing devices, such as one or more computers or server computers, to enable an entity to communicate with other entities in the cloud-based transaction system 100, and / or perform one or more of the functions described herein.

[0069] Additional information regarding the on-device cloud-based transaction software 113 and limited-use keys can be found in U.S. Patent No. 9,972,005, entitled “Cloud based Transactions Methods and Systems,” issued on May 15, 2018, the contents of which are incorporated herein by reference in their entirety for all purposes. In addition, information regarding the KiC processing software 190 (also referred to as “kernel in the cloud”) can be found in U.S. Patent Application No. 15 / 631,716, entitled “Adapter for Providing Unified Transaction Interface,” filed on June 23, 2017, and U.S. Provisional Application No. 62 / 641,712, entitled “Rules Engine for Communication Round Trips Optimization of Kernel-in-Cloud Payment Transaction,” filed on March 12, 2018, each of which is incorporated by reference in its entirety for all purposes.

[0070] Figure 2 An exemplary method 200 according to an embodiment of the present invention is shown. The method 200 may be performed by Figure 1 The steps described in conjunction with method 200 may be performed in any suitable order. In some embodiments, more or fewer steps may be included.

[0071] Prior to executing method 200, the user may download mobile application 112. As discussed above, mobile application 112 may be a merchant-specific application. Method 200 may begin at step 1, where the user may log into a user account associated with a merchant. In some embodiments, the user may enter any suitable credentials (e.g., a username, password, biometric input such as fingerprint, retinal scan, facial detection, etc.). These credentials may be sent by mobile application 112 to mobile application platform 170 for authentication. If the credentials are valid, the user may access functionality provided by mobile application 112.

[0072] In some embodiments, the mobile application 112 may include a software module, such as an on-device cloud-based transaction (ODCBT) software 113. The ODCBT software 113 may be configured to manage payment credentials, tokens, limited-use keys, or any suitable data corresponding to a user. In some embodiments, the ODCBT software 113 may be configured to provide a digital wallet function to the user.

[0073] At step 2, the user may enter payment credential information using an interface provided by the ODCBT software 113. For example, the user may enter a personal account number (PAN), expiration date, CVV, billing address, etc. Once entered, the ODCBT software 113 may send the data to the mobile application platform 170. The mobile application platform 170 may be configured to store the data in association with the user's user account.

[0074] At step 3, the mobile application platform 170 may request a token for the payment credential from the token service 182. The token service 182 may be configured to generate the token and associate the token with the payment credential information. In some embodiments, the token service 182 also generates a cryptogram. In some embodiments, the cryptogram may be generated using a restricted use key (LUK) associated with a set of one or more restricted use thresholds that restrict the use of the LUK. The token service 182 may generate the token and / or LUK and send this information to the ODCBT software 113 via the mobile application platform 170. The ODCBT software 113 may store such data in Figure 1 The LUK is stored in a secure memory space local to the portable communication device 101 and accessible to the ODCBT software 113. In some embodiments, the ODCBT software 113 may encrypt this data before storage. In this way, the token and password may be provided to the mobile application 112 to perform subsequent transactions. Transactions may be authorized based at least on whether the use of the LUK exceeds a set of one or more restricted use thresholds.

[0075] In at least some embodiments, the token may be generated by the token service 182 and the mobile device 101 may be configured with the LUK. Once configured, the mobile device 101 (e.g., the ODCBT software 113) may be configured to generate a password for the transaction. The token and password may be provided to any suitable computing component (e.g., the receiving device software 115).

[0076] As an illustrative example, the ODCBT software 113 may receive user credentials (e.g., PAN) via an interface provided by the ODCBT software 113 on the mobile application 112 via user input. The ODCBT software 113 may generate a token request including the user credentials and send it to the mobile application platform 170. The mobile application platform 170 then requests a token for the user credentials from the token service 182. If the token exists, the token service 182 may determine the token associated with the user credentials, otherwise the token service 182 may generate a token. The token service 182 then provides the token to the mobile application platform 170, which provides the token to the ODCBT software 113. The ODCBT software 113 then receives the token from the mobile application platform 170, and may store the token in any appropriately secure manner.

[0077] At step 4, the acceptance device software 115 may perform a registration process with the KiC processing computer 190. In some embodiments, the registration process may be performed when the mobile application 112 is installed or at another suitable time. In some embodiments, the registration process may include providing connection credentials to the acceptance device software 115 that enable the acceptance device software 115 to connect with and exchange information with the KiC processing computer 190. As discussed above, the KiC processing computer 190 may perform acceptance processing (e.g., point-of-sale terminal processing) on ​​behalf of a physical (and in some cases mobile) access device.

[0078] At step 5, the user may participate in a shopping experience in which he or she may scan a barcode and / or QR code (or any suitable identifier) ​​via an input device (e.g., an image capture device) of the user's mobile phone (e.g., an instance of mobile device 101). For example, the mobile application 112 may include a scanning module 112C that may communicate with the image capture device to obtain one or more identifiers. The one or more identifiers may be collected by a detected physical item collection module 112D. Once the user is ready to proceed, the user may initiate an interaction using a physical item acquisition module 112E to obtain the scanned physical item. For example, at some point in time, the user may wish to purchase the physical item and may select an option (e.g., a checkout button) to initiate a transaction for a total amount of the combined physical items (which may include sales tax or other suitable fees, taxes, and / or surcharges). The acceptance device software 115 may be configured to receive the physical item information and calculate the total amount of the transaction.

[0079] The receiving device software 115 may receive and / or generate interaction data based on one or more identifiers received from the physical item acquisition module 112E. The interaction data includes data related to the interaction and / or data recorded during the interaction. For example, in some embodiments, the interaction data may be transaction data. The transaction data may include an amount, a transaction code, a currency code, a date and / or time, a resource provider identifier, and / or any other suitable data used in the interaction or used by the ODCBT software 113 to determine whether to provide at least one token to continue the interaction.

[0080] At step 6, the accepting device software 115 may retrieve any suitable transaction scripts / rules and / or configuration information from the KiC processing computer 190. For example, the accepting device software 115 may be configured at least in part with a rule engine that may interpret rules provided by the KiC processing computer 190 that define a specific messaging protocol to be used to exchange data between the KiC processing computer 190 and the ODCBT software 113. The accepting device software 115 may be configured to use these rules to facilitate the exchange of data between the KiC processing computer 190 and the ODCBT software 113. In some embodiments, the accepting device software 115 may convert between one communication protocol of the ODCBT software 113 and another communication protocol of the KiC processing computer 190 if the protocols are different. In some embodiments, the accepting device software 115 may obtain these rules at any suitable time (e.g., at registration or another suitable time).

[0081] Additionally, at step 6, the recipient device software 115 provides the interaction data to the KiC processing computer 190. The KiC processing computer 190 provides configuration data that defines a set of rules associated with the interaction processing. For example, the configuration data includes transaction scripts / rules and / or configuration information for the interactions to be processed between the recipient device software 115 and the ODCBT software 113. Upon receiving the configuration data, the recipient device software 115 may be configured according to the configuration data (e.g., prepared to process the interaction based on the transaction scripts / rules and / or configuration information).

[0082] At step 7, the acceptance device software 115 may perform operations according to the rules provided by the KiC processing computer 190 to obtain the card data from the ODCBT software 113. The acceptance device software 115 may access the card data via any suitable API (e.g., Figure 1The ODCBT software 113 may communicate with the ODCBT software 113 via the APIs 116 of the token service 182. For example, the acceptance device software 115 may request card data from the ODCBT software 113 via these APIs. The ODCBT software 113 may generate transaction data (e.g., EMV® card data) and provide this data to the acceptance device software 115 (e.g., via the APIs 116). In some embodiments, the transaction data may include a token and / or password generated by the token service 182 and may be stored in the local memory of the mobile device 101.

[0083] For example, at step 7, the receiving device software 115 may generate an API call. The API call may include a request for at least one token from the ODCBT software 113. In some embodiments, the API call may also include a request for a password associated with the token. For example, the token may be a substitute value for a credential (e.g., PAN), and the password includes a piece of obfuscated text, such as an encrypted text of a credential (e.g., such as dCVV (dynamic card verification value)). The receiving device software 115 and the ODCBT software 113 may communicate using API calls and responses instead of APDU (application protocol data unit) commands and responses. The API calls and responses may include a larger amount of information than APDU commands and responses, and therefore the receiving device software 115 and the ODCBT software 113 may be advantageously configured to perform transactions during a single round of communication.

[0084] The API call may include interaction data associated with one or more physical items, including, for example, a transaction amount, a currency code, a resource provider identifier, a time, and / or any other suitable information capable of describing the interaction and / or used by the ODCBT software 113 to determine whether to proceed with the interaction. For example, in some embodiments, the API call may include recipient device software 115 data, including, for example, a recipient device software identifier, a recipient device software version number, a recipient device software certificate, a cryptographic key that verifies the authenticity of the recipient device software 115, and the like. The recipient device software 115 then provides the API call to the ODCBT software 113. The API call may be provided directly from the recipient device software 115 to the ODCBT software 113 without passing through a module or hardware (e.g., a secure element) that is not part of the recipient device software 115 or the ODCBT software 113.

[0085] Upon receiving the API call, the ODCBT software 113 determines whether to provide the token to the recipient device software 115 based on the interaction data included in the API call. In some embodiments, the ODCBT software 113 can determine whether the recipient device software 115 is authentic. For example, the ODCBT software 113 can verify the recipient device software certificate, the recipient device software public key, and / or the recipient device software signature known to those skilled in the art.

[0086] The ODCBT software 113 can determine whether to respond to the API call based on the validity of the API call and / or the receiving device software 115. If the ODCBT software 113 determines to respond, the ODCBT software 113 generates an API response. The API response includes a token. In some embodiments, the API response may also include a password associated with the token. The password may be generated by the ODCBT software 113. The ODCBT software 113 then provides the API response to the receiving device software 115. The API response may be provided directly to the receiving device software 115.

[0087] It should be appreciated that although the acceptance device software 115 is described as obtaining the card data from the ODCBT software 113, in some embodiments, the acceptance device software 115 may be configured to obtain the card data via Figure 1 Thus, if the user wishes to use a transaction device other than that known to the ODCBT software 113, the user can touch or otherwise bring the transaction device near the mobile device 101 so that the acceptance device software 115 can receive the data via the contactless interface 108.

[0088] At step 8, the recipient device software 115 may send the data obtained from the ODCBT software 113 to the KiC processing computer 190. In some embodiments, step 8 may include exchanging any suitable number of messages and / or data between the ODCBT software 113 and the KiC processing computer 190 via the recipient device software 115 (and API 116).

[0089] For example, at step 8, the recipient device software 115 may provide the token to the KiC processing computer 190 after receiving the token from the ODCBT software 113. In some embodiments, if the interaction data is not provided to the KiC processing computer 190 at step 6, the recipient device software 115 may provide the interaction data together with the token to the KiC processing computer 190.

[0090] At step 9, the KiC processing computer 190 may process the transaction data to generate an authorization request message. The authorization request message may include at least the token and the interaction data. The authorization request message is sent to the transmission computer 174.

[0091] At step 10 , after receiving the authorization request message, the transmission computer 174 provides the authorization request message to the processing network 194 .

[0092] At step 11, after receiving the authorization request message, the processing network 194 provides the authorization request message to the authorization entity computer 172. In some embodiments, the authorization entity computer 172 may communicate with the token service 182 to obtain the credentials associated with the token (e.g., PAN). The processing network 194 may modify the authorization request message to replace the token with the credentials. The processing network 194 then provides the authorization request message including the interaction data and the credentials to the authorization entity computer 172 for authorization.

[0093] After receiving the authorization request message, the authorization entity computer 172 determines whether to authorize or deny the interaction. For example, the authorization entity computer 172 can accept or deny the interaction. The authorization entity computer 172 can generate an authorization response message including the user credentials and an indication of whether the interaction is authorized. In some embodiments, the authorization response message can also include the interaction data. In other embodiments, the authorization response message can also include a token or a credential.

[0094] At step 12 , after generating the authorization response message, the authorization entity computer 172 sends the authorization response message to the processing network 194 .

[0095] At step 13, after receiving the authorization response message, processing network 194 sends the authorization response message to transmission computer 174. In some embodiments, if the authorization response message includes credentials, communication network 194 can communicate with token service 182 to obtain a token. Then, before sending the authorization response message to transmission computer 174, processing network 194 can modify the authorization response message to replace the credentials with the token.

[0096] At step 14 , after receiving the authorization response message from the processing network 194 , the transmission computer 174 sends the authorization response message to the KiC processing computer 190 .

[0097] At step 15, upon receiving the authorization response message, the KiC processing computer 190 may provide an indication of authorization / denial (and, in some embodiments, transaction data) to the mobile application platform 170. Upon receipt or at another suitable time, the mobile application platform 170 and / or the KiC processing computer 190 may provide the indication of authorization / denial (and transaction data) via an interface provided by the mobile application 112. For example, the KiC processing computer 190 may provide the authorization response message or an indication of whether the interaction is authorized to the mobile application 112. The mobile application 112 may present the indication of whether the interaction is authorized to the user of the mobile application 112. In some embodiments, the indication of whether the interaction is authorized may allow the user to obtain one or more physical items.

[0098] Figure 3 A flow chart illustrating details of communication between a first software module and a second software module according to an embodiment is shown. Figure 3 The method described in the accompanying drawings will be described in the context of a first software module communicating with a second software module within an application on a mobile device. Figure 3 The method described in the embodiment may be performed by a mobile device 300, which includes a mobile application 302 and a remote computer 308, wherein the mobile application includes a first software module 304 and a second software module 306. However, it should be understood that the present invention may be applicable to other situations.

[0099] Prior to step 320, the user may use the mobile device 300 to scan or otherwise obtain one or more identifiers of the one or more physical items. For example, the mobile device 300 may include an input element (now shown), which may be a scanner capable of capturing a QR code via a camera or other suitable device. The user may use the mobile device 300 to scan the one or more identifiers, and may then choose to perform an interaction within the mobile application 302 to obtain and / or gain access to the one or more physical items. The first software module 304 may determine interaction data based on the one or more identifiers. For example, the first software module 304 may determine a total amount, a currency code, a resource provider identifier, etc. to be included in the interaction data.

[0100] In some embodiments, the user can select a user device to use during the interaction. For example, the mobile device 300 can receive a selection of a selected user device from a plurality of user devices presented on the mobile device. For example, two user devices can be presented to the user. The first user device can be simulated by the second software module 306. The second user device can be a physical device that the user can bring into contact with the mobile device 300 during the interaction. As an example, the user can select the first user device to continue the interaction described below.

[0101] At step 320, the first software module 304 provides the interaction data to the remote computer 308. For example, the first software module 304 may communicate with the remote computer 308 over the air. In some embodiments, the first software module 304 may request configuration data from the remote computer 308. The configuration data may include transaction scripts / rules and / or configuration information for the interactions to be processed between the first software module 304 and the second software module 306. For example, the configuration data may include instructions for the first software module 304 to provide an API call to the second software module 306 to at least obtain a token. The configuration data may indicate data that should be included in the API call from the first software module 304 to the second software module 306. For example, the configuration data may indicate that the API call includes data fields for an amount, a resource provider identifier, and an interaction environment selection for a contact interaction.

[0102] At step 325, after receiving the interaction data from the first software module 304, the remote computer 308 may determine the configuration data of the first software module 304 to be provided to the mobile application 302. For example, the remote computer 308 may store a plurality of configuration data corresponding to different interaction environments. The remote computer 308 may determine which of the plurality of configuration data to provide to the first software module 304 based on the interaction data. For example, the interaction data may include a first software module identifier. The remote computer 308 may determine which of the plurality of configuration data to provide to the first software module 304 based on a pre-stored first software module identifier (e.g., in Figure 2 4 ), determining that the first software module identifier indicates that the first software module 304 can interact with the second software module 306 in the contact-type interaction environment.

[0103] At step 330, the remote computer 308 then provides the configuration data to the first software module 304. In some embodiments, the remote computer 308 may provide an indication to the first software module that an authorization request is to be initiated.

[0104] At step 335, after receiving the configuration data from the remote computer 308, the first software module 304 may be configured according to the configuration data (e.g., to prepare to process interactions based on the transaction scripts / rules and / or configuration information). The first software module 304 generates an API call based on the configuration data to provide to the second software module 306. The API call may provide the interaction data to the second software module 306 in a format specified by the configuration data from the remote computer 308. In addition, the API call may request data from the second software module 306. For example, the API call may request a token, a password, an expiration date, and / or any other suitable information maintained by the second software module 306 to simulate a user device.

[0105] At step 340 , after generating the API call, the first software module 304 provides the API call directly to the second software module 306 .

[0106] At step 345, upon receiving the API call from the first software module 304, the second software module 306 determines whether to respond to the API call. For example, the second software module 306 can determine whether the first software module 304 is authentic, as described in further detail herein. The second software module 306 can then generate an API response including second software module data, including, for example, a token.

[0107] At step 350, after generating the API response, the second software module 306 provides the API response to the first software module 304. In some embodiments, rather than performing several subsequent command and response messages between the first software module 304 and the second software module 306, the first software module 304 and the second software module 306 can transmit all the data necessary to complete the interaction in a single API call and API response. For example, in some embodiments, rather than the second software module 306 providing a token in response to a token request, in a second response providing a password in response to a password request, the second software module 306 can provide the token and the password (and any other suitable user device data emulated by the second software module 306) to the first software module 304 in a single message. This can be achieved because the first software module 304 and the second software module 306 do not need to follow standard APDU commands and responses, which can handle small amounts of data in each command / response.

[0108] API calls and API responses between the first software module 304 and the second software module 306 can be provided directly to the second software module 306 and the first software module 304, respectively. Therefore, embodiments do not require a hardware controller (e.g., a controller element or a controller module) to communicate between the first software module 304 and the second software module 306.

[0109] At step 360, after receiving the API response from the second software module 306, the first software module 304 provides the interaction data and the token associated with the user to the remote computer 308. The first software module 304 may provide the data to the remote computer 308 based on the configuration data. For example, the configuration data may indicate what data should be provided to the remote computer 308 at step 360 and in what format.

[0110] After receiving the interaction data and the token from the first software module 304 of the mobile device 300, the remote computer 308 may generate an authorization request message (not shown) including the interaction data and the token. The remote computer 308 sends the authorization request message to the authorization entity computer via the transmission computer and processing network, as shown in FIG. Figure 2 The authorization entity computer determines whether the interaction is authorized and provides an authorization response message to the remote computer 308 via the transmission computer and processing network. The authorization response message may include an indication of whether the interaction is authorized.

[0111] Upon receiving the authorization response message, at step 370, the remote computer 308 sends the authorization response message to the first software module 304. The first software module 304 can then determine whether the authorization response message indicates that the interaction is authorized. For the described example, the first software module 304 can receive an indication that the interaction is authorized. The mobile application 302 can present the indication to the user of the mobile device 300 via a display or other suitable device. The user can then obtain one or more physical items corresponding to the one or more identifiers. In some embodiments, the user can use the indication that the interaction is authorized to access the one or more physical items. For example, the indication that the interaction is authorized can serve as a receipt or access code.

[0112] Figure 4 A block diagram of a building access system 400 is shown according to an embodiment. Figure 4 A mobile device 401 (eg, Figure 1 The mobile device 401 may interact with a mobile application platform 470 and a building access security computer 490 (eg, a device that manages access to the building 402).

[0113] The access transaction may be described as follows, where a user will use mobile device 401 to scan an identifier at a location in building 402. For example, a locked door at building 402 may have a QR code (or other suitable identifier) ​​printed on the door. The user may scan the QR code on the door using a QR code scanner on mobile device 401. Mobile application 412 displays an "unlock" button or other element to allow the user to select an option to unlock the scanned door. The user then selects to unlock the door in mobile application 412. The first software module 415 will then receive the identifier associated with the door and any other information embedded in the scanned QR code. The first software module 415 will then provide the interaction data to a building access security computer 490 (e.g., a remote computer).

[0114] After receiving the interaction data, the building access security computer 490 then provides the configuration data to the first software module 415. The first software module 415 will communicate with the second software module 413 of the mobile application 412 via the API 416 of the mobile OS 414. The first software module 415 provides the interaction data to the second software module 413 in a manner consistent with the configuration data provided by the building access security computer 490. For example, the first software module 415 can request a token held by the second software module 413. The token can be a credential that proves that a user can enter the building 402 via a locked door. The second software module 413 can evaluate the interaction data including the received identifier associated with the door. For example, the second software module 413 can determine whether the token should be used to attempt to access the building 402 via the locked door. The second software module 413 determines that the received identifier matches an identifier associated with a token (e.g., a token that can be used to attempt to unlock the door). The second software module 413 can provide the token to the first software module 415.

[0115] Upon receiving the token and any other suitable data (e.g., a password, etc.) from the second software module 413 via the API 416, the first software module 415 sends the interaction data and the token to the building access security computer 490. The building access security computer 490 then determines whether the interaction is authorized (e.g., to allow the user to access the building). For example, the building access security computer 490 may determine whether the token is sufficient to prove that the user is authorized to access the building 402. In some embodiments, the building access security computer 490 may send a message indicating that the interaction is authorized to the mobile device 401 and / or an electromechanical lock at a door of the building 402.

[0116] Technical advantages

[0117] Using the technology discussed herein, the time required to conduct a transaction can be reduced because a common device can be used to store payment credentials, obtain transaction data, and initiate transaction acceptance processing. Unlike using one device to provide payment credentials and using another device for acceptance processing, this function can be provided in a single device, thereby reducing the overall processing resources required for transaction processing. The technology herein enables users to scan physical items, check out, and pay without searching for access devices in stores. In addition, through the host card emulation function provided by the cloud-based transaction software on the device and the acceptance processing promoted by the acceptance device software, the transaction can be regarded as a card-present transaction because the cloud-based transaction software on the device is interacting with the acceptance device software locally. Therefore, the transaction is safer than conventional e-commerce transactions.

[0118] Embodiments provide a number of additional technical advantages. For example, because the application on the mobile device includes both the first software module and the second software module, the complexity of the mobile device can be reduced. For example, the mobile device does not require additional hardware components integrated into the mobile device to allow various components to communicate. For example, since multiple security elements and controllers that communicate between security elements are not required, the mobile device can be less complex. In addition, since the first software module and the second software module are included in the application, the application can be easily updated and provided to the mobile device. When the application is updated, the mobile device will not be outdated because the software module of the application is not integrated into the security element (or other hardware) of the mobile device.

[0119] Embodiments also provide technical advantages of secure communication of sensitive data. For example, the first software module and the second software module can securely communicate with each other via API calls and API responses. The application programming interface exposed by the second software module storing the token can hide the token more securely than the previous method of digital wallets storing tokens and providing the tokens to merchants after request to prevent malicious token requests.

[0120] It should be understood that any embodiment of the present invention can be implemented in the form of control logic using hardware (e.g., an application specific integrated circuit or a field programmable gate array) and / or using computer software, wherein a general purpose programmable processor is modular or integrated. As used herein, a processor includes a single-core processor, a multi-core processor on the same integrated chip, or multiple processing units on a single circuit board or networked. Based on the present disclosure and the teachings provided herein, a person of ordinary skill in the art will know and understand other methods and / or methods of implementing embodiments of the present invention using hardware and a combination of hardware and software.

[0121] Any software component or function described in this application may be implemented as software code executed by a processor using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift or a scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission, and suitable media include random access memory (RAM), read-only memory (ROM), magnetic media such as a hard drive or floppy disk, or optical media such as a compact disk (CD) or a digital versatile disk (DVD), flash memory, etc. The computer-readable medium may be any combination of such storage or transmission devices.

[0122] Such programs can also be encoded and sent using carrier signals adapted to be transmitted via wired, optical and / or wireless networks that meet multiple protocols including the Internet. Therefore, a computer-readable medium according to an embodiment of the present invention can be created using a data signal encoded with such a program. A computer-readable medium encoded with program code can be packaged with a compatible device or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or inside a single computer product (e.g., a hard drive, a CD, or an entire computer system), and can be present on or inside different computer products within a system or network. A computer system can include a monitor, a printer, or other suitable displays for providing any result mentioned herein to a user.

[0123] The above description is illustrative and non-restrictive. After those skilled in the art have read this disclosure, many variations of the present invention will become apparent to them. Therefore, the scope of the present invention should not be determined with reference to the above description, but should be determined with reference to the pending claims and their full scope or equivalents.

[0124] One or more features of any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the present invention.

[0125] As used herein, the use of "a," "an," or "the" is intended to mean "at least one" unless clearly indicated to the contrary.

Claims

1. A method for interactive processing, the method comprising: a) receiving, at a first software module on a mobile device, one or more identifiers associated with one or more physical items external to the mobile device, the mobile device comprising the first software module configured to perform acceptance processing and a second software module configured to manage payment credentials and / or tokens and emulate a user device associated with a user, the one or more identifiers being read by the mobile device using an input component in a purchase transaction; After step a), b) receiving, by the first software module, configuration data from a remote computer, the configuration data allowing the second software module to communicate with the remote computer via the first software module; c) receiving, at the first software module, an indication that an authorization request is to be initiated; d) exchanging interaction data associated with the one or more physical items and a token associated with the user between the first software module and the second software module of the mobile device by: The first software module provides an API call including the interaction data to the second software module, wherein the second software module evaluates the interaction data and the first software module, and determines whether to respond to the API call according to whether the first software module is authentic and the interaction data; as well as In response to the evaluating, receiving, by the first software module, an API response including the token from the second software module; and e) the first software module sending the interaction data and the token associated with the user to a remote computer, the remote computer comprising acceptance processing software, the first software module having been registered on the acceptance processing software so that the first software module can exchange information with the remote computer, the sending causing the remote computer to generate an authorization request message for the purchase transaction, the authorization request message comprising the interaction data and the token. 2 . The method of claim 1 , wherein the first software module is hosted by a resource provider, and wherein the mobile device is operated by an entity other than the resource provider associated with the first software module. 3 . The method of claim 1 , wherein providing the API call by the first software module to the second software module is based on the configuration data.

4. The method of claim 1, wherein the API response further comprises a password associated with the token. 5 . The method of claim 1 , wherein the first software module communicates directly with the second software module via the API call and the API response.

6. The method of claim 1, wherein the one or more physical items relate to an interaction between the user of the mobile device and a resource provider hosting the first software module, wherein the remote computer provides the authorization request message to an authorization entity computer, and wherein the authorization entity computer determines whether to authorize the interaction and generates an authorization response message, and wherein the method further comprises: receiving, by the first software module, from the remote computer, the authorization response message including an indication of whether the interaction is authorized; as well as The indication of whether the interaction is authorized to the user is displayed by the first software module.

7. The method of claim 1, wherein the input component comprises a code scanner, reader, camera, or one or more RF transceivers that send and receive communications using NFC, radio frequency, or wireless communication protocols including Bluetooth, BLE, Wi-Fi, and iBeacon.

8. The method of claim 1, wherein before exchanging the interaction data associated with the one or more physical items and the token associated with the user between the first software module and the second software module of the mobile device, the method further comprises: receiving, by the second software module of the mobile device, the token from a mobile application platform; as well as The token is stored by the second software module of the mobile device in a secure element of the mobile device, whereby the first software module cannot access the token without the second software module.

9. A mobile device, comprising: one or more processors; as well as one or more memories storing computer executable instructions that, when executed by the one or more processors, cause the mobile device to perform steps comprising: a) receiving, at a first software module on the mobile device, one or more identifiers associated with one or more physical items external to the mobile device, the mobile device comprising the first software module configured to perform acceptance processing and a second software module configured to manage payment credentials and / or tokens and emulate a user device associated with a user, the one or more identifiers being read by the mobile device using an input component in a purchase transaction; After step a), b) receiving, by the first software module, configuration data from a remote computer, the configuration data allowing the second software module to communicate with the remote computer via the first software module; c) receiving, at the first software module, an indication that an authorization request is to be initiated; d) exchanging interaction data associated with the one or more physical items and a token associated with the user between the first software module and the second software module of the mobile device by: The first software module provides an API call including the interaction data to the second software module, wherein the second software module evaluates the interaction data and the first software module, and determines whether to respond to the API call according to whether the first software module is authentic and the interaction data; as well as In response to the evaluating, receiving, by the first software module, an API response including the token from the second software module; and e) the first software module sending the interaction data and the token associated with the user to a remote computer, the remote computer comprising acceptance processing software, the first software module having been registered on the acceptance processing software so that the first software module can exchange information with the remote computer, the sending causing the remote computer to generate an authorization request message for the purchase transaction, the authorization request message comprising the interaction data and the token.

10. The mobile device according to claim 9, further comprising: Safety elements; as well as The input component.

11. The mobile device of claim 9, wherein before exchanging the interaction data associated with the one or more physical items and the token associated with the user between the first software module and the second software module of the mobile device, further comprising: A selection of a selected user device of a plurality of user devices presented on the mobile device is received, wherein the selected user device is the user device.

12. The mobile device of claim 9, wherein before receiving, at the first software module, the one or more identifiers associated with the one or more physical items, wherein the steps further comprise: receiving, by the second software module via an interface provided by the second software module, user credentials; sending, by the second software module, a token request including the user credentials to a mobile application platform, wherein the mobile application platform requests the token for the user credentials from a token service; as well as The token is received by the second software module from the mobile application platform.

13. The mobile device of claim 9, wherein providing the API call by the first software module to the second software module is based on the configuration data.

14. The mobile device of claim 9, wherein the first software module is hosted by a resource provider, and wherein the mobile device is operated by an entity other than the resource provider associated with the first software module.

15. The mobile device of claim 9, wherein the one or more identifiers include one or more barcodes and / or one or more QR codes.

16. The mobile device of claim 9, wherein the operations further comprise: A password associated with the token is exchanged between the first software module and the second software module of the mobile device.

17. A system for interactive processing, the system comprising: Remote computer; as well as A mobile device comprising: one or more processors; and one or more memories storing computer-executable instructions that, when executed by the one or more processors, cause the mobile device to perform operations including: a) receiving, at a first software module on the mobile device, one or more identifiers associated with one or more physical items external to the mobile device, the mobile device comprising the first software module configured to perform acceptance processing and a second software module configured to manage payment credentials and / or tokens and emulate a user device associated with a user, the one or more identifiers being read by the mobile device using an input component in a purchase transaction; After step a), b) receiving, by the first software module, configuration data from a remote computer, the configuration data allowing the second software module to communicate with the remote computer via the first software module; c) receiving, at the first software module, an indication that an authorization request is to be initiated; d) exchanging interaction data associated with the one or more physical items and a token associated with the user between the first software module and the second software module of the mobile device by: The first software module provides an API call including the interaction data to the second software module, wherein the second software module evaluates the interaction data and the first software module, and determines whether to respond to the API call based on whether the first software module is authentic and the interaction data; and In response to the evaluating, receiving, by the first software module, an API response including the token from the second software module; and e) The first software module sends the interaction data and the token associated with the user to the remote computer, the remote computer comprising acceptance processing software, the first software module having been registered on the acceptance processing software so that the first software module can exchange information with the remote computer, the sending causing the remote computer to generate an authorization request message for the purchase transaction, the authorization request message including the interaction data and the token.

18. The system of claim 17, wherein the remote computer further comprises: one or more processors; as well as one or more memories storing computer-executable instructions that, when executed by the one or more processors, cause the mobile device to perform operations including: providing the configuration data by the remote computer, wherein the configuration data defines a set of rules associated with an interaction process; receiving, by the remote computer, the interaction data and the token associated with the user from the mobile device; generating, by the remote computer, the authorization request message including the interaction data and the token; as well as The authorization request message is sent by the remote computer to an authorization entity computer so that the authorization entity computer determines whether to authorize the interaction.

Images