Provisioning method and system with message conversion

Abstract

A method is disclosed. The method includes receiving, from a communication device, a provisioning request message including a user device identifier and a password in a first message format, the provisioning request message received by the communication device from a user device during a message exchange process between the user device and the communication device. The method also includes generating an authorization request message in a second message format, the authorization request message including the password, sending the authorization request message to an authorization computer, and receiving an authorization response message from the authorization computer. The method also includes providing access data to the communication device.

Description

[0001] Cross-referencing related applications

[0002] This application is a PCT application that claims priority to U.S. Patent Application No. 16 / 554,955, filed August 29, 2019, which is incorporated herein by reference in its entirety. Background Technology

[0003] Systems and methods for pre-configuring access data to communication devices such as mobile phones are known. For example, access data, such as security data, can be pre-configured to the communication device so that a user of the communication device can use the access data to access resources, such as data, restricted areas, or goods and services.

[0004] However, existing provisioning systems and methods have many problems. For example, users can manually enter identifiers (e.g., access codes, accounts, etc.) of the access data to be provisioned to a communication device, and the communication device can request access data from a remote server computer. However, manually entering data into the communication device is cumbersome and prone to errors. Furthermore, manual data entry can be insecure. For instance, if the identifier required to provision the access data to the communication device is stolen or intercepted from a legitimate user by an unauthorized person, that unauthorized individual could provision access data to their own communication device.

[0005] Another issue that needs to be addressed is the ability to authenticate users or devices to ensure that they are authorized to receive access data. Some authorized entities may be the appropriate ones to authenticate users and / or devices, but they may not have the infrastructure to perform the provisioning process. Furthermore, there may be many different authorized entities, and it would be cumbersome for each to create the infrastructure for provisioning access data. Along the same route, a processing computer may have the capability to provision access data, but may not have the capability to verify whether the user requesting provisioning access data possesses a legitimate user device.

[0006] The embodiments of this disclosure address these and other problems individually and collectively. Summary of the Invention

[0007] One embodiment includes a method comprising: receiving, by a server computer, a pre-configuration request message in a first message format, comprising a user device identifier and a password, the pre-configuration request message being received by the communication device from the user device during a message exchange process between the user device and the communication device; generating, by the server computer, an authorization request message in a second message format, the authorization request message including the password; sending, by the server computer, the authorization request message to an authorization computer; receiving, by the server computer, an authorization response message from the authorization computer; and, in response to receiving the authorization response message, providing access data to the communication device.

[0008] Another embodiment includes a server computer comprising: a processor; and a computer-readable medium including code. The code is executable by the processor to implement a method comprising: receiving, from a communication device, a provisioning request message in a first message format including a user device identifier and a password, the provisioning request message being received by the communication device from the user device during a message exchange process between the user device and the communication device; generating an authorization request message in a second message format, the authorization request message including the password; sending the authorization request message to an authorization computer; receiving an authorization response message from the authorization computer; and, in response to receiving the authorization response message, providing access data from the server computer to the communication device.

[0009] Another embodiment includes a method comprising: a communication device and a user device performing a message exchange process, wherein a password is received by the communication device from the user device during the message exchange process; the communication device sending a provisioning request message including a user device identifier and a password to a server computer, the server computer generating an authorization request message including the password, sending the authorization request message to an authorization computer, the authorization computer verifying the password; and the communication device receiving access data in response to sending the provisioning request message.

[0010] Another embodiment includes a communication device comprising: a processor; and a computer-readable medium coupled to the processor. The computer-readable medium includes code executable by the processor for implementing a method comprising: performing a message exchange process with a user device, wherein a password is received by the communication device from the user device during the message exchange process; sending a provisioning request message including a user device identifier and a password to a server computer, the server computer generating an authorization request message including the password, sending the authorization request message to an authorization computer, the authorization computer verifying the password; and receiving access data in response to sending the provisioning request message.

[0011] Further details regarding embodiments of this disclosure are described in the detailed description and accompanying drawings. Attached Figure Description

[0012] Figure 1 A block diagram of a system according to an embodiment is shown.

[0013] Figure 2 A block diagram of a communication device according to an embodiment is shown.

[0014] Figure 3 A diagram illustrating a user device according to an embodiment is shown.

[0015] Figure 4 A block diagram of a processing server computer according to an embodiment is shown.

[0016] Figure 5 A block diagram of an authorized computer according to an embodiment is shown.

[0017] Figure 6 A flowchart depicting a pre-fitting method according to an embodiment is shown.

[0018] Figure 7 A flowchart depicting the message exchange process between a communication device and a user device is shown.

[0019] Figure 8 A block diagram illustrating an encryption process for generating a password according to an embodiment is shown.

[0020] Figure 9 A block diagram illustrating the payment processing system is shown.

[0021] Figure 10 A block diagram illustrating a building access system is shown. Detailed Implementation

[0022] Implementations may include methods and systems for pre-provisioning access data to communication devices. However, the pre-provisioning of access data may depend on the user possessing a legitimate user device. For example, the user device may be a building access card or a payment card. The user may wish to use a communication device, such as a mobile phone, so that the communication device can function like a user device. For this, the user needs to possess a legitimate user device. The user will connect the user device to the communication device. During the connection, a message exchange process will occur, causing the mobile device to simulate a standard reader for the activity to be performed. For example, the activity may be a payment transaction, and the communication device may simulate a point-of-sale terminal. In another example, the activity may be access to a restricted location, such as a building. The communication device may be programmed to simulate a tag reader. By allowing the communication device to simulate the type of reader for the expected activity, the user device can be authenticated in a manner similar to how the expected activity will occur. Therefore, it can be ensured that any server computer requested to pre-provision access data will pre-provision the access data to a legitimate and authorized communication device.

[0023] This embodiment improves upon conventional systems. By requiring the user to provide a legitimate user device to the communication device before allowing the server computer to provision access data to the communication device, it ensures that the server computer pre-provisions access data to legitimate and authorized communication devices. Furthermore, in this embodiment, since the user does not need to manually input any data into the communication device, fewer data entry errors occur compared to conventional systems. Finally, because this embodiment can use message exchange processes that simulate the actual activities of a user device, existing protocols used in different ways can be used to authenticate the user device. Therefore, this embodiment is easier to implement than systems that may require additional dedicated programming for provisioning functionality.

[0024] Other advantages of the embodiments may include the use of a central server computer that can receive a request message in a first message format and then use an existing communication network with a predefined second message format to verify that the user possesses a legitimate user device. The predefined second message format may be, for example, an ISO 8583 format. The communication network can be configured to seek approval for transactions such as financial transactions. The communication network can be used to obtain verification that the user possesses a legitimate user device (e.g., a payment card) before the user's communication device is provisioned with access data. Verification can be performed using standard messages, such as standard financial messages, instead of specially designed authentication request messages. This is useful because in some cases, different authorized computers (e.g., different issuing computers) may hold different keys to verify passwords that may originate from various user devices held by different users. As an alternative to embodiments of the invention, the only way for an authorized computer to verify passwords for provisioning access data purposes is to redesign each authorized computer utilizing a specific communication protocol and the verification process. By using embodiments of the invention, each authorized computer does not need to create a new provisioning system. Specifically, in an example use case, a central server computer can leverage existing infrastructure and existing authorization request and response messages with existing message formats to verify passwords from user devices before allowing communication devices to be provisioned to access data.

[0025] Before discussing the details of some embodiments of this disclosure, the description of some terms may help to understand the various embodiments.

[0026] A “communication device” (sometimes referred to as a mobile communication device or mobile device) can include any suitable electronic device that a user can transmit and operate, and that also provides the ability to communicate remotely with a network. A mobile communication device can communicate using a mobile phone (wireless) network, a wireless data network (e.g., 3G, 4G, or similar networks), Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), Wi-Max, or any other communication medium that provides access to networks such as the Internet or a private network. Examples of mobile communication devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, netbooks, laptops, wearable devices (e.g., watches), vehicles (e.g., cars and motorcycles), personal music players, handheld dedicated readers, etc. A mobile device can include any suitable hardware and software for performing such functions, and can also include multiple devices or components (e.g., two devices used together can be considered a single mobile device when the device remotely accesses a network by sharing the network with another device (i.e., using said other device as a modem)).

[0027] "Contactless" communication can be communication that exchanges data between two devices without the two devices being physically coupled. Without limiting the generality of the foregoing, "contactless" communication can include data transmission via near field communication (NFC) transceivers, laser, radio frequency, infrared communication, or other radio frequency or wireless communication protocols such as Bluetooth, Bluetooth Low Energy (BLE), Wi-Fi, iBeacon, etc.

[0028] A “user device” can be any suitable device that can be used by a user. A “user device” can take any suitable form. Some examples of user devices include cards (e.g., debit cards, credit cards, and prepaid cards) with magnetic stripes or contactless elements (e.g., including contactless chips and antennas), fobs, wearable devices, mobile phones, tablet computers, etc. In some embodiments, the user device has fewer functions than the communication device used by the user. For example, in some embodiments, the communication device can be a mobile phone with a long-range antenna. The user device can be a payment card without a long-range antenna but with contactless elements having a short-range antenna.

[0029] A "resource provider" can be an entity that provides resources (such as goods, services, access to secure data, access to location, etc.) during a transaction. For example, a resource provider can be a merchant, venue operator, building owner, government entity, etc. A "merchant" is typically an entity that participates in a transaction and can sell goods or services or provide access to goods or services.

[0030] An "application" can be a computer program used for a specific purpose. Examples of applications can include transportation applications, secure data access applications, banking applications, digital wallet applications, etc.

[0031] "Authentication data" can include any data suitable for authenticating an entity. Authentication data can be obtained from a user or a device operated by the user. Examples of authentication data obtained from a user may include a PIN (Personal Identification Number), biometric data, password, etc. Examples of authentication data obtained from a device may include a device serial number, hardware security element identifier, device fingerprint, phone number, IMEI number, etc.

[0032] "Access data" can include any suitable data that can be used to access resources or create data that allows access to resources. In some embodiments, access data can be account information for a payment account. Account information can include a PAN, payment token, expiration date, and verification value (e.g., CVV, CVV2, dCVV, dCVV2), etc. In other embodiments, access data can be data that can be used to activate account data. For example, in some cases, account information can be stored on a mobile device but may not be activated until the mobile device receives specific information. In other embodiments, access data can include data that can be used to access a location. Such access data can be event ticket information, data for accessing buildings, transportation ticket information, etc. In other embodiments, access data can include data for obtaining access to sensitive data. Examples of access data can include code or other data required by a server computer to grant access to sensitive data.

[0033] An "access request" can include a request to access a resource. The resource can be a physical resource (e.g., a product), a digital resource (e.g., electronic documents, electronic data, etc.), or a service. In some cases, an access request can be submitted by sending an access request message that includes access request data. Typically, the device associated with the requesting party can send the access request message to the device associated with the resource provider.

[0034] "Access request data" may include any information about or related to the access request. Access request data may include access data. Access request data may include information that can be used to process and / or verify the access request. For example, access request data may include details associated with entities involved in processing the access request (e.g., resource provider computers, processing server computers, authorizing computers, etc.), such as entity identifiers (e.g., names, etc.), location information associated with the entity, and information indicating the entity type (e.g., category codes). Exemplary access request data may include information indicating the amount of access request, the location of the access request, the resources received (e.g., products, documents, etc.), information about the received resources (e.g., size, quantity, type, etc.), resource provider entity data (e.g., resource provider data, document owner data, etc.), user data, the date and time of the access request, information about the method used to make the access request (e.g., contactless, contactless, etc.), and other relevant information.

[0035] An "access device" can be any suitable device for providing access to something. Access devices can take any suitable form. Some examples of access devices include point-of-sale (POS) devices, 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, websites, etc. Access devices can use any suitable contact or contactless operating mode to send or receive data to or from a user device, or associate with a user device. In some embodiments where the access device may include a POS terminal, any suitable POS terminal can 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 user device.

[0036] A “digital wallet” or “e-wallet” can include electronic devices that allow individuals to conduct e-commerce transactions. A digital wallet can store user profile information, credentials, bank account information, one or more digital wallet identifiers, and can be used for various transactions, such as, but not limited to, e-commerce transactions, social network transactions, money transfer / personal payment transactions, mobile commerce transactions, proximity payment transactions, and gaming transactions. Digital wallets can be designed to simplify the purchasing and payment process. A digital wallet can allow users to load one or more payment cards onto it to make payments without entering an account number or presenting a physical card.

[0037] A "credential" can be any suitable information that serves as reliable evidence of value, ownership, identity, or authority. A credential can be a string of numbers, letters, or any other suitable characters, and any object or document that can be used for authentication. Examples of credentials include value certificates, identification cards, authentication documents, access cards, passwords, and other login information. Other examples of credentials include master account (PAN) and personally identifiable information (PII), such as name, address, and telephone number.

[0038] An "authorizing entity" can be an entity that typically uses an authorized computer to authorize a request. Authorizing entities can be issuers, government agencies, document repositories, access administrators, etc. An "issuer" can typically include a commercial entity that maintains user accounts (e.g., a bank). Issuers may also issue payment credentials to users that are stored on user devices such as cellular phones, smart cards, tablets, or laptops.

[0039] A "service provider" can be an entity that can typically provide resources such as goods, services, information, and / or access through a service provider's computer. Examples of service providers include data providers, transportation agencies, merchants, digital wallets, payment processors, etc.

[0040] "User" may include an individual or computing device. In some embodiments, a user may be associated with one or more personal accounts and / or mobile devices. In some embodiments, a user may be a cardholder, account holder, or consumer.

[0041] A "token" can be an alternative value for a credential. A token can be a string of numbers, letters, or any other suitable characters. Examples of tokens include payment tokens, access tokens, personal identification tokens, etc.

[0042] A "payment token" may include an identifier for a payment account, which is an alternative to an account identifier such as a primary account number (PAN). For example, a token may include a series of alphanumeric characters that can be used as an alternative to the original account identifier. For example, the token "4900 0000 0000 0001" may be used in place of the PAN "4147 0900 0000 1234". In some embodiments, the token may be "formatted" and may have a numerical format consistent with account identifiers used in existing transaction processing networks (e.g., the ISO 8583 financial transaction message format). In some embodiments, the token may replace the PAN in initiating, authorizing, processing, or resolving payment transactions, or represent the original credentials in other systems where the original credentials would typically be provided. In some embodiments, a token value may be generated such that the original PAN or other account identifier may not be computably recoverable from the token value. Furthermore, in some embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and to recognize the entity issuing the token.

[0043] A "key" can include a piece of information used in a cryptographic algorithm to transform data into another representation. A cryptographic algorithm can be an encryption algorithm that transforms the original data into an alternative representation, or a decryption algorithm that transforms encrypted information back into the original data. Examples of cryptographic algorithms can include Triple Data Encryption Standard (TDES), Data Encryption Standard (DES), Advanced Encryption Standard (AES), etc. An "encryption key" can include any data value or other information suitable for cryptographically encrypting data. A "decryption key" can include any data value or other information suitable for decrypting encrypted data. In some cases, the same key used for encrypting and decrypting data can be referred to as a symmetric encryption key.

[0044] A "session key" can include any key used to encrypt or decrypt data to be securely transmitted between two computers. In some cases, a session key can be generated from a shared secret known to both the sending and receiving entities. For example, a session key can be derived using a key derivation function and a shared secret. Session keys can be used to protect data included in request or response messages.

[0045] A “password” can include encrypted text. In some embodiments, a password can be used to authenticate entities such as devices or users. A password can include static data, dynamic data, or a combination of static and dynamic data encrypted using an encryption key (such as a session key or a uniquely derived key).

[0046] An "authorization request message" can be an electronic message sent to a payment processing network and / or the issuer of a payment card to request authorization for a transaction. According to some embodiments, the authorization request message may conform to ISO 8583, a standard for systems that exchange information about electronic transactions associated with payments made by a user using a payment device or payment account. The authorization request message may include an issuer account identifier that can be associated with the payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information," such as, for example, a service code, CVV (card verification value), dCVV (dynamic card verification value), expiration date, etc. The authorization request message may also include "transaction information," such as any information associated with the current transaction, such as the transaction amount, merchant identifier, merchant location, etc., and any other information that can be used to determine whether to identify and / or authorize the transaction.

[0047] An "authorization response message" can be an electronic message response to an authorization request message generated by the issuing financial institution or payment processing network. As an example only, an authorization response message may include one or more of the following status indicators: Approval - the transaction is approved; Rejection - the transaction is not approved; or Call Center - further information is pending, and the merchant must call the toll-free authorization number. The authorization response message may also include an authorization code, which can be a code returned by the credit card issuing bank to the merchant's access device (e.g., a POS device) in response to the authorization request message in the electronic message (directly or via the payment processing network), indicating that the transaction has been approved. This code can serve as evidence of authorization. As described above, in some embodiments, the payment processing network may generate or forward authorization response messages to the merchant.

[0048] A "server computer" is typically a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers that work like cells. In one example, a server computer could be a database server coupled to a web server.

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

[0050] "Memory" can be any suitable one or more devices capable of storing electronic data. Suitable memory can include a non-transitory computer-readable medium storing instructions that can be executed by a processor to implement a desired method. Examples of memory can include one or more memory chips, disk drives, etc. Such memory can be operated using any suitable electrical, optical, and / or magnetic modes of operation.

[0051] Details of some embodiments of this disclosure will now be described in more detail.

[0052] Figure 1A system 100 comprising several components is illustrated according to an embodiment of the present invention. System 100 includes a user device 103, a communication device 102, a communication network 104, a processing server computer 105, an authorization computer 110, and an access data vault 108, wherein the user device may be associated with a user 101. For clarity, Figure 1 A specific number of components are shown. It should be understood that embodiments of this disclosure may include more than one of each component. Furthermore, some embodiments may include more than one of each component. Figure 1 All components shown are either fewer or more components.

[0053] User device 103, communication device 102, processing server computer 105, authorization computer 110, and access data vault 108 can all operationally communicate with each other through any suitable communication channel or communication network 104. Suitable communication networks can be any one and / or a combination of the following: direct interconnection, the Internet, local area network (LAN), metropolitan area network (MAN), Operational Mission as an Internet node (OMNI), secure custom connection, wide area network (WAN), wireless network (e.g., using protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.). Secure communication protocols can be used to send messages between computers, networks, and devices, such as, but not limited to, File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), Secure Hypertext Transfer Protocol (HTTPS), Secure Sockets Layer (SSL), ISO (e.g., ISO 8583), etc.

[0054] In some embodiments, the communication device 102 may include a service provider application, such as a mobile wallet application, a payment application, or an access application, which may be pre-configured with access data to enable the communication device 102 to perform access transactions. Furthermore, in some embodiments, the user device 103 may perform operational communication with the communication device 102 via contactless communication.

[0055] Figure 2 A block diagram of a communication device 102 according to an embodiment is shown. In some embodiments, the communication device 102 may be a means for communicating with external entities and obtaining access to certain resources. For example, the communication device 102 may be a mobile phone, which can be used to make payments or obtain access to location or security data. Reference Figure 2The communication device 102 may include a computer-readable medium 102B and a memory 102C residing within a body 102J. The body 102J may be in the form of a plastic substrate, a housing, or other structures. In some cases, the memory 102C may be a security element and / or may also store information such as access data, such as tokens, PANs, tickets, etc. The information in the memory 102C may be transmitted by the communication device 102 to another device using an antenna 102D or a contactless component interface 102I.

[0056] The communication device 102 may further include a processor 102A (e.g., a microprocessor) for processing the functions of the communication device 102 and a display 102G that allows users to view information. The communication device 102 may further include input elements 102E (e.g., a touchscreen, keyboard, touchpad, a sensor such as a biometric sensor, etc.), a speaker 102H, and a microphone 102F. The communication device 102 may also include an antenna 102D for wireless data transmission.

[0057] Computer-readable medium 102B may include code executable by a processor for implementing a method according to an embodiment. For example, computer-readable medium 102B may include code executable by processor 102A for implementing a method comprising: performing a message exchange process with a user device, wherein a password is received by a communication device from the user device during the message exchange process; sending a provisioning request message including a user device identifier and a password to a server computer, the server computer generating an authorization request message including the password, sending the authorization request message to an authorization computer, the authorization computer verifying the password; and receiving access data.

[0058] Computer-readable medium 102B may include a service provider application 102B-1, an access device emulation API 102B-2, and a provisioning request module 102B-3. The access device emulation API 102B-2 may further include an application selection submodule. The service provider application 102B-1, together with processor 102A, allows communication device 102 to communicate with a service provider computer. The service provider computer can provide functionality offered by the service provider. Examples of service provider applications may include digital wallet applications, payment applications, merchant applications, transportation applications, applications for accessing secure data, etc.

[0059] The operating system (OS) of communication device 102 can implement a set of access device emulation APIs 102B-2, which allow service provider application 102B-1 to gain access to contactless component interface 102I and exchange transaction data communications with contactless components of user devices. For example, access device emulation API 102B-2 may include programmable function calls to allow service provider application 102B-1 to receive, process, and respond to communications, such as Application Protocol Data Unit (APDU) commands sent from contactless components of user devices. In this way, communication device 102 can emulate the functionality of access devices such as tag readers or POS terminals. Service provider application 102B-1 can also cause provisioning request module 102B-3 and processor 102A to initiate, receive, process, and respond to message communications with processing server computer 105, which are related to provisioning access data (e.g., payment tokens) to service provider application 102B-1.

[0060] In some embodiments, the contactless component interface 102I is implemented in the form of a semiconductor chip (or other data storage element) having associated wireless transmission (e.g., data transmission) elements, such as an antenna. Data or control commands transmitted via a cellular network can be applied to the contactless component interface 102I. The contactless component interface 102I is capable of transmitting and receiving data using short-range wireless communication capabilities. Therefore, the communication device 102 is capable of transmitting and receiving data or control commands via a cellular network (or any other suitable wireless network, such as the Internet or other data networks) or any short-range communication mechanism.

[0061] Figure 3 A user device 103 according to an embodiment is shown. User device 103 includes a substrate 103A, such as a plastic substrate. A contactless element 103B for connection to a data access or data transmission device may be on or embedded within the user device substrate 103A. The contactless element 103B may include a chip and is capable of transmitting and transferring data using Near Field Communication (NFC) technology or other short-range communication technologies. User device 103 may also include a memory 103C, which may store user information such as account number, expiration date, and username. Such information may also be printed or imprinted on the substrate 103A. A magnetic stripe 103D may also be present on the substrate 103A.

[0062] Figure 4A block diagram of a processing server computer 105 according to an embodiment is shown. The processing server computer 105 may include a processor 105A, which may be coupled to system memory 105B and an external communication interface 105C. A computer-readable medium 105D may also be operatively coupled to the processor 105A. A database 105E may also operatively communicate with the processor 105A. The database 105E may contain access data such as tokens and / or account data, mappings between access data, and credentials and / or communication device identifiers, such as telephone numbers, IP addresses, device identifiers, etc.

[0063] Computer-readable medium 105D may include code executable by processor 105A to perform a method comprising: receiving from a communication device a provisioning request message in a first message format, the provisioning request message being received by the communication device from the user device during a message exchange process between the user device and the communication device; generating an authorization request message in a second message format, the authorization request message including the password; sending the authorization request message to an authorization computer; receiving an authorization response message from the authorization computer; and providing access data to the communication device in response to receiving the authorization response message.

[0064] The computer-readable medium 105D may include multiple software modules, including a communication module 105D-1, an encryption / decryption module 105D-2, a database update module 105D-3, a dynamic data element generation module 105D-4, an authorization module 105D-5, an authentication module 105D-6, a pre-configuration module 105D-7, and a message format conversion module 105D-8.

[0065] The communication module 105D-1 may include code that enables the processor 105A to generate messages, forward messages, reformat messages, and / or otherwise communicate with other entities.

[0066] In embodiments of the present invention, the encryption / decryption module 105D-2 may include any suitable encryption / decryption algorithm for encrypting data. Suitable data encryption / decryption algorithms may include DES, Triple DES, AES, etc. The encryption / decryption module may also store encryption keys that can be used with such encryption / decryption algorithms. The encryption / decryption module 105D-2 may utilize symmetric or asymmetric encryption techniques to encrypt and / or verify data. The cryptographic keys that the encryption / decryption module 105D-2 can use may be securely stored in the system memory 105B.

[0067] The database update module 105D-3 may include code that causes the processor 105A to update the database 105E. The database 105E can be updated using account information, token-to-credential-to-device information mappings, provisioning information, etc.

[0068] The dynamic data element generation module 105D-4 may include code that causes the processor 105A to generate dynamic data elements such as random numbers, time, and / or dates. In some embodiments, one or more dynamic data elements may be used as input data for a password.

[0069] The authorization module 105D-5 may include code that enables the processor 105A to evaluate the provisioning request message and determine whether access data (e.g., a payment token) should be provided to the requesting party. The authorization module 105D-5 may also include code for routing or modifying the authorization request and response messages as they are transmitted between parties such as an issuer and an acquirer.

[0070] The verification module 105D-6 may include any suitable code for verifying codes or data. In some embodiments, the verification module 105D-6 may verify encrypted data packets received from the communication device 102. The verification module 105D-6 may also include code for comparing data to determine if a match exists.

[0071] The pre-configuration module 105D-7 may include code that can be executed by the processor 105A to pre-configure access data to the communication device.

[0072] The message format conversion module 105D-8 may include code executable by the processor 105A to convert messages from one message format to another different message format. The message format conversion module 105D-8 may include mapping software that can map data elements in data fields of a first message in a first message format (e.g., XML data format) to corresponding data fields in a second message in a different message format (e.g., ISO 8583 message format).

[0073] Figure 5 A block diagram of an authorization computer 110 according to an embodiment is shown. The authorization computer 110 may include a processor 110A that is coupled to system memory 110B and an external communication interface 110C. A computer-readable medium 110D may also be operatively coupled to the processor 110A. A database 110E may also operatively communicate with the processor 110A. The database 110E may contain account data.

[0074] Computer-readable medium 110D may include code executable by processor 110A to perform a method comprising: receiving an authorization request message from a processing computer, the authorization request message including a nominal amount or zero dollar amount and a password previously generated by a user device interacting with a communication device; authorizing or rejecting the authorization request message; generating an authorization response message; and sending the authorization response message to the processing computer.

[0075] The computer-readable medium 110D may include multiple software modules, including a communication module 110D-1, an encryption / decryption module 110D-2, a database update module 110D-3, a settlement module 110D-4, an authorization module 110D-5, and a verification module 110D-6.

[0076] The communication module 110D-1 may include code that enables the processor 110A to generate messages, forward messages, reformat messages, and / or otherwise communicate with other entities.

[0077] In embodiments of the present invention, the encryption / decryption module 110D-2 may include any suitable encryption / decryption algorithm for encrypting data. Suitable data encryption / decryption algorithms may include DES, Triple DES, AES, etc. The encryption / decryption module may also store encryption keys that can be used with such encryption / decryption algorithms. The encryption / decryption module 110D-2 may utilize symmetric or asymmetric encryption techniques to encrypt and / or verify data. The cryptographic keys that the encryption / decryption module 110D-2 can use may be securely stored in the system memory 110B.

[0078] The database update module 110D-3 may include code that causes the processor 110A to update the database 110E. The database 110E can be updated with account information, authorization data, etc.

[0079] The settlement module 110D-4 may include code that enables the processor 110A to perform settlement processing with a settlement entity such as a processing computer.

[0080] The authorization module 110D-5 may include code that enables the processor 110A to evaluate the authorization request message to determine whether it should be authorized. Determining whether the authorization request message should be authorized or not may include whether the received password is determined to be valid, and / or whether the account associated with the user has sufficient funds or credit to authorize the ongoing transaction.

[0081] The verification module 110D-6 may include any suitable code for verifying codes or data. In some embodiments, the verification module 110D-6 may verify encrypted data packets received from the communication device 102. The verification module 110D-6 may also include code for comparing data to determine if a match exists.

[0082] The pre-configuration module 110D-7 may include code that can be executed by the processor 110A to pre-configure access data to the communication device.

[0083] Figure 6 A flowchart illustrating a method for securely pre-promoting access data to a service provider application 102B-1 (e.g., an access application, digital wallet application, etc.) on a communication device 102 (e.g., a mobile phone) using authentication data received from a user device 103 (e.g., a contactless payment card) according to an embodiment is shown. The following description may also refer to... Figure 1-5 The components in.

[0084] At step S108, the user of communication device 102 may wish to provide access data to an application on communication device 102. Specifically, communication device 102 may generate an initialization request message to pre-provision the access data to a service provider application 102B-1 (e.g., a digital wallet application) on communication device 102. Once the user of communication device 102 is ready to send the pre-provisioning initialization request message to processing server computer 105, the user can select an appropriate indicator on mobile communication device 102. For example, the user can select "Send," "+," "Add Card to Digital Wallet," or any other suitable option presented on the display of communication device 102. Service provider application 102B-1 can then execute pre-provisioning request module 102B-3 to send the pre-provisioning initialization request message to processing server computer 105. An initialization request message can be sent from communication device 102 to processing server computer 105 using any suitable electronic message format, including email, Short Message Service (SMS) messages, Multimedia Message Service (MMS) messages, Hypertext Transfer Protocol (HTTP) request messages, Send Control Protocol (TCP) packets, web form submissions, etc. The message can be directed to any suitable address associated with processing server computer 105, including email addresses, telephone numbers, Internet Protocol (IP) addresses, or Uniform Resource Locators (URLs).

[0085] In step S110, after receiving an initialization request message for pre-configured access data from communication device 102, processing server computer 105 can generate dynamic data elements by executing dynamic data element generation module 105D-4. Instances of dynamic data elements may include application transaction counters (ATCs), random numbers, current time, etc. Dynamic data elements are dynamic because they can change frequently (e.g., with each or nearly every interaction). Furthermore, in some embodiments, processing server computer 105 can generate session IDs associated with the dynamic data elements.

[0086] At step S112, the processing server computer 105 can send dynamic data elements and an optional session ID to the communication device 102. The service provider application 102B-1 on the communication device 102 can receive the dynamic data elements and then prompt the user to present the user device 103 to the communication device 102 (e.g., displaying the message "Tap the card to the phone").

[0087] In step S114, the user can present the user device 103 to the communication device 102 by placing it near the contactless component interface 102I of the communication device 102. The user can move the user device 103 closer to the communication device 102 until data can be exchanged between the two devices. In some embodiments, the user device 103 may contact the communication device 102.

[0088] At step S116, the communication device 102 may perform a message exchange procedure with the user device 103. During the message exchange procedure, the communication device 102 receives a password from the user device 103. The message exchange procedure may be a procedure that is typically performed during an access transaction for accessing resources, even if the current request to provision access data to the communication device may not be considered a request for access to resources such as goods, services, location, or security data.

[0089] In some embodiments, the message exchange process uses an enhanced data interface protocol to transmit information between communication device 102 and user device 103. For example, an exemplary embodiment of the concepts described herein includes a message exchange process comprising APDU commands, such as “Get Processing Options” and “Application Identifier” request and response messages. In some embodiments, the message exchange process includes sending a numerical value, such as $0, from communication device 102 to user device 103. Furthermore, in some embodiments, user device 103 may provide transaction processing information to communication device 102, including the primary account (PAN) and the expiration date associated with the primary account. References below... Figure 7 Further details are described regarding an exemplary message exchange process.

[0090] In some embodiments, the password sent from user device 103 to communication device 102 in step S116 is generated by encrypting at least the following items using at least one key on user device 103: dynamic data elements received by communication device 102 from processing server computer 105 at step S112, user device identifier from user device 103, and optionally numerical values ​​and other information. In some embodiments, the user device identifier may be a PAN.

[0091] The password can be generated in any suitable manner. For example, in some embodiments, at least one password key on user device 103 is derived from data existing on user device 103. In some embodiments, processing server computer 105 and user device 103 may share symmetric encryption keys that will allow the processing server computer and the user device to encrypt and decrypt the password. In other embodiments, processing server computer 105 and user device 103 may respectively encrypt a portion of the password using a public key and decrypt a portion of the password using a private key. The encryption used can include any type of encryption method. For example, this encryption step may utilize DES, triple DES, AES, etc. See below for further details. Figure 8 Further details are described regarding the exemplary password generation process.

[0092] At step S118, communication device 102 may send a provisioning request message to processing server computer 105. The provisioning request message may include a user device identifier and a password received from user device 103 during step S116. In some embodiments, communication device 102 may provide the provisioning request message to processing server computer 105 via service provider application 102B-1, which may then use provisioning request module 102B-3 to send the message. In some embodiments, the provisioning request message may include an encrypted portion (e.g., the password generated in step S116) and an unencrypted portion (e.g., a PAN or key index that can be used to locate the encryption key in a database). The unencrypted portion can be used to decrypt the encrypted portion and recover data from it. In some embodiments, the unencrypted portion can be used to generate one or more keys for decrypting the encrypted portion. In some embodiments, communication device 102 may send the session ID received by communication device 102 at step S112 as part of the unencrypted portion of the provisioning request message. This allows the processing server computer 105 to associate the provisioning request message with the dynamic data element generated by the processing server computer 105 in step S110.

[0093] Provisioning request messages can take the form of emails, Short Message Service (SMS) messages, Multimedia Messaging Service (MMS) messages, Hypertext Transfer Protocol (HTTP) request messages, Send Control Protocol (TCP) packets, web form submissions, etc.

[0094] In step S120, the processing server computer 105, having received the pre-configuration request message sent by the communication device 102 in step S118, can generate an authorization request message including a user device identifier, password, dynamic data elements, and a value. The value may be a transaction amount, such as a symbolic amount or zero dollars. The authorization request message may be in a different message format than the pre-configuration request message (e.g., a first message format), such as a second message format. For example, the pre-configuration request message may be in a format such as XML data format, while the authorization request message may be in a format such as ISO 8583 message format. The message format conversion module 150, in conjunction with the data processor 150A, can perform the message format conversion process.

[0095] In step S122, once formed, the processing server computer 105 can send the authorization request message to the authorization computer 110.

[0096] In step S124, after receiving the authorization request message, the authorization computer 110 can extract the password from the authorization request message and can execute the encryption / decryption module 110D-2 to decrypt the password using the appropriate second password key, and can recover the dynamic data elements from the password. If the authorization computer 110 determines that it can decrypt the password and recover the data elements in the password, the authorization computer 110 can guarantee that the real user device created the password, because only the real user device will likely have the first password key corresponding to the second password key stored by the authorization computer 110 (which forms the password). Then, the processing server computer 105 determines whether the value of the dynamic data element generated in step S110 and received in the authorization request message matches the value of the recovered dynamic data element. If the recovered dynamic data element does not match the previously generated dynamic data element, the authorization computer 110 can reject the authorization request message. The authorization computer 110 can also determine the transaction amount that can be authorized. For example, the amount can be $0 or a symbolic amount such as $0.28, and the authorization computer 110 can determine whether the account associated with the user identifier in the authorization request message contains sufficient funds or credit to authorize the transaction.

[0097] In step S126, if the password is verified by the authorized computer 110 and the transaction amount is also verified by the authorized computer, the authorized computer 110 can send an authorization response message including the user identifier and a positive authorization indicator to the processing server computer 105.

[0098] In step S128, after receiving the authorization response message, the processing server computer 105 can analyze the authorization response message to see if it contains a positive authorization indicator. If it does, the processing server computer 105 can ensure that the authorizing computer 110 has verified the password.

[0099] In step S130, if the authorization response message contains a positive authorization result, the processing server computer 105 may send an access data request message containing at least a user device identifier to the access data repository 108. In some embodiments, the access data request message may contain details required to provision access data to the communication device 102. For example, such details may include the address associated with the communication device 102 (e.g., a telephone number), details of the user device 103 (e.g., a PAN), and any other suitable data.

[0100] In step S132, the access data vault 108 can retrieve the requested access data.

[0101] In step S134, the access data custodian 108 may send access data (e.g., a token) to the processing server computer 105. The processing server computer 105 may receive the access data and, in some embodiments, store the access data and related information received from the access data custodian 108 via the database update module 105D-3 in a database 105E. Such information may include the address of the communication device 102 (e.g., a telephone number), any data used by the communication device 102 to receive access data, etc.

[0102] In step S136, the provisioning module 105D-7 of the processing server computer 105 can send the access data received in step S134 to the service provider application 102B-1 of the communication device 102. Subsequently, the communication device 102 can be used to conduct access transactions using the service provider application 102B-1 and the access data provisioned to the communication device. In some embodiments, the access data can be stored in a secure area (e.g., a secure element) within the communication device 102. Furthermore, in some embodiments, the service provider application 102B-1 can send a confirmation message to the user. For example, the confirmation message may display "Card connected" on the communication device display 102G.

[0103] In step S138, if the amount in the original authorization request message includes a symbolic amount (e.g., $0.27), the processing server computer 105 can send a transaction reversal message to the authorization computer 110. The authorization computer 110 can then revoke the transaction amount so that it is not credited to the user's account.

[0104] The process described above can be used to pre-provision static or dynamic access data to communication device 102. If the access data is dynamic, it can be provided to communication device 102 for each transaction or a predetermined number of transactions (e.g., every 5-10 transactions). This reduces the risk of fraud that may result from man-in-the-middle attacks.

[0105] Figure 7 Show Figure 6 A flowchart of message exchange process S116 between user device 103 and communication device 102. Figure 7 The illustrated message exchange process involves a payment interaction process between a contactless device, such as a contactless card, and a POS terminal. Other message exchange processes may be used in other contexts. In one embodiment, the service provider application 102B-1 of communication device 102 may execute an Access Device Emulation (ADE) application programming interface (API) 102B-2. The ADE API may include programmable function calls to allow the service provider application 102B-1 to emulate an access device to receive, process, and respond to provisioned communications, such as Application Protocol Data Unit (APDU) commands sent from user device 103.

[0106] For example, in one exemplary embodiment, the user device 103 is a contactless payment card. As stated above... Figure 6 As explained in step S114, a user can present their user device 103 to the communication device 102 by placing it near the contactless component interface 102I of the communication device 102. When the communication device 102 detects the presence of the user device 103, the application selection module of the ADE API 102B-2 can initiate a message exchange process by sending an available application request 702 to the user device 103. In some embodiments, the available application request 702 may be in the form of a “Select Near-Field Payment System Environment (PPSE)” command. In such embodiments, the request for an available application may include a payment environment identifier (e.g., a PPSE name, such as “2PAY.SYS.DDF01”) for identifying the payment environment supported by the ADE API 102B-2 of the communication device 102.

[0107] Upon receiving an available application request 702, user device 103 can identify and process the request by recognizing the payment environment identifier (e.g., PPSE name) included in the request, and respond by sending an available application response 704 back to communication device 102 via ADE API 102B-2. The available application response 704 may include a list of available account application identifiers (AIDs), application configuration options associated with the available AIDs, and may include a proximity payment environment identifier (e.g., PPSE name) as a dedicated filename. Furthermore, in some embodiments, such as when user device 103 is a mobile communication device, the available application response 704 may include a wallet identifier associated with the mobile application. In some embodiments, the available application response 704 may be in the form of a "select PPSE" response and may include PPSE file control information (FCI). For example, the available application response 704 may include a directory entry for each available AID on the contactless user device 103. In some embodiments, a wallet identifier may be associated with each available AID. Each directory entry may include information such as: AID, application tag associated with the AID (e.g., a mnemonic associated with the AID, such as "Visa debit"), application priority indicator indicating the priority of the AID, kernel identifier indicating the kernel preferences of the application, and / or additional information related to a specific AID. Available application responses to 704 may also include other data, such as arbitrary data from the FCI issuer or any other relevant information.

[0108] The communication device 102 can determine the supported account applications based on the received available AIDs, and can send an “application selection” command 706 including the selected AID to the contactless user device 103.

[0109] Additionally, in some embodiments, upon receiving the application selection message 706, the contactless user device 103 may send a terminal transaction data request 708 to request transaction data from the communication device 102 that may be required to complete the provisioning process of the selected application associated with the selected AID. In some embodiments, the terminal transaction data request 708 may be in the form of a “selected AID response” and may include Application Identifier (AID) File Control Information (FCI) with the selected AID as a proprietary filename. The terminal transaction data request may include a list of transaction data identifiers (via ADE API 102B-2, which emulates a POS terminal) requesting appropriate data from the communication device 102, and the list of transaction data identifiers may be in the form of a Processing Option Data Object List (PDOL).

[0110] The transaction data for a transaction request from the contactless user device 103 may include an entity identifier associated with the communication device 102, a Terminal Processing Option (TPO), an amount, a communication device identifier, and other information. Additionally, the transaction data may include dynamic data elements (e.g., random numbers) previously generated by the processing server computer 105. In other embodiments, the transaction information may be provided as part of the application selection message 706 and / or as part of the available application request 702.

[0111] Upon receiving a terminal transaction data request 708, communication device 102 may send the terminal transaction data 710 requested by contactless user device 103 to contactless user device 103. In some embodiments, the terminal transaction data 710 may be sent in the form of a Get Processing Option (GPO) command and may be included in the requested terminal transaction data 710 in a Processing Option Data Object List (PDOL). In some embodiments, the terminal transaction data 710 (e.g., a Transaction Processing Option (TPO)) may include a TPO indicator indicating which transaction data types the communication device 102 supports. As noted in some embodiments, to facilitate the pre-provisioning process by utilizing APDU commands, communication device 102 may send a zero dollar value as part of the terminal transaction data 710 to contactless user device 103. It should be understood that in some embodiments, the value may be any amount.

[0112] Once user device 103 receives terminal transaction data 710, it obtains the relevant card credentials from its contactless element 103B and may send a set of transaction processing information 712 to communication device 102. In some embodiments, transaction processing information 712 may be sent in the form of a "Get Processing Option" (GPO) response. In some embodiments, transaction processing information may include one or more application file locators (AFLs) that can be used by communication device 102 as file addresses to read account data stored on user device 103, and application exchange profiles (AIPs) that can be used to indicate the capabilities of the payment application.

[0113] Transaction processing information 712 may include any transaction credentials, including a password generated using the transaction information, track 2 equivalent data (e.g., PAN, expiry date), and / or additional data. For example, the transaction information may be used to generate the password, which may include at least the previously described dynamic data elements (e.g., random numbers), a user device identifier (e.g., PAN), and optionally other information such as a session identifier, a zero-dollar amount equivalent, and a transaction counter. Transaction processing information 712 may also include Issuer Application Data (IAD), a Form Factor Indicator (FFI), a Card Transaction Qualifier (CTQ), Password Information Data (CID), and / or an Application PAN Serial Number (PAN). In some embodiments, the Issuer Application Data (IAD) may include a length indicator indicating the length of the IAD, a Password Version Number (CVN) indicating the version of the transaction password, a Derived Key Indicator (DKI) that can be used to identify the master key (e.g., a master key associated with the issuer), and / or a Card Verification Result (CVR). References below. Figure 8 Describe additional details about the password generation process.

[0114] After receiving transaction processing information 712, communication device 102 may send account data request 714 to user device 103 to read additional account data that may be stored on user device 103. In some embodiments, account data request 714 may be in the form of a "read record" command and may include an application file locator (AFL) indicating the location of the account data that communication device 102 is attempting to read. The AFL included in account data request 714 may correspond to the AFL in transaction processing information 712 provided from user device 103 to communication device 102.

[0115] In response to receiving an account data request 714 from communication device 102, contactless user device 103 may send account data 716 stored at a location indicated by the AFL to communication device 102. In some embodiments, account data 716 may be sent in the form of a "read record" response. Account data 716 may include, for example, application use controls indicating restrictions on the use and services allowed by the issuer, cardholder's name, customer-specific data, issuer country code, and / or other account-related data accessible at the AFL location and stored in user device 103.

[0116] Figure 8 A flowchart illustrating the process of generating a password by a user device 103 according to one embodiment is shown.

[0117] In some embodiments, the password generation process 800 may begin with user device 103 encrypting static data element 804 using encryption function 806 with a first encryption key 802 on user device 103 to generate a second encryption key 808. The first encryption key 802 may be a base key associated with the issuer of a user account, and the base key may be associated with a set of accounts. For example, the first encryption key 802 may be associated with a set of accounts within a BIN or PAN range specified for a payment service associated with this type of user device 103. Each user device 103 may be personalized within its functionality to derive a key unique to the payment service from data (e.g., static data element 804) present on user device 103. In some embodiments, the first encryption key 802 may be a master derived key (MDK) associated with the issuer of the account associated with static data element 804, and the first encryption key 802 may also be maintained at processing server computer 105.

[0118] Static data element 804 may include account identification information, such as an account identifier (e.g., PAN), an alternative account identifier (e.g., an alternative PAN), or a token that is an alternative account identifier, and may additionally include user identification information, such as (e.g., when multiple users use the same account) a serial number (e.g., a PAN serial number (PSN)) that identifies a specific user of the account. For example, static data element 804 used as input to cryptographic function 806 may be a concatenation of account identification information and user identification information, or a reversed version of such a concatenation.

[0119] In some embodiments, the second encryption key 808 generated from the account information may include multiple parts, each generated from different variants of the account information. For example, the second encryption key 808 may be divided into two parts. The first part of the second encryption key 808 may be generated by encrypting the account information using the first encryption key 802. The second part of the second encryption key 808 may be generated by reversing the account information and encrypting the reversed account information using the first encryption key 802. The encryption function 806 used to generate the second encryption key 808 may be, for example, Triple Data Encryption Standard (TDES) or other suitable encryption algorithms, and may use an initial chaining vector of binary zeros. In some embodiments, the second encryption key 808 generated from the account information may correspond to the account's unique derived key (UDK).

[0120] In one exemplary embodiment, the password generation process 800 can continue by encrypting at least two dynamic data elements 810, 812 using a second encryption key 808. By creating a password using at least two (or more) dynamic data elements, the likelihood of a skimmer determining the password is extremely low. In some embodiments, instances of dynamic data elements may include an application transaction counter (ATC), dynamic data elements generated by the processing server computer (e.g., random numbers), the time of day, etc. Dynamic data elements are dynamic in such a sense that they change frequently, for example, with each or almost every transaction, or at frequent time intervals (e.g., daily or every few days). In some embodiments, dynamic data element 810 corresponds to dynamic data element S110, which is first generated at the processing server computer 105. Figure 6 The message is sent to the communication device 102 in step S112, and further sent by the communication device 102 to the user device 103 during the message exchange process S116. It should be understood that although in some exemplary embodiments, at least two dynamic data elements are encrypted to form a cipher, in some embodiments, only one dynamic data element may be encrypted.

[0121] In some embodiments, a numeric string (not shown) of a predetermined length can be created as input to be encrypted by the encryption / decryption function 814. This numeric string can be created by overlaying a first dynamic data element (e.g., ATC) on the corresponding leftmost digit of the account of the payment service or PAN. This numeric string can be overlaid with a second dynamic data element (e.g., on the right side) on the left. Figure 6 In step S116, randomly generated numbers received from communication device 102 are concatenated to produce a concatenated value. If necessary, padding characters are concatenated to the right of the concatenated value to form a number string with a predetermined fixed length. This number string can be encrypted by encryption / decryption function 814 using a second encryption key 808. In some embodiments, this number string can be divided into two equal blocks. Furthermore, in some embodiments, encryption / decryption function 814 can further encompass a series of sub-steps (not shown). In these sub-steps, the two blocks obtained from the bisection of the number string can each be encrypted and / or decrypted using one or both parts of the divided second encryption key, and / or XORed with the resulting blocks. This series of sub-steps can generate transaction cipher 816.

[0122] Once access data is pre-configured on the communication device, the access data can be used for access transactions. Figure 9 and 10 Systems and methods for accessing data on communication devices in different contexts are described.

[0123] Figure 9 This diagram illustrates a transaction processing system in which user 101 operates a communication device 102 pre-configured with access data (e.g., a token). User 101 can use the communication device 102 to pay for goods or services from a resource provider, such as a merchant. The merchant can operate a resource provider computer 920 and / or access device 910. The merchant can communicate with an authorized entity computer 950 operated by the issuer via a transmission computer 930 operated by the acquirer and a processing network 940, such as a payment processing network.

[0124] A payment processing network may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception handling services, and clearing and settlement services. An exemplary payment processing network may include VisaNet. TM For example, VisaNet TM Payment processing networks like VisaNet can handle credit card transactions, debit card transactions, and other types of commercial transactions. TM Specifically, this includes the VIP system (Visa Integrated Payment System) that processes authorization requests, and the Base II system that performs clearing and settlement services. The payment processing network can use any suitable wired or wireless network, including the Internet.

[0125] A typical payment transaction flow using a communication device 102 (pre-configured with access data via user device 103) at an access device 910 (e.g., a POS location) can be described as follows. User 101 presents his or her communication device 102 to the access device 910 to pay for goods or services. The communication device 102 and the access device 910 interact, such that access data from the communication device 102 (e.g., PAN, payment token, verification value, expiry date, etc.) is received by the access device 910 (e.g., via a contact or contactless interface). The resource provider computer 920 can then receive this information from the access device 910 via an external communication interface. The resource provider computer 920 can then generate an authorization request message including the information received from the access device 910 (i.e., the information corresponding to user device 103) and additional transaction information (e.g., transaction amount, merchant-specific information, etc.), and electronically transmit this information to the transmission computer 930. Then, the transmission computer 930 can receive, process, and forward the authorization request message to the processing network 940 for authorization.

[0126] Generally, before a credit or debit card transaction is processed, the processing network 940 has already established an agreement with the issuer regarding the authorization method for the transaction. In some cases, such as when the transaction amount is below a threshold, the processing network 940 can be configured to authorize the transaction based on its information about the user account without generating an authorization request message and sending it to the authorization entity computer 950. In other cases, such as when the transaction amount is above a threshold, the processing network 940 can receive the authorization request message, identify the issuer associated with the user device 103, and forward the authorization request message for the transaction to the authorization entity computer 950 for verification and authorization. Once the transaction is authorized, the authorization entity computer 950 can generate an authorization response message (which may include an authorization code indicating that the transaction is approved or rejected) and send this electronic message to the processing network 940 via the external communication interface of the authorization entity computer. The processing network 940 can then forward the authorization response message to the transmission computer 930, which can then subsequently send an electronic message including authorization instructions to the resource provider computer 920, and then to the access device 910.

[0127] If the access data is in the form of a token, the processing network 940 can exchange the token for a real credential (e.g., a PAN). Any authorization request message can then be modified to include the real credential, and the authorization request message can be forwarded to the authorizing entity computer 950 for verification. The authorizing entity computer 950 can generate an authorization response message with approval or rejection. The authorization response message can be sent to the processing network 940, and the processing network 940 can replace the credential with the token. The processing network 940 can then send the authorization response message back to the access device 910.

[0128] At the end of the day or at some other suitable time interval, the clearing and settlement process between the transaction execution resource provider computer 920, the transmission computer 930, the processing network 940 and the authorized entity computer 950 can be carried out.

[0129] Figure 10A block diagram of a building access system and a communication device 102 operated by user 101 is shown. Access data (e.g., a token) as described above has been pre-configured to communication device 102 using a contactless user device 103 (e.g., a contactless card). Communication device 102 can interact with access device 1010 and transmit access data to it. Access device 1010 can locally verify the received access data, or it can communicate with a remotely located authentication server computer (not shown). The remotely located authentication server computer can verify the authenticity of the access data and can send a signal indicating this back to access device 1010. Access device 1010 can then proceed to allow user 101 to enter building 1020.

[0130] The embodiments of this disclosure offer several technical advantages over conventional systems. For example, by providing a mechanism for communication device 102 to simulate access device 910 (including receiving, processing, and responding to transaction communications from user device 103) when provisioned with access data, security is enhanced because it allows processing network 940 to verify that the user device's credentials are actually associated with the real user device 103 (e.g., a genuinely issued payment card). Furthermore, the embodiments allow processing network 940 to verify that provisioning access data to communication device 102 is performed within the same session in which user device 103 is presented to communication device 102, thereby reducing man-in-the-middle attacks. Moreover, the embodiments allow processing computer to verify whether a real user device is used to request provisioned access data, even if the processing computer does not possess the cryptographic key that allows it to verify any passwords generated by the real user device. The embodiments utilize existing messaging infrastructure to perform the verification process, even if the specific messaging infrastructure was not originally designed or intended for this purpose.

[0131] It should be understood that any embodiment of this disclosure may be implemented using hardware (e.g., application-specific integrated circuits or field-programmable gate arrays) and / or computer software in the form of control logic, wherein the general-purpose programmable processor is modular or integrated. As used herein, the 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 together. Based on the disclosure and teachings provided herein, those skilled in the art will know and understand other ways and / or methods of implementing embodiments of this disclosure using hardware and combinations of hardware and software.

[0132] Any software component or function described in this application may be implemented as processor-executable software code using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python, employing 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. Suitable media include random access memory (RAM), read-only memory (ROM), magnetic media such as hard disk drives, or optical media such as optical discs (CDs) or digital versatile discs (DVDs), flash memory, etc. The computer-readable medium may be any combination of such storage or transmission means.

[0133] Such programs can also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and / or wireless networks conforming to various protocols, including the Internet. Therefore, computer-readable media according to embodiments of this disclosure can be created using data signals encoded with such programs. Computer-readable media encoded with program code can be packaged with compatible devices or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or within a single computer product (e.g., a hard disk drive, CD, or an entire computer system) and can exist on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any results mentioned herein to a user.

[0134] The foregoing description is illustrative and not restrictive. Many variations of this disclosure will become apparent to those skilled in the art upon reading it. Therefore, the scope of this disclosure should not be determined by reference to the foregoing description, but rather by reference to the pending claims and their full scope or equivalents.

[0135] Without departing from the scope of this disclosure, one or more features from any embodiment may be combined with one or more features from any other embodiment.

[0136] Unless explicitly indicated otherwise, the use of “a” or “the” is intended to mean “one or more”.

[0137] All patents, patent applications, publications, and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. This does not constitute an admission that they are prior art.

Claims

1. A method for provisioning access data to a communication device, the method comprising: receiving, by a server computer, an initialization request message from the communication device to provision the access data to a service provider application on the communication device; providing, by the server computer, a dynamic data element to the communication device in response to the initialization request message; performing, by the communication device with a user device, a message exchange process using a simulated access device, wherein a value is sent from the communication device to the user device and a cryptogram is received by the communication device from the user device in the message exchange process, wherein the cryptogram is formed using the dynamic data element, a user device identifier, and a first cryptographic key; receiving, by the server computer, a provisioning request message including the user device identifier and the cryptogram from the communication device in a first message format; generating, by the server computer, an authorization request message in a second message format, the authorization request message including the cryptogram, the user device identifier, the dynamic data element, and the value; sending, by the server computer, the authorization request message to an authorization computer, wherein the authorization computer extracts the cryptogram from the authorization request message, decrypts the cryptogram using a second cryptographic key to determine a recovered dynamic data element, and determines that the recovered dynamic data element matches the dynamic data element; receiving, by the server computer, an authorization response message from the authorization computer; providing, by the server computer, the access data to the communication device in response to receiving the authorization response message; and storing, by the communication device, the access data in a secure area of the communication device.

2. The method of claim 1, wherein the communication device is a mobile phone and the user device is a card.

3. The method of claim 1, wherein the cryptogram is formed using a DES or triple DES encryption process.

4. The method of claim 1, further comprising: verifying, prior to providing the access data to the communication device, that the authorization response message includes a positive authorization indicator.

5. The method of claim 1, wherein the first message format is an HTTP / S message format and the second message format is an ISO 8583 message format.

6. The method of claim 1, wherein the authorization request message further includes a symbolic value.

7. The method of claim 1, wherein the value includes a symbolic amount, and the method comprises: sending, by the server computer, a transaction reversal message to the authorization computer for the symbolic amount.

8. The method of claim 1, wherein the second cryptographic key is derived on the user device.

9. The method of claim 1, wherein the access data includes data that can allow a user of the communication device to access a secure location.

10. A server computer comprising: a processor; and a memory. A computer-readable medium comprising code executable by the processor to implement a method comprising: receiving, by the server computer from a communication device, an initialization request message to provide access data to a service provider application on the communication device; providing, by the server computer to the communication device, a dynamic data element in response to the initialization request message; performing, by the communication device emulating an access device, a message exchange process with a user device, wherein in the message exchange process, a value is sent from the communication device to the user device and a cryptogram is received by the communication device from the user device, wherein the cryptogram is formed using the dynamic data element, a user device identifier, and a first cryptographic key; receiving, from the communication device, a provisioning request message comprising the user device identifier and the cryptogram in a first message format; generating an authorization request message in a second message format, the authorization request message comprising the cryptogram, the user device identifier, the dynamic data element, and the value; sending the authorization request message to an authorization computer, wherein the authorization computer extracts the cryptogram from the authorization request message, decrypts the cryptogram using a second cryptographic key to determine a recovered dynamic data element, and determines that the recovered dynamic data element matches the dynamic data element; receiving an authorization response message from the authorization computer; providing access data to the communication device in response to receiving the authorization response message; and storing, by the communication device, the access data in a secure area of the communication device.

11. The server computer of claim 10, wherein the authorization request message comprises a zero value amount, the cryptogram, and the user device identifier.

12. The server computer of claim 10, wherein the authorization response message comprises the user device identifier and an authorization indicator.

13. The server computer of claim 10, wherein the access data comprises a token.

14. The server computer of claim 10, wherein the method further comprises: providing, by the server computer to the communication device, the dynamic data element comprising a random number, wherein the cryptogram is formed using the dynamic data element and the user device identifier.

15. A method for a communication device to obtain access data, the method comprising: sending, by the communication device emulating an access device, an initialization request message to a server computer to provision access data to a service provider application on the communication device; receiving, by the communication device from the server computer, a dynamic data element in response to the initialization request message; providing, by the communication device to a user device, the dynamic data element; performing, by the communication device, a message exchange process with the user device, wherein the user device generates a cryptogram using the dynamic data element, a first encryption key, and a user device identifier, wherein, in the message exchange process, a value is sent from the communication device to the user device and the cryptogram is received by the communication device from the user device; sending, by the communication device, a provisioning request message including the user device identifier and the cryptogram to the server computer in a first message format, the server computer generating an authorization request message in a second message format, the authorization request message including the cryptogram, the user device identifier, the dynamic data element, and the value, wherein the server computer sends the authorization request message to an authorization computer, the authorization computer verifying the cryptogram by extracting the cryptogram from the authorization request message, decrypting the cryptogram using a second encryption key to determine a recovered dynamic data element, and determining that the recovered dynamic data element matches the dynamic data element; receiving, by the communication device, the access data in response to sending the provisioning request message; and storing, by the communication device, the access data in a secure area of the communication device.

16. The method of claim 15, wherein the communication device is a mobile phone and the user device is a card.

17. The method of claim 15, wherein the cryptogram is generated by encrypting using the second encryption key on the user device, and at least the dynamic data element and the user device identifier.

18. The method of claim 15, wherein the server computer is in communication with an access data vault, and wherein the server computer retrieves the access data from the access data vault and sends the access data to the communication device after receiving an authorization response message from the authorization computer in response to the authorization request message.

19. The method of claim 15, wherein the provisioning request message is in an XML data format.

Images