CN107636664B

CN107636664B - Method, device and apparatus for provisioning access data to a mobile device

Info

Publication number: CN107636664B
Application number: CN201680026340.9A
Authority: CN
Inventors: G·鲍威尔; J·希茨; K·瓦格纳
Original assignee: Visa International Service Association
Current assignee: Visa International Service Association
Priority date: 2015-05-07
Filing date: 2016-04-06
Publication date: 2021-11-23
Anticipated expiration: 2036-04-06
Also published as: CN114077725A; WO2016178780A1; CN107636664A

Abstract

A method and system for provisioning access data to a second application on a mobile device using a first application on the mobile device. Authentication data may be entered into the first application and an authentication code may be requested from a remote server. The authentication code may include access data to be supplied in encrypted form. After the first application in the mobile device receives the authentication code, the first application may pass the authentication code to a second application that initiates an access data provisioning process.

Description

Method, device and apparatus for provisioning access data to a mobile device

Cross Reference to Related Applications

This application claims benefit of U.S. provisional application No.62/158,503 filed on day 7, 5/2015 and U.S. provisional application No.14/707,788 filed on day 8, 5/2015. All of these applications are incorporated herein by reference in their entirety for all purposes.

Background

The mobile phone may use the access data to gain access to the resource or location. For example, a mobile phone may include data communicated to an access device to allow a user of the mobile phone to access a room in a building. In another example, the mobile phone may have access data, such as account data, that may allow a user of the mobile phone to access an account to obtain goods.

In many cases, the resource provider may provide access data to the mobile phone. For example, a building operator system may supply a mobile phone with data that allows a user of the mobile phone to access a building. In another example, a bank may provide access data for a mobile phone that allows a user of the mobile phone to access an account at the bank. In this particular case, the resource provider can verify that the user of the mobile phone is actually the real user. Thus, the transfer of access data to the mobile phone is relatively secure.

In some cases, a mobile device may contain applications that may perform multiple functions and/or may perform functions for more than one resource provider. In one example, a single application on a mobile phone that is to perform multiple functions or services for many resource providers may not be directly related to the resource provider associated with the functions or services. In this case, there may be trust issues because the resource provider may not have control over the individual applications. For example, if the access data provided by the service provider is highly sensitive, the service provider may not be able to fully control any security features of a single mobile application. Furthermore, if the user requests that the resource provider provide access data to the user's mobile phone, the user may also not trust that the data in the individual mobile application is secure.

Furthermore, in today's world, many different entities need to collaborate in order to provide access data onto mobile devices. For example, in order to provision access data to a mobile phone for a transaction at a point of sale, cooperation may be required between the handset manufacturer, the digital wallet provider, the bank, the mobile network operator and the service provider sending the access data to the mobile device. Since many parties are involved in the access data provisioning process, sensitive authentication data and access data may be passed between various entities and thus may be exposed to man-in-the-middle attacks or hackers. It is also difficult to ensure that the user's sensitive access data and other confidential information is adequately protected while the provisioning process takes place.

Embodiments of the present invention relate to methods and systems for improving data security. Embodiments of the present invention address these and other problems, individually and collectively.

Disclosure of Invention

Embodiments of the present invention relate to methods and systems for improving security when provisioning access data to a mobile device.

One embodiment of the present invention is directed to a method that includes receiving, by a validation entity computer, an authentication code. The method also includes decrypting, by the verifying entity computer, the encrypted portion of the authentication code to obtain the access data. The method also includes initiating, by the experience recognition computer, a provisioning of the access data to the mobile device.

Another embodiment of the invention relates to a laboratory verification computer configured to perform the above method.

Another embodiment of the invention is directed to a method. The method includes receiving, by the mobile device, user authentication data at a first application on the mobile device and then sending the user authentication data to an authorization computer system. The method also includes receiving, by the mobile device, an authentication code from the authorizing computer system via the first application. The authentication code may be derived from the access data. The authentication code is then provided from the first application to a second application on the mobile device. The mobile device then provides the authentication code to the verification entity computer. The validation entity computer validates the authentication code and obtains access data from the authentication code. It may then instruct the provisioning server computer to provide the access data to a second application on the mobile device.

Another embodiment of the invention relates to a mobile device configured to perform the above method.

These and other embodiments are described in more detail below with reference to the figures and detailed description.

Drawings

Fig. 1 shows a block diagram of a system according to an embodiment of the invention.

Fig. 2 shows a block diagram of a mobile device according to an embodiment of the invention.

FIG. 3 shows a block diagram of an authorization computer, according to an embodiment of the invention.

FIG. 4 shows a block diagram of an experience validation computer, according to an embodiment of the present invention.

Fig. 5 shows a flow diagram illustrating a method for providing an authentication code to a second application on a mobile device.

Fig. 6 shows a flow chart illustrating a method for provisioning an access device to a mobile device.

Fig. 7 shows a block diagram illustrating the system and flow sequence of another embodiment of the present invention.

Fig. 8 shows a block diagram of a building access system.

FIG. 9 illustrates a block diagram of a transaction processing system that may use a mobile device having access to data.

Fig. 10 shows a block diagram of a computer.

Detailed Description

Embodiments of the present invention may provide a number of different mechanisms that may enhance security when accessing resources through untrusted applications on mobile devices. In some embodiments, this may be accomplished by requesting an authentication code via a trusted application on the mobile device. In some embodiments, the activation code may include an encrypted time data element such that the activation code is time-limited. The verification body computer may use the time data element to determine whether the activation code is still valid.

Some embodiments of the invention may include receiving, by a mobile device, user authentication data into a first application on the mobile device. Once the user authentication data is received by the first application on the mobile device, it is sent to the authorizing computer system. The authorization computer system then verifies the authentication data. After the authorization computer system verifies the authentication data, the authorization computer system may then generate and send an authentication code to the first application in the mobile device. After the mobile device receives the authentication code, a first application in the mobile device may provide the authentication code to a second application on the mobile device through a second application API (application programming interface). A second application in the mobile device may then provide the authentication code to the verification entity computer. After the validation entity computer verifies the authentication code, the validation entity computer may send an instruction to the provisioning server to provide the access data to a second application in the mobile device.

In some embodiments, the authentication code may be a mobile banking authentication code and the first application may be a mobile banking application. Once the consumer has been authenticated or authorized by the issuer for the purpose of personalizing the consumer's account information to the mobile device, an authentication code may be generated by the issuer. The authentication code may be communicated to a party that will provision the account data to the mobile device. The party may authenticate the code before performing the provisioning process.

A high-level process flow according to an embodiment of the invention may be described as follows. First, the issuer verifies the consumer's identity and confirms that the consumer is authorized to receive payment account information on his mobile device. Second, the issuer securely creates an authentication code using its server computer. Third, the issuer passes the authentication code to the issuer's mobile banking application on the consumer's mobile device. Fourth, the mobile banking application passes the authentication code to the digital wallet provider application on the mobile device through an API (application programming interface). The digital wallet provider application in the mobile device then provides the authentication code to the remotely located digital wallet server computer. Fifth, the digital wallet server computer then transmits the authentication code to the validation entity computer, which may initiate provisioning of payment account data or activation of the payment account in the digital wallet provider application on the mobile device. Once the digital wallet provider application on the mobile device is provisioned with the payment account data, the mobile device may be allowed or authorized to conduct payment transactions.

Before discussing detailed embodiments of the invention, some description of certain terms may be useful.

A "mobile device" may include any electronic device that a user may carry and operate, and that may also provide remote communication capabilities with a network. Examples of remote communication capabilities include the use of a mobile telephone (wireless) network, a wireless data network (e.g., 3G, 4G, or the like), Wi-Fi, Wi-Max, or any other communication medium that may provide network access such as the internet or a private network. Examples of mobile devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, netbooks, laptop computers, personal music players, handheld dedicated readers, wearable devices (e.g., watches), vehicles (e.g., automobiles), and so forth. A mobile device may include any suitable hardware and software for performing such functions, and may also include multiple devices or components (e.g., two devices used together may be considered a single mobile device when the devices remotely access a network by being tethered to another device-i.e., using the other device as a relay).

"authentication data" may include any data suitable for authenticating a user or mobile device. The authentication data may be obtained from the user or a device operated by the user. Examples of authentication data obtained from a user may include a PIN (personal identification number), a password, and the like. Examples of authentication data that may be obtained from a device may include a device serial number, a hardware secure element identifier, a device fingerprint, a telephone number, an IMEI number, and the like.

The "verification entity computer" may be any suitable computer that can verify data. In an embodiment of the invention, the data that can be verified may include an authentication code. The data may be operated by a validation entity such as a payment organization, payment processing network, transit authority (transit authority), building system, ticketing system, or the like.

The "provisioning server computer" may include any suitable computer that may provision access data to a device.

"Access data" may include any suitable data that may be used to access a resource or create data that may access a resource. In some embodiments, the access data may be account information for a payment account. The account information may include a PAN, a payment token, an expiration date, and a verification value (e.g., CVV2, dCVV2), and so forth. In other embodiments, the access data may be data that may be used to activate account data. For example, in some cases, account information may be stored on the mobile device, but may not be activated until the mobile device receives certain information. In some embodiments, the specific information may be characterized as access information. In other embodiments, the access data may include data that is usable to access the location. Such information may be ticket information for the event, data for accessing the building, transit ticket information, and the like.

The "access data reference identifier" may include an identifier that may identify the access data rather than the actual access data itself. The access data reference identifier may be used to identify the particular access data. For example, a primary account number such as 4000819882981132 may be represented by an account reference identifier such as XP 28278978. In embodiments of the invention, the account reference identifier cannot be used to conduct transactions, but can be used as a security mechanism to allow different entities to take action with respect to the account without using the real account number.

An "application" may be a computer program for a specific purpose.

The "time data element" may include data relating to any suitable time. For example, the time data element may be a time, a date, a month, a year, or any suitable combination of the foregoing. The time data elements may also be derived from time, date, month, year, or any suitable combination of the above. The encrypted time data element may be a data element that may include an encrypted time, date, month, year, and/or suitable combination of the above.

An "access device" may be any suitable device for obtaining access to a resource. The access device may generally be located at any suitable location, such as at a merchant location. The access device may be in any suitable form. Some examples of access devices include POS devices, cellular phones, PDAs, Personal Computers (PCs), tablets, handheld application specific readers, set-top boxes, Electronic Cash Registers (ECRs), Automated Teller Machines (ATMs), Virtual Cash Registers (VCRs), kiosks, security systems, access systems, websites, and the like. The access device may use any suitable contact or contactless mode of operation to send or receive data from or in association with the payment device and/or with the user mobile device.

An "authorization request message" may be an electronic message sent to the payment processing network and/or the issuer of the payment card to request authorization for a transaction. The authorization request message according to some embodiments may conform to ISO 8583, which is a standard of systems for exchanging electronic transaction information associated with payments made by consumers using payment devices or payment accounts. The authorization request message may include an issuer account identifier that may be associated with the payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information," including, for example only: a service code, a CVV (card verification value), a dCVV (dynamic card verification value), an expiration date, etc. The authorization request message may also include "transaction information," e.g., any information associated with the current transaction, such as the transaction amount, merchant identifier, merchant location, etc., and may be used to determine whether to identify and/or authorize the transaction.

The "authorization response message" may be an electronic message reply to an authorization request message generated by the issuing financial institution or the payment processing network. The authorization response message may include, by way of example only, one or more of the following status indicators: approval-transaction approved; decline-transaction not approved; or call center-in response to waiting for more information, the merchant must dial a toll-free authorized telephone number. The authorization response message may also include an authorization code, which may be a code indicating that the transaction is approved that the credit card issuing bank returned to the merchant's access device (e.g., POS device) in response to the authorization request message in the electronic message (either directly or through the payment processing network). The code may serve as proof of authorization. As described above, in some embodiments, the payment processing network may generate or forward an authorization response message to the merchant.

A "server computer" is typically a powerful computer or cluster of computers. For example, a server computer may be a mainframe, a minicomputer cluster, or a group of servers as a unit. In one example, the server computer may be a database server coupled to a Web server.

A "processor" may refer to any suitable data computing device or devices. The processor may include one or more microprocessors that work together to achieve the desired functionality. The processor may comprise a CPU including at least one high speed data processor sufficient to execute program components for performing user and/or system generated requests. The CPU may be an AMD microprocessor such as Athlon, Duron and/or Opteron; PowerPC from IBM and/or Motorola; cell processors by IBM and Sony; intel's saint, itanium, pentium, to strong and/or XScale; and/or the like.

A "memory" may be any suitable device or devices that can store electronic data. Suitable memories may include non-transitory computer-readable media that store instructions that are executable by a processor to implement a desired method. Examples of memory may include one or more memory chips, disk drives, and the like such memory may operate using any suitable electrical, optical, and/or magnetic mode of operation.

I. System for controlling a power supply

Fig. 1 shows a block diagram of a system according to an embodiment of the invention. Fig. 1 shows a mobile device 10 in communication with an authorization computer system 40, a provisioning server computer 90, and a digital wallet server computer 60. The mobile device 10 may store a first application 20A and a second application 20B. The experience verification computer 80 communicates with the provisioning server computer 90 and the digital wallet server computer 60. Authorization computer system 40 communicates with authentication entity computer 80.

The provisioning server computer 90 may be configured to provision the access data to the mobile device 10. The provisioning server computer may include a processor and a computer-readable medium including code to cause the processor to perform any suitable method associated with provisioning access data to the mobile device 10. It may also maintain a database of addresses (e.g., IP or internet protocol addresses or telephone numbers) for various mobile devices that may be provisioned with access data. The provisioning server computer may also maintain a database of access data to be provisioned. The access data to be provisioned may have been previously obtained by the issuer operating authorization computer system 40 and/or the payment processor operating validation authority computer 80.

The digital wallet server computer 60 may be configured to maintain digital wallets associated with users of the mobile device 10 as well as other users. A "digital wallet" may store user profile information, payment information (e.g., PAN or primary account number, payment token (i.e., PAN substitute), verification value such as CVV, etc.), bank account information, and/or the like, and may be used in various transactions such as, but not limited to, e-commerce for retail purchases, social networking, money transfer/personal payment, mobile commerce, proximity payments, games, and/or the like, digital merchandise purchases, utility payments, purchases of games or game credits from gaming websites, transfers funds between users, and the like.

Each of the entities in fig. 1 may communicate over any suitable communication channel or communication network. Suitable communication networks may be any one and/or combination of the following: a direct interconnection; an internet; a Local Area Network (LAN); metropolitan Area Networks (MANs); an operation task (OMNI) as an Internet node; a secure custom connection; a Wide Area Network (WAN); wireless networks (e.g., using protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.); and/or the like.

Fig. 2 shows a block diagram of a mobile device 10 according to an embodiment of the invention. In some embodiments, the mobile device 10 may be a payment device that may be used to make payments or a device that may allow a user to gain access to a location. Exemplary mobile device 10 may include a computer readable medium 10B that may reside within a body 10H of the mobile device 10. The computer-readable medium 10B may be in the form of a memory that stores data. In some cases, memory 10B may also store information such as access data. In general, any of this information may be transmitted by the mobile device 10 to another device using any suitable method, including using the antenna 10A or the contactless element 10G. The body 10H may be in the form of a plastic substrate, housing or other structure.

The computer-readable medium 10B may include code executable by a processor for implementing a method including receiving user authentication data at a first application on a mobile device; sending, by the mobile device, user authentication data to the authorizing computer system; receiving, by the mobile device, an authentication code from the authorizing computer system via the first application; providing, by the mobile device, the authentication code from the first application to a second application on the mobile device; providing, by the mobile device, the authentication code to a verification entity computer, wherein the verification entity computer verifies the authentication code; and receiving access data from the provisioning server in communication with the authentication entity computer. In some embodiments, the authentication code may be derived from the access data such that a validation entity computer receiving the authentication code may simply decrypt the authentication code to obtain the necessary information to provision the access data for the mobile device.

In some embodiments, the mobile device 10 may also include a contactless element 10G, typically implemented in the form of a semiconductor chip (or other data storage element) having an associated wireless transmission (e.g., data transmission) element, such as an antenna. The contactless element 10G may be coupled to (e.g., embedded in) the mobile device 10, and data or control instructions transmitted over a cellular network may be applied to the contactless element 10G through a contactless element interface (not shown). The contactless element 10G may be capable of transmitting and receiving data using a short-range wireless communication capability. As mentioned above, the mobile device 10 may include components that are both interrogator devices (e.g., receiving data) and interrogated devices (e.g., sending data). Thus, the mobile device 10 may be capable of communicating and transmitting data or control instructions over cellular networks (or any other suitable wireless networks, such as the Internet or other data networks) and short-range communications.

The mobile device 10 may also include a processor 10C (e.g., a microprocessor) for processing functions of the mobile device 10 and a display 10D that allows the consumer to view telephone numbers and other information and messages. The mobile device 10 may also include an input element 10E to allow a user to input information into the device, a speaker 10F to allow a user to hear voice communications, music, etc., and a microphone 10I to allow a user to transmit her voice through the mobile device 10. The mobile device 10 may also include an antenna 10A for wireless data transfer (e.g., data transmission).

The memory 20 may be coupled to the processor 10C and may store a first application 20A and a second application 20B. The memory 20 may be in the form of one or more memory devices (e.g., RAM, EEPROM, ROM chips) using any suitable data storage scheme. In some embodiments, the memory 20 in the mobile device 10 may also include a secure storage area for storing sensitive data such as payment credentials (account numbers, payment tokens, verification values, etc.) and access data. For example, the memory 20 may be part of or may contain a secure element.

In some embodiments, first application 20A is an application specifically associated with authorization computer system 40 and is generally trusted by an authorization entity associated with authorization computer system 40. The first application 20A may be, for example, an issuer application, such as a mobile banking application. Such applications are typically designed by an authorized entity and may include data security measures that are specifically required by the authorized entity.

The second application 20B may be associated with an entity such as a digital wallet server computer 60. Since the second application 20B is not developed by an authorized entity, the second application 20B is typically less trusted by an authorized entity operating an authorized computer. Examples of the second application may include a digital wallet application, a merchant application, a fitness application, and any other suitable application that may be present on the mobile device 10.

FIG. 3 shows a block diagram of an authorization computer system 40 according to an embodiment of the invention. Fig. 3 shows a server computer 40A and an account data database 40B coupled to server computer 40A.

Account data database 40B may hold accounts for various users that are affiliated with the authorizing entity associated with the authorizing computer system. For example, the authorizing entity may be the issuer bank, and database 40B may store account information for credit and debit card accounts of customers of the issuer bank.

Database 40B (as well as any other databases described herein) may be a conventional, fault-tolerant, relational, extensible, secure database, such as Oracle^TMOr Sybase^TM. Database 1204 may be implemented using various standard data structures such as arrays, hashes, (linked) lists, structured text files (e.g., XML), tables, and/or the like. Such data structures may be stored in memory and/or in (structured) files.

Server computer 40A may include a processor 41 that may be coupled to a system memory 42 and an external communication interface 43. A computer readable medium 44 may also be operatively coupled to the processor 41.

Computer-readable media 44 may include a plurality of software modules, including a communication module 44A, an encryption module 44B, a database update module 44C, an authentication code generation module 44D, an authorization module 44E, and a verification module 44F.

Communication module 44A may include code that causes processor 41 to generate messages, forward messages, reformat messages, and/or otherwise communicate with other entities.

In embodiments of the present invention, encryption module 44B may include any suitable encryption algorithm for encrypting data. Suitable data encryption algorithms may include DES, triple DES, AES, and the like. The encryption module may also store encryption keys that may be used with such encryption algorithms. Encryption module 44B may utilize symmetric or asymmetric encryption techniques to encrypt and/or verify data.

Database update module 44C may work with processor 41 to update account information in account data database 40B.

The authentication code generation module 44D may include computer code that, when executed by the processor 41, generates an authentication code. The specific authentication code generation process is described in detail below.

Authorization module 44E may include code that may cause processor 41 to evaluate an authorization request message for a transaction and determine whether the transaction should be authorized. Such transactions may be authorized or denied based on a number of factors including the potential level of fraud and/or the amount of funds or credit associated with the account used to conduct the transaction.

Authentication module 44F may include code that causes processor 41 to authenticate authentication credentials received from a user's mobile device. Validation module 44F may include code for causing processor 41 to retrieve data from database 40B and compare the data to the received data.

The computer-readable medium 44 may include code executable by a processor to implement a method comprising: receiving, by an authorization computer and from a mobile device, authentication data; verifying, by the authorization computer, the authentication data; determining that the authentication data is valid in response to determining that the authentication data is valid; creating an authentication code, wherein the authentication code comprises a first portion and a second portion, the first portion comprising encrypted information, the encrypted information comprising encrypted time data elements, and the second portion comprising unencrypted information, the unencrypted information capable of being used to process unencrypted information; and sending the authentication code to the mobile device, wherein the authentication code is provided to a validation authority computer that initiates provisioning of the access data to the mobile device.

FIG. 4 shows a block diagram of an experience verification computer 80, according to an embodiment of the invention. In some embodiments of the invention, the experience computer 80 may also be in a payment processing network. The experience computer 80 may include a processor 81, which may be coupled to a system memory 82 and an external communication interface 83. A computer readable medium 84 may also be operatively coupled to the processor 81.

In some embodiments, the verification computer 80 may be part of a payment processing network that switches transaction requests and responds between issuers and acquirers. The payment processing network may be a transaction processing network. The transaction processing network may process payment transactions or other types of access transactions.

The computer-readable medium 84 may include a plurality of software modules, including a communications module 84A, a settlement module 44B, a code verification module 84C, an authorization module 84D, and an encryption module 84E.

The communication module 84A may include code that causes the processor 81 to generate messages, forward messages, reformat messages, and/or otherwise communicate with other entities.

Settlement module 84B may include code that causes processor 81 to settle transactions between various entities, including issuers and acquirers.

The code verification module 84C may include code that causes the processor 81 to analyze the received authentication code to determine if the received authentication code is valid. In some embodiments, the verification module 84C may obtain the most recently received authentication code and may decrypt (or cooperate with the encryption module 84E) any encrypted data. The verification module may then retrieve the previously received authentication code previously received from the authorizing computer system 40 and also decrypt any encrypted data. Alternatively, the data received from the authorizing computer system 40 may be the access data itself (without receiving the authentication code). The decrypted data from the received authentication code may be evaluated and compared to previously received access data or to decryption information from a previously received authentication code to determine if a match exists (thereby verifying the received authentication code). The code verification module 84C may also include code that causes the processor 81 to receive the authentication code, decrypt the encrypted portion of the authentication code to obtain the access data, and initiate provisioning of the access data to the mobile device.

Authorization module 84D may include code that may cause processor 81 to evaluate an authorization request message for a transaction and determine whether the transaction should be authorized. The authorization module may also include code for routing or modifying authorization request and response messages as they pass between parties, such as the issuer and the acquirer.

In embodiments of the present invention, encryption module 84E may include any suitable encryption algorithm for encrypting data. Suitable data encryption algorithms may include DES, triple DES, AES, and the like. The encryption module may also store encryption keys that may be used with such encryption algorithms. The other keys of any corresponding key pair may be stored in encryption module 44B in authorizing computer system 40. The encryption module 84E may utilize symmetric or asymmetric encryption techniques to encrypt and/or verify data.

And II, performing treatment. Method of producing a composite material

Fig. 5 shows a flow diagram illustrating a method for providing an authentication code to a second application on a mobile device. Fig. 6 shows a flow chart illustrating a method for provisioning access data to a mobile device. The methods shown in fig. 5-6 may also be described with reference to the system diagram of fig. 1. Although the methods described in detail below may relate to payment processing, embodiments of the invention may be applied to other areas where payment is not required.

Prior to step S102, the user may wish to load access data into the second application 20B. In some embodiments, the second application 20B may be a digital wallet application that is associated with the digital wallet server computer 60. The access data may be payment account data, such as credit card account data, or activation data that may be used to activate payment account data already resident on the mobile device.

In embodiments of the present invention, the user may initiate the loading process by launching or otherwise interacting with the first application 20A on the mobile device 10. The first application 20A may be an issuer application (e.g., a mobile banking application) that is associated with the authorizing computer system 40. The authorizing computer system may be an issuer computer system. In other embodiments, the second application 20B may be launched first, and this may invoke or cause the launching of the first application 20A. If the second application 20B invokes the launch of the first application 20A, in some embodiments, the second application 20B may pass the mobile device identifier and/or the second application identifier to the first application 20A. Such identifiers may be used by subsequent downstream entities (e.g., authorizing computer system 40) to help identify mobile devices to be provisioned (if device information is not already resident at those downstream entities).

After the first application 20A is launched, the first application 20A may present the user with the option of loading an account number (e.g., a credit card account number) into the second application 20B. In doing so, the first application may also require the user to enter authentication data for the user, and optionally any account identifiers associated with the account number to be loaded into the second application 20B. For example, the first application 20A may ask the user of the mobile device 10 for a previously identified PIN (personal identification number) or password, and optionally a username. Alternatively or additionally, the first application 20A may collect authentication data (e.g., serial number, phone number, digital fingerprint, etc.) directly from the mobile device 10. In some cases, this may be done automatically, without any user input or action.

In step S102, authentication data is transmitted from the mobile device 10 and received at the authorizing computer system 40. The authentication data may be sent from mobile device 10 to authorizing computer system 40 using any suitable electronic message format, including an email, a Short Message Service (SMS) message, a Multimedia Message Service (MMS) message, a hypertext transfer protocol (HTTP) request message, a Transmission Control Protocol (TCP) packet, a Web form submission, and so forth. The message may be directed to any suitable location, such as an email address, a telephone number, an Internet Protocol (IP) address, or a Uniform Resource Locator (URL). The other communications described with reference to fig. 1 may be conducted in the same or different manners.

In step S104, the authorization computer system 40 verifies the authentication data. It can be treated in the following way: the authentication data previously stored for the user is retrieved and the retrieved authentication data is then compared with the received authentication data. For example, the authorization computer system 40 may store a password, may receive a corresponding password from the mobile device 10, and may determine whether the stored password matches the received password. If the received authentication data does not match the previously stored authentication data, a message may be generated by the authorizing computer system 40 and sent to the mobile device 10 to indicate that the entered authentication data is incorrect.

In step S106, if the received authentication data matches the previously stored authentication data, the authorizing computer system 40 may generate an authentication code.

The authentication code may be generated in any suitable manner. An encryption process may be used to generate the authentication code. In some embodiments, the authentication code may include an encrypted portion and an unencrypted portion. The non-encrypted portion may be used to decrypt the encrypted portion. In addition, the encrypted portion may include the consumer's primary account identifier (PAN), the date and time when the authentication code (an example of a time data element) was generated or when the user was verified by the authorized entity, and the particular authorization code generated by the authorized entity. By encrypting the date and time when the authentication code was generated or when the user was verified by an authorized entity, the verifying entity computer that verified the authentication code can determine whether it is still valid. A specific method of generating an authentication code according to an embodiment of the present invention is described in further detail below. Further, by creating an authentication code having an encrypted portion and an unencrypted portion, the authentication code can include information on how to recover any secrets present in the encrypted portion. Multiple separate data transmissions are not required to provide information regarding decryption of encrypted information.

In step S108, after generating the authentication code, in some embodiments, the authentication code may be provided to the verification entity computer 80 using a communication path that is separate from and not involving the mobile device 10 or the digital wallet server computer 60. The verification entity computer 80 may store the received authentication code in a database. In other embodiments, the validation entity computer may receive the access data and may not receive the actual authentication code.

In step S110, an authentication code is sent from the authorizing computer system 40 to the first application 20A in the mobile device 10.

After the first application 20A in the mobile device 10 receives the authentication code, the first application 20A then passes the authentication code to the second application 20B in the mobile device 10 through an appropriate API (application programming interface) in step S112.

After receiving the authentication code by the second application 20B, the mobile device 10 then sends the authentication code to the digital wallet server computer 60 in step S114 using any suitable electronic message format.

After the digital wallet server computer 60 receives the authentication code, the digital wallet server computer 60 then sends the authentication code to the verification entity computer 80 using any suitable electronic message format in step S116.

After the authentication code is received by the authentication code computer 80, the authentication code is then verified by the authentication computer 80 in step S118. In some embodiments, the validation module 84C in the validation verification computer 80 may employ the most recently received authentication code and may decrypt (or cooperate with the encryption module 84E) any encrypted data. The verification module may then retrieve the previously received authentication code (stored in the database) previously received from the authorizing computer system 40 and also decrypt any encrypted data. The decrypted data from the previously stored authentication code and the most recently received authentication code may then be compared to determine whether the currently received authentication code and the previously stored authentication code match (thereby verifying the received authentication code). In other embodiments, the access data may have been previously received by the experience verification computer 80 from the authorizing computer system 40. The access data may be retrieved from the database and compared with decryption information from the received authentication code. If there is a match, and if the authentication code is otherwise valid (e.g., within a predetermined time period), the received authentication code may be verified.

The validation verification computer 80 and the authorizing computer system 40 may share symmetric encryption keys that will allow them to encrypt and decrypt the authentication code or portions of the authentication code. In other embodiments, the authorizing computer system and the verifying entity computer may encrypt a portion of the authentication code with the public key and decrypt the portion of the authentication code with the private key, respectively. If the authentication code received from the authorizing computer system 40 does not match the authentication code received from the digital wallet server computer 60, a message may be sent to the mobile device 10 indicating that the provisioning request failed.

In step S120, if the received authentication code is valid, then the proof-bodied computer 80 initiates the provisioning process. This can be done in a number of ways. In some cases, the verification entity computer 80 may send a message to the provisioning server computer 90 requesting that the second application of the mobile device be provisioned with the access data requested by the user of the mobile device 10. In another embodiment, the provisioning server computer 90 may be part of the authentication entity computer 80 and may initiate provisioning without sending any specific provisioning instruction message. If a provisioning instruction message is used, it may include details needed to provision the mobile device 10 with access data. Such details may include the access data itself (if the access data is not already stored at the provisioning server computer 90), an address (e.g., a telephone number) associated with the mobile device 10 to be provisioned, any data used by the mobile device 10 that allows the mobile device 10 to accept the access data, and so forth. The experience computer 80 and/or the provisioning server computer 90 may have received access data from the authorizing computer system 40 at some time in the past through different communications. In some embodiments, the access data may be derived from an authentication code, as described below.

In step S122, the provisioning server computer 90 sends the access data to the second application 20B in the mobile device 10 for storage. In some embodiments, the provisioning server computer 90 may store one encryption key (e.g., an ephemeral public ECC key) and the mobile device 10 may store another corresponding encryption key. The provisioning server computer 90 may then encrypt the access data before sending it to the mobile device 10, and the mobile device 10 may decrypt the encrypted access data upon receipt. Once the mobile device 10 receives and stores the access data, the mobile device 10 may thereafter be used to conduct payment transactions using the second application 20B and the access data supplied to it. In some cases, the access data may be stored in a secure area (e.g., a secure element) in the mobile device 10.

The above-described process may be used to provision mobile devices with static or dynamic access data. If the access data is dynamic, it may be provided to the mobile device for each transaction or a predetermined number of transactions (e.g., every 5-10 transactions). This helps to ensure that the risk of fraud caused by man-in-the-middle attacks is reduced.

Fig. 7 shows a system block diagram illustrating a method according to other embodiments of the invention.

Prior to step S202, the user may want to supply access data into the second application 20B. In some embodiments, the second application 20B may be a digital wallet application that is associated with the digital wallet server computer 60. The access data may be payment account data such as credit card account data.

The user may initiate the provisioning process by launching or otherwise interacting with the first application 20A on the mobile device 10. In some embodiments, this may be done without any initial interaction with the second application 20B. The first application 20A may be an issuer application (e.g., a mobile banking application) that is associated with the authorizing computer system 40. The authorizing computer system may be an issuer computer system. The second application 20B may be a digital wallet application that is associated with a digital wallet server computer 60.

After the first application 20A is launched, the first application 20A may present the user with the option of loading an account number (e.g., a credit card account number) into the second application 20B. In doing so, the first application 20A may also require the user to enter authentication data for the user, and optionally any account identifiers associated with the account number to be loaded into the second application 20B. For example, the first application 20A may ask the user of the mobile device 10 for a previously identified PIN (personal identification number) or password and username. In some cases, the PIN or password and username may simply be user credential information needed to access the authorizing computer system 40 using the first application 20A. Alternatively or additionally, the first application 20A may collect authentication data (e.g., serial number, phone number, digital fingerprint, etc.) directly from the mobile device 10. In some cases, this may be done automatically, without any user input or action.

In step S202, authentication data is sent from the mobile device 10 and received at the authorizing computer system 40. The authentication data may be sent from the mobile device 10 to the authorizing computer system 40 (as described above with reference to fig. 1) using any suitable electronic message format. The other communications described with reference to fig. 7 may be performed in the same or different manners.

In step S204, the authorization computer system 40 verifies the authentication data. It can be treated in the following way: the authentication data previously stored for the user is retrieved and the retrieved authentication data is then compared with the received authentication data. For example, the authorization computer system 40 may store a password, may receive a corresponding password from the mobile device 10, and may determine whether the stored password matches the received password. If the received authentication data does not match the previously stored authentication data, a message may be generated by the authorizing computer system 40 and sent to the mobile device 10 to indicate that the entered authentication data is incorrect.

In step S206, after the authorization computer system 40 verifies the authentication data. The authorizing computer system 40 then sends a response back to the first application 20A on the mobile device 10.

In step S207, the second application 20B (and optionally the digital wallet server computer 60) is queried by the first application 20A to determine if any account data held by the authorizing computer system 40 has been provisioned to the second application 20A in the mobile device 10. The first application 20A may perform this operation by sending (S208) one or more access data reference identifiers, such as an account reference identifier for the user of the mobile device 10 that the access data has, to the second application (and optionally the digital wallet server computer 60). The account reference identifier may be associated with accounts that the user has with the issuer associated with the authorizing computer system 40. If the second application 20B has determined that access data (e.g., payment account data) associated with one or more account reference identifiers has been provisioned on the second application 20B on the mobile device 10, the second application 20B notifies the first application 20A on the same mobile device. In some embodiments, the second application 20B may send back to the first application 20A any account reference identifiers associated with the account data that have been provisioned to the second application 20B, which may then forward them to the authorization computer system 40. To enhance security, the second application 20B and the digital wallet server computer 60 may not communicate using actual account data (e.g., an actual primary account number), but may instead communicate using a payment account reference identifier.

In some embodiments, when the second application 20B returns one or more account reference identifiers to the first application 20A and the authorizing computer system 40 (or returns other indicators of previous provisioning of account data to the second application 20A), the second application 20B (or the digital wallet server computer 60) may send additional device-specific or event-specific information back to the authorizing computer system 40 via the first application 20A to ensure that the finally generated authentication code cannot be replayed by another user device. This may be done when one or more account reference identifiers are returned or at a different time. For example, the second application 20B or the digital wallet server computer 60) may have device-specific information, such as an identifier of the mobile device 10 or an identifier of the second application 20A (e.g., a wallet identifier), and may send this information (in clear text or hashed or encrypted form) to the first application 20A and then to the authorizing computer system 40. The identifier of the mobile device 10 or the second application 20A may be in any suitable form (e.g., any suitable length and/or number of characters). The type of event specific information that may be sent from the second application 20B or the digital wallet server computer 60 to the first application 20A, and then to the authorization computer 40, may include a timestamp and a random number. Such information may be sent in encrypted or clear form from the second application 20B or the digital wallet server computer 60 to the first application 20A and the authorization computer system 40.

Further, in some embodiments, to ensure that the verification entity computer 80 knows which mobile device 10 the request originated from, the event-specific information and/or the device-specific information may be signed with a cryptographic key (e.g., a cryptographic private key), which may reside in memory (e.g., a secure element) in the mobile device 10. The signature information may then be provided by the second application 20B to the first application 20A and then to the authorizing computer system 40.

Illustratively, the second application 20B may retrieve a cryptographic key (e.g., a private key) from a secure element in the mobile device 10, and may then use the key to sign the event-specific data or the device-specific data. This may be used at a later time by the authentication entity computer 80 to authenticate whether the mobile device 10 initiated a provisioning request. In some embodiments, the verification may be performed by the verification entity computer 60 using a public key (or private key) associated with the private key that signed the event-specific data or the device-specific data. For example, in some embodiments, the event-specific data may be a random number, and the random number may be signed by a private key residing in a secure element on the mobile device 10. The second application 20B may generate a random number and may retrieve the private key from the secure element on the mobile device 10 to sign it. The signed random number may then be provided to the authorizing computer system 40 alone or with the random number for inclusion in a subsequently generated authentication code. This will allow the verification entity computer 80 to confirm that the first application 20A and the second application 20B interact on the mobile device 10 and that the provisioning request came from the correct mobile device 10.

After the first application 20A receives the account number reference identifier from the second application 20B, the first application 20A and/or the authorizing computer system 40 may then determine which account data has not been provisioned to the mobile device 10 in step S208. The authorizing computer system 40 then optionally sends the primary account number or an alias of the primary account number that has not been provisioned to the second application 20B to the first application 20A in the mobile device 10. In the first application 20A, the user may select any of the presented primary account numbers (or aliases thereof) that have not yet been provisioned to the second application 20A so that they may be provisioned to the second application 20A.

In step S210, if the received authentication data matches the previously stored authentication data, and the authorizing computer system 40 has determined that there is account data to be provisioned, the authorizing computer system 40 may generate an authentication code.

The authentication code may be generated in any suitable manner. An encryption process may be used to generate the authentication code. In some embodiments, the authentication code may include an encrypted portion and an unencrypted portion. The unencrypted portion may include information that can be used to decrypt the encrypted portion and/or verify that the encrypted information is valid or from a valid source. For example, the encrypted or unencrypted portion may include the device specific information and/or event specific information described above, as well as a digitally signed version of the information. Further, the encrypted portion may include the consumer's primary account identifier (PAN), an expiration date, a date and time when an authentication code (an example of a time data element) was generated or when the user was verified by an authorized entity, and a particular authorization code generated by the authorized entity. By encrypting the date and time when the authentication code was generated or when the user was verified by an authorized entity, the verifying entity computer that verified the authentication code can determine whether it is still valid. The authentication code may also include (in encrypted form) the above-mentioned device-specific information and/or event-specific information. Signed device-specific information and/or event-specific information may also be included in the authentication code (e.g., in encrypted form).

In other embodiments, the device-specific information and/or event-specific information may be sent with the authentication code, but not included in the authentication code itself when it is transmitted from the authorizing computer system 40 to the verification entity computer 80.

A specific method of generating an authentication code according to an embodiment of the present invention is described in further detail below. Further, by creating an authentication code having an encrypted portion and an unencrypted portion, the authentication code can include information on how to recover any secrets present in the encrypted portion. Multiple separate data transmissions are not required to provide information regarding decryption of encrypted information.

In some embodiments, the authentication code is derived from the access data. In some embodiments, the authentication code may encrypt all access data so that the provisioning server computer may obtain all access data from the authentication code without separately obtaining this information from the authorizing computer system 40. For example, the authentication code may be derived from at least the primary account number and an expiration date associated with the primary account number, and optionally a verification value (such as a CVV or CVV2 value). In such embodiments, an authentication code may be received and used to obtain the primary account number, expiration date, CVV, and CVV 2. Because all access data may be derived from the authentication code in some embodiments of the present invention, the authorization computer system 40 need not provide the authentication verification computer 80 or the provisioning server computer 90 with the access data in a separate communication. This is particularly advantageous as it reduces communications that would otherwise be required between the authorization computer system 40 and the authentication entity computer 80 and the provisioning server computer 90. This is also advantageous as it provides increased security for any primary account number as there is no need to transmit a primary account number.

In addition to having all of the access data included within the authentication code itself, in some embodiments, any information needed to communicate the access data to the mobile device 10 may also be included in the authentication code. Such information may be an IP address, a telephone number, a digital wallet ID, a communication network ID, etc.

Further, in the provisioning system according to an embodiment of the present invention, the authorization system computer 40, the verification entity computer 80, and the digital wallet server computer 60 may be operated by different entities. Although it is relatively straightforward for a computer system to authenticate a user before provisioning access data to a mobile device, this is not straightforward when multiple different entities are involved in the provisioning process. It is also difficult to ensure that the user's sensitive access data and other confidential information is adequately protected while the provisioning process takes place. Embodiments of the present invention may protect access data as it passes between various entities in the system while also minimizing the number of communications required to provision the access data for the mobile device 10.

In step S230, in some embodiments, after generating the authentication code, the authentication code may be provided to the verification entity computer 80 using a communication path that is separate from and not involving the mobile device 10 or the digital wallet server computer 60. The verification entity computer 80 may store the received authentication code in a database. In other embodiments, the validation entity computer may receive the access data and may not receive the actual authentication code. In other embodiments, step 230 may be optional if the validation entity computer 80 simply verifies that the authentication code was received within a valid time period and verifies that the received authentication code originated from the correct mobile device 10.

In step S212, an authentication code is sent (e.g., over the air) from the authorizing computer system 40 to the first application 20A in the mobile device 10.

After the first application 20A in the mobile device 10 receives the authentication code, the first application 20A then passes the authentication code to the second application 20B in the mobile device 10 through an appropriate API (application programming interface) in step S214.

After receiving the authentication code by the second application 20B, the mobile device 10 then sends the authentication code to the digital wallet server computer 60 using any suitable electronic message format in step S216.

After the digital wallet server computer 60 receives the authentication code, the digital wallet server computer 60 then sends the authentication code to the verification entity computer 80 using any suitable electronic message format in step S218.

In steps S212, S214, S216 and S218, the previously described device specific information (e.g., device and/or wallet application identifier) and/or event specific information (e.g., random number) may be sent to the verification entity computer 80 along with the authentication code. In other embodiments, device specific information and/or event specific information may be developed with the authentication code to the verification entity computer 80. This data may be clear or encrypted, but may be used by the authentication entity computer 80 to confirm that the authentication code is from the correct mobile device 10.

After the authentication code is received by the authentication code computer 80, the authentication code is then verified by the authentication computer 80 in step S220. In some embodiments, the validation module 84C in the validation verification computer 80 may employ the most recently received authentication code and may decrypt (or cooperate with the encryption module 84E) any encrypted data. The verification module may then retrieve the previously received authentication code (stored in the database) previously received from the authorizing computer system and also decrypt any encrypted data. The decrypted data from the previously stored authentication code and the most recently received authentication code may then be compared to determine whether the currently received authentication code and the previously stored authentication code match (thereby verifying the received authentication code). In other embodiments, the access data may have been previously received by the experience verification computer 80 from the authorizing computer system 40. The access data may be retrieved from the database and compared with decryption information from the received authentication code. If there is a match, and if the authentication code is otherwise valid (e.g., within a predetermined time period), the received authentication code may be verified.

In addition, the previously described signature device and/or event specific data may also be verified by the verifier computer 80. The device and/or event specific data may be obtained from the digital wallet server 60 along with the authentication code. For example, in some embodiments, the device and/or event specific data may be signed by an encryption key in a secure element in the mobile device 10, as described above. The resulting digital signature may be verified by the verifier computer 80 using a corresponding cryptographic key (e.g., public key) to ensure that the correct mobile device 10 is provisioned with the account data.

As noted above, in some embodiments, the authentication code may contain (in encrypted form) access data to be provisioned to the mobile device 10. Decrypting the encrypted information component in the authentication code will supply the authentication entity computer 80 and/or the provisioning server computer 90 with all the information it needs to provision the second application 20B in the mobile device 10 with access data. Thus, the provisioning server computer 90 need not receive access data from the authorizing computer system 40. This reduces the number of data transfers required to supply the second application 20B with access data.

In step S220, if the authentication code received from the authorizing computer system 40 matches the authentication code received from the digital wallet server computer 60, the verification entity computer 80 then initiates the provisioning process. This can be done in a number of ways. In some cases, the verification entity computer 80 may send a message to the provisioning server computer 90 requesting that the second application of the mobile device be provisioned with the access data requested by the user of the mobile device 10. In another embodiment, the provisioning server computer 90 may be part of the authentication entity computer 80 and may initiate provisioning without sending any specific provisioning instruction message. If a provisioning instruction message is used, it may include details needed to provision the mobile device 10 with access data. Such details may include the access data itself, an address (e.g., a phone number) associated with the mobile device 10 to be provisioned, any data used by the mobile device 10 that allows the mobile device 10 to accept the access data, and so forth.

In step S222, the authentication entity computer 30 then sends a message to the provisioning server computer 90 to start the provisioning process. In step 224, the provisioning server computer 90 sends the access data to the second application 20B in the mobile device 10 for storage. In some embodiments, the provisioning server computer 90 may store one encryption key (e.g., an ephemeral public ECC key) and the mobile device 10 may store another corresponding encryption key. The provisioning server computer 90 may then encrypt the access data before sending it to the mobile device 10, and the mobile device 10 may decrypt the encrypted access data upon receipt. The mobile device 10 may thereafter be used to conduct a payment transaction using the second application 20B and the access data supplied thereto. In some cases, the access data may be stored in a secure area (e.g., a secure element) in the mobile device 10.

Once the access data is provisioned to the mobile device 10, the access data may be used to conduct an access transaction. Fig. 8 shows a system comprising a mobile device that is provisioned with access data and may allow a user to access a location such as a building. Fig. 9 illustrates a payment processing system that includes a mobile device that is provisioned with access data and allows a user to access an account to pay for a merchant's goods or services.

Fig. 8 shows a block diagram of a building access system. Fig. 8 shows the mobile device 110 being operated by the user 206. As described above, the mobile device 110 is provisioned with access data. The mobile device 110 may interact with the access device 120 and communicate access data to the access device 120. The access device 120 may verify the received access data locally or it may communicate with a remotely located authentication server computer (not shown). The remotely located authentication server computer may verify that the access data is authentic and may send a signal indicative thereof back to the access device 120. The access device 120 may then proceed to let the user 206 enter the building 130.

FIG. 9 illustrates a block diagram of a transaction processing system that may use a mobile device having access to data. Fig. 9 shows a user 206 who may operate a mobile device 210. The user 206 may use the mobile device 210 to pay for the merchant's goods or services. The merchant may operate the merchant computer 230 and/or the access device 220. The merchant may communicate with the issuer computer 260 via the acquirer computer 240 and the payment processing network 250.

The payment processing network 250 may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network may include VisaNet (TM). Payment processing networks such as Visanet^TMCredit card transactions, debit card transactions, and other types of commercial transactions can be processed. Visanet^TMIncluding in particular processing of authorisation requestsA VIP system (Visa integrated payment system) and a Base II system that performs clearing and settlement services. The payment processing network may use any suitable wired or wireless network, including the internet.

A typical payment transaction flow using the mobile device 210 at the access device 220 (e.g., POS location) may be described as follows. The user 206 presents his or her mobile device 210 to the access device 220 to pay for the item or service. The mobile device 210 and the access device 220 interact such that access data (e.g., PAN, payment token, verification value(s), expiration date, etc.) from the mobile device 210 is received by the access device 220 (e.g., via a contact or contactless interface). Merchant computer 230 may then receive this information from access device 220 via the external communication interface. Merchant computer 230 may then generate an authorization request message including the information received from access device 220 (i.e., the information corresponding to mobile device 210) and additional transaction information (e.g., transaction amount, merchant-specific information, etc.) and electronically transmit the information to acquirer computer 240. The acquirer computer 240 may then receive, process, and forward the authorization request message to the payment processing network 250 for authorization.

Generally, before a credit or debit card transaction occurs, the payment processing network 250 has an established agreement with each issuer regarding how the issuer's transaction will be authorized. In some cases, such as when the transaction amount is below a threshold, the payment processing network 250 may be configured to authorize the transaction based on information it has about the user's account without generating and sending an authorization request message to the issuer computer 260. In other cases, such as when the transaction amount is above a threshold, the payment processing network 250 may receive the authorization request message, determine the issuer associated with the mobile device 210, and forward the authorization request message for the transaction to the issuer computer 260 for verification and authorization. Once the transaction is authorized, the issuer computer 260 may generate an authorization response message (which may include an authorization code indicating that the transaction is approved or denied) and send the electronic message to the payment processing network 250 via its external communication interface. Payment processing network 250 may then forward the authorization response message to acquirer computer 240, which may then in turn send an electronic message including an authorization indication to merchant computer 230 and then to access device 220.

At the end of the day or at some other suitable time interval, the clearing and settlement flow between the merchant computer 230, acquirer computer 240, payment processing network 250, and issuer computer 260 may be performed on the transaction.

Authentication code generation

The authentication code may be formatted in any suitable manner. For example, the data used to generate the authentication code may be cryptographically protected by encryption. Many different types of encryption schemes may be used. Any suitable key scheme may be established between the parties that create and verify the authentication code.

The cryptographically protected code may be encoded for transmission as required. For example, in embodiments of the present invention, BASE-64, hexBinary, or other encoding schemes may be used to transmit values in text-based messages. The scheme used may be explicitly stated in the message used to transmit the authentication code or may be implicit due to previous arrangements between the involved parties.

Prior to encryption, the data may be formatted according to a predetermined scheme. This format may contain general information and application specific data suitable for all applications. In some embodiments, the data may be structured with the following data prior to encryption:

control information-for conveying information to recipients necessary to process the information (e.g., formatting, character encoding)

Omicron random number or character

Total length of omicron usage-specific data

Omicron use specific data

Fill (as required by the encryption scheme)

The usage-specific data may be formatted in a manner that makes the content of the data self-evident. When the code is time sensitive, the usage-specific data may include a time data element. The padding scheme (if used) will be identified from the control information.

A. Formatted authentication code

In some embodiments, the authentication code includes two main portions, each of which may contain multiple elements. The first portion may include plaintext information. The plaintext information includes information required to process the encrypted information. The second portion may include encryption information. The encryption information contains protected data supplied by an authorized entity (e.g., an issuer) to enable a verifying entity (e.g., a payment processor or an access authority) to verify the authenticity and validity of the authentication code.

The first portion and the second portion may be concatenated together to construct the authentication code. The authentication code may be received at a first application and then transmitted as a single data element to a second application on the mobile device (e.g., via an API of the digital wallet provider). In some embodiments, the constructed authentication code may be consistent with the following layout, where each component value is separated by a hyphen (-): type-version-key index-encryption information

The "type" may be a plaintext component that identifies the type of authentication code present. For example, the type of code may be a payment account provisioning code, a building access code, a payment account activation code, and the like. The "type" may be in any suitable form, including letters, numbers, symbols, and the like. For example, the mobile bank activation authentication code may be in the form of "MBAAC".

The "version" may be a plaintext component that specifies the format or version of the authentication code constructed by the issuer.

The "key index" may be a plaintext component that identifies a particular data encryption key used to encrypt the encrypted information component. The value may be coordinated between the authorizing entity and the verifying entity. The value may be represented as a positive integer or any other suitable symbol, character, or identifier. In other embodiments of the invention, a "key name" may be used instead of or in addition to a "key index" in the authentication code.

The "encryption information" may be a component containing a plurality of data elements formatted according to a specific syntax in ASCII text, encrypted, and then encoded by hexBinary before being contained in the authentication code data field. Each element contained in the encrypted information component may use a name/value pair syntax, where each name/value pair is separated by a semicolon. The name/value pairs may use the following syntax: name is value.

In some embodiments, the following data elements may be included within the encrypted information component to create an authentication code that may be used to supply account data to a second application on the mobile device:

the following may be the sample data before encryption:

pan＝1234567890123456；datetime＝20140424221300；

authcode＝846932

pan＝1234567890123456；datetime＝201404242214θθ；

authcode＝8AC93Z

the constructed data is then encrypted. Once encrypted, it may be converted to a hexBinary format for inclusion as an encrypted information component in the authentication code.

In some embodiments, the encrypted information component may include all of the access data such that there is necessary information to provision the mobile device 10 when decrypting the encrypted information. For example, it may include an expiration date in addition to the primary account number. It may also include a verification value, such as a CVV or CVV2 value. Further, to prevent replay or relay of the authentication code, as described above, additional device-specific information (e.g., a device ID or a wallet ID) or event-specific information (e.g., a random number) may be included in the encryption information.

B. Example authentication code

The following is an example of a constructed authentication code. Note that the illustrated encrypted information component is an example, but the length of the authentication code may be shorter than the examples shown below.

MBAAC-1-1-7AF291C91F3ED4EF92C1D45EFF127C1F9ABC12347E

C. Regional encryption key parameters

The data encryption key used to protect the encrypted information component may be a double length triple des (tdea) symmetric key. They may be used for the sole purpose of transient data encryption between parties and are usually distinct from PINs, MACs, or other specific encryption keys.

The key or keys used may be transferred between the authorizing entity and the verifying entity prior to use using conventional key transfer and protection schemes.

D. Cipher block formatting

The encrypted information component within the authentication code may be formatted using an encryption blocking scheme. The blocking scheme may help protect the authentication code from attack and may provide a consistent way for the receiving system to identify important data in one or more cipher blocks.

The following section describes the structural parameters and formatting parameters of the encrypted block before encryption. Each of these encrypted blocks may be specially formatted in a consistent structure for ease of processing and additional security. The first block may contain additional control information that is not present in the remaining blocks.

Control field (first block only) -the control field may include any data used to convey information to a recipient that is needed to process the information (e.g., formatting, character encoding)

Second control field (first block only)

Random numbers or characters (only the first block).

Two-digit data length field-comprising the number of data bits or characters to be encrypted (first block only). Excluding controls, reservations, lengths, padding and random numbers or characters

Data to be encrypted-Normal 7-bit ASCII numbers (second to last blocks)

Plain text characters containing data to be protected in encrypted information in ASCII character format-it may use one or more 8 byte (64 bit) encryption blocks to accommodate the length of data to be protected as needed

The remaining unused locations may include filler characters as needed

An exemplary cipher block formatting process may be described below.

First block

Bit	1-8	9-16	17-24	25-32	33-40	41-48	49-56	57-64
									Data of	C1	C2	R	R	R	R	L1	L2

Second to last block

Bit	1-8	9-16	17-24	25-32	33-40	41-48	49-56	57-64
									Data of	D	D/F	D/F	D/F	D/F	D/F	D/F	D/F

In the above example, C1 may be control field 1. This may be a binary value, such as 00100000 (empty in ASCII text format). C2 may be control field 2. This may also be a binary value, such as 00100000 (empty in ASCII text format). R may be a randomized character. It may contain random 7-bit ASCII characters. L1 and L2 may indicate the length of the data. L1 and L2 may be implemented by two 7-bit ASCII numbers containing the length (number of characters) of the data present in the encrypted block. For example, L1 ═ 00110010(ASCII '2') and L2 ═ 00110110(ASCII '6') indicate that there are twenty-six characters. D may be name/value pair data (e.g., 7-bit ASCII characters). The D/F may be name/value pair data or a padding character. The labels of these fields are determined by the length field. F may be a pad character. F may be a binary value such as 00100001 ('|' in ASCII text format).

The encrypted block may be encrypted using a Triple DES Encryption Algorithm (TDEA) with Cipher Block Chaining (CBC) to produce encrypted data for inclusion in the encrypted information component of the authentication code. In some embodiments, the encrypted information component may be converted to a hexBinary format before being included in the authentication code.

An example of an encryption block (plaintext before encryption) can be described as follows. The following data may be formatted so that it is contained in the encrypted information component:

pan＝1234567890123456；datetime＝20140424221300；

authcode＝846932

prior to encoding, nine 64-bit encrypted blocks may be constructed in plain text format (plain 7-bit ASCII encoded characters).

FIG. 10 is a high-level block diagram of a computer system that may be used to implement any of the entities or components described above. The subsystems shown in fig. 10 are interconnected via a system bus 775. Additional subsystems include a printer 774, keyboard 778, system memory 772, and monitor 776, which is coupled to display adapter 782. Peripherals and input/output (I/O) devices, which are coupled to I/O controller 771. For example, external interface 722 may be used to connect the computer device to a wide area network such as the internet, a mouse input device, or a scanner via input/output port 777. The interconnection via the system bus 775 allows the central processor 773 to communicate with each subsystem and to control the execution of instructions from the system memory 772 or the one or more storage devices 779 and the exchange of information between subsystems. The system memory 772 and/or the one or more storage devices may be implemented by computer-readable media.

Embodiments of the present invention have many advantages. For example, as described above, in embodiments of the invention, access data may be provisioned to an untrusted application by first making a request for access data using a trusted first application associated with an authorized entity. The user and authorized entity can be confident that the request for access to the data is authentic, and not fraudulent. Furthermore, the use of the authentication code described above may allow a party other than the authorizing entity to supply access data. Finally, since the authentication code has an encrypted portion (i.e., a time data element) and an unencrypted portion containing information about how to process the encrypted portion, the authentication code can be used by different parties to verify that the provisioning request is authentic and valid.

Embodiments of the present invention have a number of additional advantages. As described above, in the provisioning system according to the embodiment of the present invention, the authorization system computer, the verification entity computer, and the digital wallet server computer may be operated by different entities. Although it is relatively straightforward for a computer system to authenticate a user before provisioning access data to a mobile device, this is not straightforward when multiple different entities are involved in the provisioning process. It is also difficult to ensure that the user's sensitive access data and other confidential information is adequately protected while the provisioning process takes place. Embodiments of the present invention may protect access data as it passes between various entities in the system while also minimizing the number of communications required to provision the access data for the mobile device 10. The authentication code used to verify that the mobile device 10 can receive the access data may contain the access data itself, thereby eliminating the need for the authorization computer system to separately transmit the access data to the verification entity computer and/or the provisioning server computer.

It will be appreciated that the invention as described above may be implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and/or methods to implement the present invention using hardware and a combination of hardware and software.

Any of the software components or functions described in this application may be implemented as software code executed by a processor using any suitable computer language, such as, for example, Java, C + + or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium, such as a Random Access Memory (RAM), a Read Only Memory (ROM), a magnetic or floppy disk, such as a hard drive, or an optical medium, such as a CD-ROM. Any such computer-readable medium may reside on or within a single computing device, and may exist on or within different computing devices within a system or network.

Although a few exemplary embodiments have been described in detail and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that this invention not be limited to the specific arrangements and instrumentalities shown and described, since various other modifications may occur to those ordinarily skilled in the art.

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

Claims

1. A method for provisioning access data to a mobile device, comprising:

receiving, by a mobile device, user authentication data at a first application on the mobile device;

transmitting, by the mobile device, the user authentication data to an authorizing computer system;

receiving, by the mobile device via the first application program, an authentication code from the authorizing computer system, wherein the authentication code is derived from access data, the authentication code comprising a first portion comprising encrypted information and a second portion comprising unencrypted information, the encrypted information comprising the access data, the unencrypted information capable of being used to decrypt the encrypted information to obtain the access data;

providing, by the mobile device, the authentication code from the first application to a second application on the mobile device;

providing, by the second application on the mobile device, the authentication code to a verification entity computer, wherein the verification entity computer verifies the authentication code and decrypts the encrypted information to obtain the access data from the authentication code; and

receiving, by the mobile device and from a provisioning server computer in communication with the experience verification computer, the access data.

2. The method of claim 1, wherein the mobile device is a mobile phone.

3. The method of claim 1, wherein the experience-verifying entity computer is a transaction processing network.

4. The method of claim 1, wherein the access data comprises an expiration date.

5. The method of claim 1, wherein the authentication code comprises a first portion comprising encrypted information and a second portion comprising unencrypted information, the encrypted information comprising an encrypted time data element.

6. The method of claim 1, wherein the authentication code includes a first portion containing encrypted information including the consumer's primary account number, the time and date when the authentication code was generated, and an authorization code generated in encrypted form by the authorizing computer system.

7. The method of claim 5, wherein the encryption information further comprises a random number in encrypted form.

8. The method of claim 1, wherein the authentication code comprises a first portion comprising encrypted information and a second portion comprising unencrypted information, the encrypted information including an encrypted time data element, the unencrypted information including a key index that can identify a key used to decrypt the encrypted information.

9. The method of claim 1, wherein the authentication code comprises a first portion containing encrypted information including the consumer's primary account number, the time and date when the authentication code was generated, and an authorization code generated in encrypted form by the authorizing computer system, and a second portion comprising unencrypted information, wherein the verifying entity computer verifies the authentication code by: decrypt the encrypted information using the unencrypted information, obtain the authorization code from the authentication code, and compare the obtained authorization code to the authorization code obtained from the authorizing computer system.

10. The method of claim 9, wherein the first application is a mobile banking application and the second application is a digital wallet application.

11. A mobile device, comprising:

a processor;

an antenna coupled to the processor; and

a non-transitory computer-readable medium coupled to the processor, wherein the computer-readable medium comprises code executable by the processor to implement the method of any of the preceding claims.

12. The mobile device of claim 11, further comprising:

a display coupled to the processor.

13. The mobile device of claim 11, further comprising a contactless element coupled to the processor, the contactless element configured to provide the access data to an access device.

14. A method for provisioning access data to a mobile device, comprising:

receiving, by a validation entity computer, an authentication code, wherein the authentication code includes an encrypted information component and an unencrypted information component, the encrypted information component including the access data, the unencrypted information component including information for decrypting the encrypted information component to obtain the access data;

verifying the authentication code by the verification entity computer;

decrypting, by the verifying entity computer, the encrypted information component of the authentication code to obtain data to be accessed; and

the provisioning of the access data to the mobile device is initiated by the experience recognition computer.

15. The method of claim 14, wherein initiating provisioning of the access data comprises sending a message to a provisioning server computer that sends the access data to an application on the mobile device.

16. The method of claim 14, wherein the authentication code comprises a first portion containing encrypted information including the consumer's primary account number, the time and date when the authentication code was generated, and an authorization code generated in encrypted form by an authorizing computer system, wherein the verifying authentication computer verifies the authentication code by: decrypt the encrypted information using unencrypted information in the authentication code, obtain the authorization code from the authentication code, and compare the obtained authorization code to an authorization code obtained from the authorizing computer system.

17. An apparatus for provisioning access data to a mobile device, comprising:

a processor; and

a non-transitory computer-readable medium coupled to the processor, the computer-readable medium comprising code executable by the processor to implement the method of any of claims 14-16.