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

Abstract

The present disclosure relates to methods, devices, and apparatuses for provisioning access data to a mobile device. Included is 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 can be entered into the first application and an authentication code can be requested from a remote server. The authentication code can include access data to be provisioned in encrypted form. After the first application in the mobile device receives the authentication code, the first application can pass the authentication code to the second application that initiates the access data provisioning process.

Description

[0001] This application is a divisional application of Chinese patent application No. 201680026340.9, with an international filing date of April 6, 2016, entitled "Method, apparatus and device for supplying access data to a mobile device".

[0002] Cross-references to related applications

[0003] This application claims the benefits of U.S. Provisional Application No. 62 / 158,503, filed May 7, 2015, and U.S. Provisional Application No. 14 / 707,788, filed May 8, 2015. The entire contents of all these applications are incorporated herein by reference for all purposes. Background Technology

[0004] Mobile phones can utilize access data to gain access to resources or locations. For example, a mobile phone may include data passed to an access device to allow the mobile phone user to access rooms in a building. In another example, a mobile phone may have access data, such as account data, that could allow the mobile phone user to access an account to obtain goods.

[0005] In many cases, resource providers can offer access data to mobile phones. For example, a building operator system can provide data to a mobile phone allowing its user to access the building. In another example, a bank can provide access data to a mobile phone, allowing its user to access their bank account. In this specific case, the resource provider can verify that the mobile phone user is indeed a legitimate user. Therefore, the transmission of access data to the mobile phone is relatively secure.

[0006] In some cases, mobile devices may contain applications that can perform multiple functions and / or perform functions for more than one resource provider. In one example, a single application on a mobile phone that performs multiple functions or provides services for many resource providers may not be directly associated with the resource providers associated with those functions or services. Trust issues may arise in this case because the resource provider may not have control over the individual application. For example, if the access data provided by the service provider is highly sensitive, the service provider may not have complete control over any security features of the individual mobile application. Furthermore, if a user requests access data from a resource provider to their mobile phone, the user may not trust the data in the individual mobile application to be secure.

[0007] Furthermore, in today's world, many different entities need to collaborate to provide access data to mobile devices. For example, providing access data to mobile phones for point-of-sale transactions may require collaboration between handset manufacturers, digital wallet providers, banks, mobile network operators, and service providers that send the access data to the mobile devices. Because many parties are involved in the access data provision process, sensitive authentication and access data may be transferred between various entities and thus potentially exposed to man-in-the-middle attacks or hacking. It is also difficult to ensure that users' sensitive access data and other confidential information are adequately protected during the provision process.

[0008] Embodiments of the present invention relate to methods and systems for improving data security. Embodiments of the present invention individually and collectively address these and other problems. Summary of the Invention

[0009] Embodiments of the present invention relate to methods and systems for improving security when supplying access data to mobile devices.

[0010] One embodiment of the present invention relates to a method comprising receiving an authentication code by a verification entity computer. The method further comprises decrypting an encrypted portion of the authentication code by the verification entity computer to obtain access data. The method also includes initiating the provisioning of the access data to a mobile device by the verification entity computer.

[0011] Another embodiment of the present invention relates to a verification entity computer configured to perform the above-described methods.

[0012] Another embodiment of the invention relates to a method. The method includes receiving user authentication data by a mobile device at a first application on the mobile device, and then sending the user authentication data to an authorized computer system. The method also includes receiving an authentication code from the authorized computer system by the mobile device via the first application. The authentication code can 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 a verification entity computer. The verification entity computer verifies the authentication code and obtains the access data from the authentication code. It can then instruct a provisioning server computer to provide the access data to the second application on the mobile device.

[0013] Another embodiment of the present invention relates to a mobile device configured to perform the above-described method.

[0014] These and other embodiments are described in more detail below with reference to the accompanying drawings and detailed description. Attached Figure Description

[0015] Figure 1A block diagram of a system according to an embodiment of the present invention is shown.

[0016] Figure 2 A block diagram of a mobile device according to an embodiment of the present invention is shown.

[0017] Figure 3 A block diagram of an authorized computer according to an embodiment of the present invention is shown.

[0018] Figure 4 A block diagram of a verification entity computer according to an embodiment of the present invention is shown.

[0019] Figure 5 A flowchart illustrating a method for providing an authentication code to a second application on a mobile device is shown.

[0020] Figure 6 A flowchart illustrating a method for supplying access devices to mobile devices is shown.

[0021] Figure 7 A block diagram illustrating a system and process sequence of another embodiment of the present invention is shown.

[0022] Figure 8 A block diagram of a building access system is shown.

[0023] Figure 9 A block diagram is shown of a transaction processing system that can use mobile devices with access to data.

[0024] Figure 10 A block diagram of a computer is shown. Detailed Implementation

[0025] Embodiments of the present invention can provide a number of different mechanisms to enhance security when accessing resources via untrusted applications on mobile devices. In some embodiments, this can be achieved by requesting an authentication code via a trusted application on the mobile device. In some embodiments, the activation code may include encrypted time data elements, making the activation code time-limited. The verifying entity computer can use the time data elements to determine whether the activation code is still valid.

[0026] Some embodiments of the present invention may include a mobile device receiving user authentication data into a first application on the mobile device. Once the first application on the mobile device receives the user authentication data, it sends it to an authorized computer system. The authorized computer system then verifies the authentication data. After verification, the authorized computer system may generate an authentication code and send it to the first application on the mobile device. After receiving the authentication code, the first application on the mobile device can provide the authentication code to a second application on the mobile device via a second application API (Application Programming Interface). The second application on the mobile device can then provide the authentication code to a verification entity computer. After verification, the verification entity computer can send instructions to a provisioning server to provide access data to the second application on the mobile device.

[0027] In some implementations, the authentication code may be a mobile banking authentication code, and the primary application may be a mobile banking application. Once a consumer has been authenticated or authorized by the issuer for the purpose of personalizing the consumer's account information to the mobile device, the issuer can generate the authentication code. The authentication code can be transmitted to the party that will supply account data to the mobile device. This party can authenticate the code before performing the supply process.

[0028] The advanced processing flow according to an embodiment of the present invention can 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 their mobile device. Second, the issuer securely creates an authentication code using its server computer. Third, the issuer transmits the authentication code to the issuer's mobile banking application on the consumer's mobile device. Fourth, the mobile banking application transmits the authentication code to the digital wallet provider application on the mobile device via an API (Application Programming Interface). Then, the digital wallet provider application on the mobile device provides the authentication code to a remotely located digital wallet server computer. Fifth, the digital wallet server computer then transmits the authentication code to a verification entity computer, which can initiate the provisioning of payment account data or activation of the payment account within the digital wallet provider application on the mobile device. Once the digital wallet provider application on the mobile device has been provided with payment account data, the mobile device can be allowed or authorized to conduct payment transactions.

[0029] Before discussing detailed embodiments of the invention, certain descriptions of certain terms may be useful.

[0030] "Mobile device" can include any electronic device that a user can carry and operate, and that also provides the ability to communicate remotely with a network. Examples of remote communication capabilities include using mobile phone (wireless) networks, wireless data networks (such as 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that can 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, laptops, personal music players, handheld dedicated readers, wearable devices (e.g., watches), vehicles (e.g., automobiles), and so on. Mobile devices can include any suitable hardware and software for performing such functions, and can also include multiple devices or components (e.g., when a device remotely accesses a network by being attached to another device). -Right now Using other devices as relays – two devices used together can be considered a single mobile device.

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

[0032] The "verifying entity computer" can be any suitable computer capable of verifying data. In embodiments of the invention, the verifiable data may include authentication codes. This data can be handled by a verifying entity such as a payment organization, payment processing network, transit authority, building system, ticketing system, etc.

[0033] "Supply server computer" can include any suitable computer that can supply access data to the device.

[0034] "Access data" can include any suitable data that can be used to access a resource or create data that allows access to a resource. In some embodiments, access data can be account information of a payment account. Account information can include a PAN, payment token, expiration date, and verification value (e.g., CVV, CVV2, dCVV, dCVV2), etc. In other embodiments, access data can be data that can be used to activate account data. For example, in some cases, account information can be stored on a mobile device but may not be activated until the mobile device receives specific information. In some embodiments, this specific information can be characterized as access information. In other embodiments, access data can include data that can be used to access a location. Such information can be event ticket information, data for accessing a building, transit ticket information, etc.

[0035] An "access data reference identifier" may include an identifier that identifies accessed data rather than the actual accessed data itself. The access data reference identifier can be used to identify specific accessed data. For example, a primary account such as 4000 8198 8298 1132 can be represented by an account reference identifier such as XP28278978. In embodiments of the invention, the account reference identifier cannot be used for transactions, but can be used as a security mechanism to allow different entities to take actions regarding an account without using the actual account.

[0036] An "application" can be a computer program used for a specific purpose.

[0037] A "time data element" can include data related to any suitable time. For example, a time data element can be time, date, month, year, or any suitable combination of the above. A time data element can also be derived from time, date, month, year, or any suitable combination of the above. Encrypted time data elements can be data elements that can include encrypted time, date, month, year, and / or suitable combinations of the above.

[0038] An "access device" can be any suitable device used to obtain access to a resource. Access devices can typically be located anywhere suitable, such as at a merchant's location. Access devices can take any suitable form. Some examples of access devices include POS devices, cellular phones, PDAs, personal computers (PCs), tablets, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), newsstands, security systems, access systems, websites, etc. Access devices can use any suitable contact or contactless operating mode to send or receive data from payment devices and / or user mobile devices, or be associated with payment devices and / or user mobile devices.

[0039] An "authorization request message" can be an electronic message sent to a payment processing network and / or the issuer of a payment card to request authorization for a transaction. According to some implementations, an authorization request message may conform to ISO 8583, a standard for systems that exchange 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 can be associated with the payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information," such as, for example, a service code, CVV (card verification value), dCVV (dynamic card verification value), expiration date, etc. The authorization request message may also include "transaction information," such as any information associated with the current transaction, such as the transaction amount, merchant identifier, merchant location, etc., and information that can be used to determine whether to identify and / or authorize the transaction.

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

[0041] A "server computer" is typically a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers as a single unit. In one example, a server computer could be a database server coupled to a web server.

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

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

[0044] I. System

[0045] Figure 1 A block diagram of a system according to an embodiment of the present invention is shown. Figure 1 A mobile device 10 is shown that communicates with an authorization computer system 40, a supply 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. An authentication entity computer 80 communicates with the supply server computer 90 and the digital wallet server computer 60. The authorization computer system 40 communicates with the authentication entity computer 80.

[0046] The provisioning server computer 90 can be configured to provide access data to the mobile device 10. The provisioning server computer may include a processor and a computer-readable medium including code that causes the processor to execute any suitable methods associated with providing 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 provided with access data. The provisioning server computer may also maintain a database of the access data to be provided. The access data to be provided may have already been obtained by the issuer of the operating authorization computer system 40 and / or the payment processor of the operating verification entity computer 80.

[0047] The digital wallet server computer 60 can be configured to maintain digital wallets associated with the user of the mobile device 10 and other users. The "digital wallet" can store user profile information, payment information (such as PAN or master account, payment token (i.e., PAN alternatives), verification values ​​such as CVV), bank account information, and / or similar information, and can be used for various transactions, such as, but not limited to, e-commerce for retail purchases, social networks, money transfers / personal payments, mobile commerce, proximity payments, gaming and / or similar transactions, digital goods purchases, utility payments, purchasing games or game credits from gaming websites, transferring funds between users, and so on.

[0048] Figure 1Each entity in the network can communicate through any suitable communication channel or communication network. A suitable communication network can be any one and / or a combination of the following: direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); an Operations Mission as an Internet node (OMNI); a secure custom connection; a wide area network (WAN); a wireless network (e.g., using protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.); and / or the like.

[0049] Figure 2 A block diagram of a mobile device 10 according to an embodiment of the present invention is shown. In some embodiments, the mobile device 10 may be a payment device that can be used to make payments or a device that allows a user to gain access to their location. An exemplary mobile device 10 may include a computer-readable medium 10B that may be present within the body 10H of the mobile device 10. The computer-readable medium 10B may be in the form of a memory for storing data. In some cases, the memory 10B may also store information such as access data. Typically, this information can be transmitted from the mobile device 10 to another device using any suitable method, including the use of an antenna 10A or a contactless element 10G. The body 10H may be in the form of a plastic substrate, a housing, or other structure.

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

[0051] In some implementations, 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), which has associated wireless transmission ( For example (Data transmission) components, such as antennas. Non-contact 10G components can be coupled to ( For exampleEmbedded within it, the mobile device 10 allows data or control commands transmitted via a cellular network to be applied to the contactless element 10G via a contactless element interface (not shown). The contactless element 10G is capable of transmitting and receiving data using short-range wireless communication capabilities. As mentioned above, the mobile device 10 may include both an interrogator device (… For example (receiving data) is also the device being queried ( For example The mobile device 10 is a component that transmits data. Therefore, the mobile device 10 can transmit data via a cellular network (or any other suitable wireless network). For example They communicate and transmit data or control commands via the Internet or other data networks and short-range communications.

[0052] Mobile device 10 may also include processor 10C for processing the functions of mobile device 10. For example The mobile device 10 may include a microprocessor and a display 10D that allows the consumer to view phone numbers and other information and messages. The mobile device 10 may also include an input element 10E to allow the user to input information into the device, a speaker 10F to allow the user to hear voice communications, music, etc., and a microphone 10I to allow the user to transmit their voice through the mobile device 10. The mobile device 10 may also include components for wireless data transmission (…). For example Antenna 10A (for data transmission).

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

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

[0055] The second application 20B may be associated with an entity such as the digital wallet server computer 60. Because the second application 20B is not developed by the authorized entity, it is generally less trusted by the authorized entity operating the authorized computer. Examples of the second application may include digital wallet applications, merchant applications, fitness applications, and any other suitable applications that may exist on the mobile device 10.

[0056] Figure 3 A block diagram of an authorized computer system 40 according to an embodiment of the present invention is shown. Figure 3 The diagram shows a server computer 40A and an account data database 40B coupled to the server computer 40A.

[0057] Account data database 40B can maintain accounts for various users, which are attached to an authorizing entity associated with the authorizing computer system. For example, the authorizing entity could be an issuing bank, and database 40B could store account information for the issuing bank's customers' credit card and debit card accounts.

[0058] Database 40B (and any other database described herein) can be a conventional, fault-tolerant, relational, scalable, and secure database, such as Oracle™ or Sybase™. Database 1204 can be implemented using various standard data structures such as arrays, hashes, (linked) lists, structured text files (e.g., XML), tables, and / or similar structures. Such data structures can be stored in memory and / or (structured) files.

[0059] Server computer 40A may include processor 41, which may be coupled to system memory 42 and external communication interface 43. Computer-readable medium 44 may also be operatively coupled to processor 41.

[0060] The computer-readable medium 44 may include multiple 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.

[0061] The communication module 44A may include code that enables the processor 41 to generate messages, forward messages, reformat messages, and / or otherwise communicate with other entities.

[0062] 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, and AES, etc. The encryption module may also store encryption keys that can be used with such encryption algorithms. Encryption module 44B may utilize symmetric or asymmetric encryption techniques to encrypt and / or verify data.

[0063] The database update module 44C can work with the processor 41 to update account information in the account data database 40B.

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

[0065] The authorization module 44E may include code that enables the processor 41 to evaluate the authorization request message for a transaction and determine whether the transaction should be authorized. Such transactions may be authorized or denied based on several factors, including the potential level of fraud and / or the amount of funds or credit limit associated with the account used to conduct the transaction.

[0066] The verification module 44F may include code that causes the processor 41 to verify verification credentials received from the user's mobile device. The verification module 44F may also include code that causes the processor 41 to retrieve data from the database 40B and compare that data with the received data.

[0067] Computer-readable medium 44 may include code executable by a processor to implement a method comprising: receiving authentication data from an authorized computer and a mobile device; verifying the authentication data by the authorized computer; 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 includes a first portion and a second portion, the first portion including encrypted information including encrypted time data elements, and the second portion including unencrypted information capable of being processed; and sending the authentication code to the mobile device, wherein the authentication code is provided to a verification entity computer that initiates the supply of access data to the mobile device.

[0068] Figure 4 A block diagram of a verification entity computer 80 according to an embodiment of the present invention is shown. In some embodiments of the invention, the verification entity computer 80 may also be located in a payment processing network. The verification entity computer 80 may include a processor 81, which may be coupled to system memory 82 and an external communication interface 83. A computer-readable medium 84 may also be operatively coupled to the processor 81.

[0069] In some implementations, the verification computer 80 may be part of a payment processing network that switches transaction requests and responds between the issuer and the acquirer. The payment processing network may be a transaction processing network. A transaction processing network can process payment transactions or other types of access transactions.

[0070] The computer-readable medium 84 may include multiple software modules, including a communication module 84A, a settlement module 84B, a code verification module 84C, an authorization module 84D, and an encryption module 84E.

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

[0072] The settlement module 84B may include code that enables the processor 81 to settle transactions between various entities, including issuers and acquirers.

[0073] The code verification module 84C may include code that causes the processor 81 to analyze a received authentication code to determine whether the received authentication code is valid. In some embodiments, the verification module 84C may obtain a recently received authentication code and may decrypt (or cooperate with the encryption module 84E) any encrypted data. The verification module may then retrieve a previously received authentication code previously received from the authorized computer system 40, and also decrypt any encrypted data. Alternatively, the data received from the authorized computer system 40 may be the access data itself (without receiving an authentication code). The decrypted data from the received authentication code may be evaluated and compared with previously received access data or with decrypted information from a previously received authentication code to determine if a match exists (thus 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 access data, and initiate the provisioning of access data to the mobile device.

[0074] The authorization module 84D may include code that enables the processor 81 to evaluate the 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 the authorization request and response messages as they pass between parties, such as the issuer and the acquirer.

[0075] 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, and AES, etc. The encryption module may also store encryption keys that can be used with such encryption algorithms. Other keys for any corresponding key pairs may be stored in encryption module 44B in the authorized computer system 40. Encryption module 84E may utilize symmetric or asymmetric encryption techniques to encrypt and / or verify data.

[0076] II. Methods

[0077] Figure 5 A flowchart illustrating a method for providing an authentication code to a second application on a mobile device is shown. Figure 6 A flowchart illustrating a method for supplying access data to a mobile device is shown. See also: Figure 1 To describe the system diagram Figures 5-6 The method is illustrated below. While the method specifically described below may relate to payment processing, embodiments of the present invention can be applied to other areas where payments are not required.

[0078] 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 associated with a digital wallet server computer 60. The access data may be payment account data such as credit card account data, or activation data that can be used to activate payment account data already residing on the mobile device.

[0079] In embodiments of the invention, a user may initiate the loading process by launching a first application 20A on the mobile device 10 or otherwise interacting with it. The first application 20A may be a publisher application (e.g., a mobile banking application) associated with an authorized computer system 40. The authorized computer system may be the publisher's computer system. In other embodiments, a second application 20B may be launched first, which may invoke or trigger the launch 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 a mobile device identifier and / or a second application identifier to the first application 20A. Such identifiers may be used by subsequent downstream entities (e.g., the authorized computer system 40) to help identify the mobile device to be supplied (if device information has not yet resided with those downstream entities).

[0080] After the first application 20A is launched, it may present the user with the option to load an account (e.g., a credit card number) into the second application 20B. In doing so, the first application may also request the user's authentication data, and optionally any account identifier associated with the account to be loaded into the second application 20B. For example, the first application 20A may request a previously identified PIN (Personal Identification Number) or password from the user of the mobile device 10, 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 can be done automatically without any user input or action.

[0081] In step S102, authentication data is sent from mobile device 10 and received at authorized computer system 40. The authentication data can be sent from mobile device 10 to authorized computer system 40 using any suitable electronic message format, including email, Short Message Service (SMS) messages, Multimedia Messaging Service (MMS) messages, Hypertext Transfer Protocol (HTTP) request messages, Transmission Control Protocol (TCP) packets, Web form submissions, etc. The message can be directed to any suitable location, such as an email address, telephone number, Internet Protocol (IP) address, or Uniform Resource Locator (URL). (See reference) Figure 1 Other communications described may be conducted in the same or different ways.

[0082] In step S104, the authorization computer system 40 verifies the authentication data. This can be done by retrieving previously stored authentication data for the user and then comparing the retrieved authentication data with the received authentication data. For example, the authorization computer system 40 can store a password, receive a corresponding password from the mobile device 10, and determine whether the stored password matches the received password. If the received authentication data does not match the previously stored authentication data, the authorization computer system 40 can generate a message and send it to the mobile device 10 to indicate that the entered authentication data is incorrect.

[0083] In step S106, if the received authentication data matches the previously stored authentication data, the authorized computer system 40 can generate an authentication code.

[0084] Authentication codes can be generated in any suitable manner. An encryption process can 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 can be used to decrypt the encrypted portion. Furthermore, the encrypted portion may include the consumer's Master Account Identifier (PAN), the date and time when the authentication code is generated (an example of a time data element) or when the user is verified by an authorized entity, and a specific authorization code generated by the authorized entity. By encrypting the date and time when the authentication code is generated or when the user is verified by an authorized entity, the verification entity computer verifying the authentication code can determine whether it is still valid. A specific method for generating an authentication code according to embodiments of the present invention is further described in detail below. Furthermore, by creating an authentication code with both encrypted and unencrypted portions, the authentication code may include information about how to recover any secrets present in the encrypted portion. Multiple separate data transmissions are not required to provide information about the decryption of the encrypted information.

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

[0086] In step S110, the authentication code is sent from the authorized computer system 40 to the first application 20A in the mobile device 10.

[0087] In step S112, 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 the appropriate API (Application Programming Interface).

[0088] In step S114, 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.

[0089] In step S116, 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.

[0090] In step S118, after the verification entity computer 80 receives the authentication code, it then verifies the authentication code. In some embodiments, the verification module 84C in the verification entity computer 80 may take 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 previously received authentication codes (stored in a database) previously received from the authorization computer system 40 and also decrypt any encrypted data. The decrypted data from the previously stored authentication codes and the most recently received authentication codes may then be compared to determine whether the currently received authentication code matches the previously stored authentication code (thus verifying the received authentication code). In other embodiments, access data may have been previously received by the verification entity computer 80 from the authorization computer system 40. This access data may be retrieved from the database and compared with the decrypted information from the received authentication code. If a match exists, and if the authentication code is also valid (e.g., within a predetermined time period), the received authentication code can be verified.

[0091] The authenticating entity computer 80 and the authorizing computer system 40 can share symmetric encryption keys that allow them to encrypt and decrypt authentication codes or portions thereof. In other embodiments, the authorizing computer system and the authenticating entity computer can respectively use a public key to encrypt a portion of the authentication code and a private key to decrypt that portion. 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 can be sent to the mobile device 10 indicating that the supply request has failed.

[0092] In step S120, if the received authentication code is valid, the verification entity computer 80 then initiates the provisioning process. This can be done in several ways. In some cases, the verification entity computer 80 may send a message to the provisioning server computer 90 to request the provisioning of access data requested by the user of the mobile device 10 to a second application on the mobile device. In another embodiment, the provisioning server computer 90 may be part of the verification 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 required to provide access data to the mobile device 10. Such details may include the access data itself (if the access data is not already stored at the provisioning server computer 90), the address associated with the mobile device 10 to be provided (e.g., a phone number), any data used by the mobile device 10 that allows the mobile device 10 to receive access data, etc. The verification entity computer 80 and / or the provisioning server computer 90 may have received the access data from the authorization computer system 40 at some point in the past via different communications. In some embodiments, as described below, the access data may be derived from the authentication code.

[0093] In step S122, the supply server computer 90 sends the access data to the second application 20B in the mobile device 10 for storage. In some embodiments, the supply server computer 90 may store an encryption key (e.g., a short-lived public ECC key), and the mobile device 10 may store another corresponding encryption key. The supply 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, it can then 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) within the mobile device 10.

[0094] The process described above can be used to supply static or dynamic access data to mobile devices. If the access data is dynamic, it can be supplied to the mobile device for each transaction or a predetermined number of transactions (e.g., every 5-10 transactions). This helps to reduce the risk of fraud caused by man-in-the-middle attacks.

[0095] Figure 7 A system block diagram is shown, illustrating a method according to another embodiment of the invention.

[0096] Prior to step S202, the user may wish to feed access data to the second application 20B. In some embodiments, the second application 20B may be a digital wallet application associated with a digital wallet server computer 60. The access data may be payment account data such as credit card account data.

[0097] A user can initiate the supply process by launching a first application 20A on mobile device 10 or otherwise interacting with it. In some implementations, this can be done without any initial interaction with a second application 20B. The first application 20A may be an issuer application (e.g., a mobile banking application) associated with an authorizing computer system 40. The authorizing computer system may be the issuer's computer system. The second application 20B may be a digital wallet application associated with a digital wallet server computer 60.

[0098] After the first application 20A is launched, it may present the user with the option to load an account (e.g., a credit card number) into the second application 20B. In doing so, the first application 20A may also request the user's authentication data, and optionally any account identifier associated with the account to be loaded into the second application 20B. For example, the first application 20A may request a previously identified PIN (Personal Identification Number) or password and username from the user of the mobile device 10. In some cases, the PIN or password and username may simply be user credentials required to access the authorized 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.

[0099] In step S202, authentication data is sent from mobile device 10 and received at authorized computer system 40. The authentication data can be sent from mobile device 10 to authorized computer system 40 using any suitable electronic message format (as referenced above). Figure 1 (As stated above). Reference Figure 7 Other communications described may be conducted in the same or different ways.

[0100] In step S204, the authorization computer system 40 verifies the authentication data. This can be done by retrieving previously stored authentication data for the user and then comparing the retrieved authentication data with the received authentication data. For example, the authorization computer system 40 can store a password, receive a corresponding password from the mobile device 10, and determine whether the stored password matches the received password. If the received authentication data does not match the previously stored authentication data, the authorization computer system 40 can generate a message and send it to the mobile device 10 to indicate that the entered authentication data is incorrect.

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

[0102] In step S207, the first application 20A queries the second application 20B (and optionally the digital wallet server computer 60) to determine whether any account data held by the authorized computer system 40 has been supplied to the second application 20B on the mobile device 10. The first application 20A can do this by sending (S208) one or more access data reference identifiers, such as account reference identifiers for the user of the access data, to the second application (and optionally, the digital wallet server computer 60). The account reference identifiers may be associated with accounts held by the user, which have issuers associated with the authorized 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 supplied 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 any account reference identifiers associated with the account data that have been supplied to the second application 20B, which can then forward them to the authorized computer system 40. To enhance security, the second application 20B and the digital wallet server computer 60 may communicate without using actual account data (e.g., the actual master account), but instead may communicate using a payment account reference identifier.

[0103] In some implementations, 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 previously supplied account data to the first 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 final generated authentication code cannot be replayed by another user device. This can be done during the return of one or more account reference identifiers or at different times. For example, the second application 20B (or the digital wallet server computer 60) may have device-specific information, such as an identifier for the mobile device 10 or an identifier for the second application 20B (e.g., a wallet identifier), and may send this information (in plaintext, hashed, or encrypted form) to the first application 20A and then to the authorizing computer system 40. The identifier for the mobile device 10 or the second application 20B can be in any suitable form (e.g., any suitable length and / or number of characters). The type of event-specific information that can be sent from the second application 20B or the digital wallet server computer 60 to the first application 20A and then to the authorized computer 40 may include timestamps and random numbers. Such information can be sent from the second application 20B or the digital wallet server computer 60 to the first application 20A and the authorized computer system 40 in encrypted or plaintext form.

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

[0105] For example, the second application 20B can retrieve a cryptographic key (e.g., a private key) from the secure element in the mobile device 10, and can then use that key to sign event-specific data or device-specific data. This can be used by the verification entity computer 80 at a later time to verify whether the mobile device 10 initiated a provisioning request. In some embodiments, verification can be performed by the verification entity computer 60 using a public key (or private key) associated with the private key used to sign the event-specific data or device-specific data. For example, in some embodiments, the event-specific data can be a random number, and the random number can be signed by a private key residing in the secure element on the mobile device 10. The second application 20B can generate the random number and can retrieve the private key from the secure element on the mobile device 10 to sign it. The signed random number can then be provided separately to the authorizing computer system 40, or provided together with the random number to be included 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 are interacting on the mobile device 10, and that the provisioning request originates from the correct mobile device 10.

[0106] In step S208, after the first application 20A receives the account reference identifier from the second application 20B, the first application 20A and / or the authorizing computer system 40 can then determine which account data has not yet been supplied to the mobile device 10. The authorizing computer system 40 can then optionally send the primary account or an alias of the primary account that has not yet been supplied to the second application 20B to the first application 20A in the mobile device 10. In the first application 20A, the user can select any of the presented primary accounts (or their aliases) that have not yet been supplied to the second application 20B, so that they can be supplied to the second application 20B.

[0107] In step S210, if the received authentication data matches the previously stored authentication data, and the authorization computer system 40 has determined that the account data to be supplied exists, the authorization computer system 40 can generate an authentication code.

[0108] Authentication codes can be generated in any suitable manner. An encryption process can be used to generate the authentication code. In some implementations, 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 aforementioned device-specific information and / or event-specific information, and a digitally signed version of that information. Furthermore, the encrypted portion may include the consumer's Master Account Identifier (PAN), the expiration date, the date and time when the authentication code was generated (an example of a time data element) or when the user was verified by an authorized entity, and a specific 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 verification entity computer verifying the authentication code can determine whether it is still valid. Additionally, the authentication code may also include (in encrypted form) the aforementioned 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).

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

[0110] The specific method for generating an authentication code according to an embodiment of the present invention is described in further detail below. Furthermore, by creating an authentication code with both encrypted and unencrypted portions, the authentication code can include information on how to recover any secrets contained in the encrypted portion. Multiple separate data transmissions are not required to provide information on the decryption of the encrypted information.

[0111] In some embodiments, the authentication code is derived from the access data. In some embodiments, the authentication code can encrypt all access data, allowing the provisioning server computer to obtain all access data from the authentication code without needing to obtain that information separately from the authorizing computer system 40. For example, the authentication code can be derived at least from the primary account and the expiration date associated with the primary account, and optionally a verification value (such as a CVV or CVV2 value). In such embodiments, the authentication code can be received and used to obtain the primary account, expiration date, CVV, and CVV2. Because all access data can be derived from the authentication code in some embodiments of the invention, the authorizing computer system 40 does not need to provide the access data to the verification entity computer 80 or the provisioning server computer 90 in separate communications. This is particularly advantageous because it reduces the communication that would otherwise be required between the authorizing computer system 40 and the verification entity computer 80 and the provisioning server computer 90. It is also advantageous because it provides increased security for any primary account, as the primary account does not need to be transmitted.

[0112] In addition to containing all the access data included within the authentication code itself, in some implementations, any information required to transmit the access data to the mobile device 10 may also be included in the authentication code. Such information may include an IP address, phone number, digital wallet ID, communication network ID, etc.

[0113] Furthermore, in the supply system according to an embodiment of the present invention, the authorization system computer 40, the authentication entity computer 80, and the digital wallet server computer 60 can be operated by different entities. While it is straightforward to have the computer system authenticate the user before supplying access data to the mobile device, this is not straightforward when multiple different entities are involved in the supply process. It is also difficult to ensure that the user's sensitive access data and other confidential information are adequately protected during the supply process. The embodiment of the present invention can protect the access data as it passes between the various entities in the system, while also minimizing the number of communications required to supply access data to the mobile device 10.

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

[0115] In step S212, the authentication code is sent from the authorized computer system 40 (e.g., via radio over the air) to the first application 20A in the mobile device 10.

[0116] In step S214, 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 the appropriate API (Application Programming Interface).

[0117] In step S216, 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.

[0118] In step S218, 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.

[0119] 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 together with the authentication code to the verification entity computer 80. In other embodiments, the device-specific information and / or event-specific information may be sent separately from the authentication code to the verification entity computer 80. This data may be plaintext or encrypted, but it can be used by the verification entity computer 80 to verify that the authentication code originates from the correct mobile device 10.

[0120] In step S220, after the verification entity computer 80 receives the authentication code, it then verifies the authentication code. In some embodiments, the verification module 84C in the verification entity computer 80 may take 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 previously received authentication codes (stored in a database) previously received from the authorized computer system and also decrypt any encrypted data. The decrypted data from the previously stored authentication codes and the most recently received authentication codes may then be compared to determine whether the currently received authentication code matches the previously stored authentication code (thus verifying the received authentication code). In other embodiments, access data may have been previously received by the verification entity computer 80 from the authorized computer system 40. This access data may be retrieved from the database and compared with the decrypted information from the received authentication code. If a match exists, and if the authentication code is also valid (e.g., within a predetermined time period), the received authentication code can be verified.

[0121] Furthermore, the previously described signing device and / or event-specific data can also be verified by the verification entity computer 80. The device and / or event-specific data can be obtained from the digital wallet server 60 along with an authentication code. For example, in some embodiments, as described above, the device and / or event-specific data can be signed using an encryption key in a secure element within the mobile device 10. The resulting digital signature can be verified by the verification entity computer 80 using the corresponding encryption key (e.g., a public key) to ensure that account data is supplied to the correct mobile device 10.

[0122] The authenticating entity computer 80 and the authorizing computer system 40 can share symmetric encryption keys that allow them to encrypt and decrypt authentication codes or portions thereof. In other embodiments, the authorizing computer system and the authenticating entity computer can respectively use a public key to encrypt a portion of the authentication code and a private key to decrypt that portion. 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 can be sent to the mobile device 10 indicating that the supply request has failed.

[0123] As described above, in some implementations, the authentication code may contain (in encrypted form) access data to be supplied to the mobile device 10. Decrypting the encrypted information component in the authentication code will provide the verification entity computer 80 and / or the provisioning server computer 90 with all the information they need to supply access data to the second application 20B in the mobile device 10. Therefore, the provisioning server computer 90 does not need to receive access data from the authorizing computer system 40. This reduces the number of data transfers required to supply access data to the second application 20B.

[0124] In step S220, if the authentication code received from the authorization 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 several ways. In some cases, the verification entity computer 80 may send a message to the provisioning server computer 90 to request the provisioning of access data requested by the user of the mobile device 10 to a second application on the mobile device. In another embodiment, the provisioning server computer 90 may be part of the verification 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 required to provide access data to the mobile device 10. Such details may include the access data itself, the address (e.g., a phone number) associated with the mobile device 10 to which it is to be provided, any data used by the mobile device 10 that allows the mobile device 10 to receive access data, etc.

[0125] In step S222, the verification entity computer 30 then sends a message to the supply server computer 90 to initiate the supply process. In step S224, the supply server computer 90 sends the access data to the second application 20B in the mobile device 10 for storage. In some embodiments, the supply server computer 90 may store one encryption key (e.g., a short-lived public ECC key), and the mobile device 10 may store another corresponding encryption key. The supply 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 can then 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) within the mobile device 10.

[0126] The process described above can be used to supply static or dynamic access data to mobile devices. If the access data is dynamic, it can be supplied to the mobile device for each transaction or a predetermined number of transactions (e.g., every 5-10 transactions). This helps to reduce the risk of fraud caused by man-in-the-middle attacks.

[0127] Once access data is supplied to mobile device 10, the access data can be used to conduct access transactions. Figure 8 A system is shown that includes mobile devices supplied with access data and that allow users to access locations such as buildings. Figure 9 A payment processing system is shown, which includes a mobile device that provides access data and allows users to access their accounts to pay for goods or services from merchants.

[0128] Figure 8 A block diagram of a building access system is shown. Figure 8 A mobile device 110 operated by user 206 is shown. As described above, mobile device 110 is supplied with access data. Mobile device 110 can interact with access device 120 and transmit access data to access device 120. Access device 120 can locally verify the received access data, or it can communicate with a remotely located authentication server computer (not shown). The remotely located authentication server computer can verify that the access data is authentic and can send a signal indicating this back to access device 120. Access device 120 can then continue to allow user 206 to enter building 130.

[0129] Figure 9 A block diagram is shown of a transaction processing system that can use mobile devices with access to data. Figure 9A user 206 is shown who can operate mobile device 210. User 206 can use mobile device 210 to pay for goods or services from a merchant. The merchant can operate merchant computer 230 and / or access device 220. The merchant can communicate with issuing computer 260 via acquiring computer 240 and payment processing network 250.

[0130] Payment processing network 250 may include a data processing subsystem, a network, and operations for supporting and transmitting authorization services, exception document services, and clearing and settlement services. An exemplary payment processing network may include VisaNet™. Payment processing networks such as VisaNet™ are capable of processing credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™ specifically includes a VIP system (Visa Integrated Payment System) for processing authorization requests and a BaseII system for performing clearing and settlement services. Payment processing networks may use any suitable wired or wireless network, including the Internet.

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

[0132] Generally, prior to a credit or debit card transaction, the payment processing network 250 has an 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 can be configured to authorize the transaction based on its information 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 can receive the authorization request message, identify the issuer associated with the mobile device 210, and forward the authorization request message to the issuer computer 260 for verification and authorization. Once the transaction is authorized, the issuer computer 260 can generate an authorization response message (which may include an authorization code indicating whether the transaction is approved or rejected) and send the electronic message to the payment processing network 250 via its external communication interface. The payment processing network 250 can then forward the authorization response message to the acquiring computer 240, which can then send an electronic message including authorization instructions to the merchant computer 230, and then to the access device 220.

[0133] At the end of the day or at some other suitable time interval, the transaction can be cleared and settled between the merchant computer 230, the acquiring computer 240, the payment processing network 250, and the issuing computer 260.

[0134] III. Authentication Code Generation

[0135] The authentication code can be formatted in any suitable manner. For example, the data used to generate the authentication code can be password protected through encryption. Many different types of encryption schemes can be used. Any suitable key scheme can be established between the parties creating and verifying the authentication code.

[0136] The password-protected code can be encoded as needed for transmission. For example, in embodiments of the invention, BASE-64, hexBinary, or other encoding schemes can be used to transmit values ​​in text-based messages. The scheme used can be explicitly stated in the message used to transmit the authentication code, or it can be implicit due to prior arrangements between the parties involved.

[0137] Before encryption, the data can be formatted according to a predetermined scheme. This format can contain general information applicable to all uses and use-specific data. In some implementations, the data can be structured with the following data before encryption: Control information – information used to communicate information to the recipients necessary to process that information (e.g., formatting, character encoding). random numbers or characters Total length of data for specific purposes Purpose-specific data Padding (as required by the encryption scheme) Purpose-specific data can be formatted in a way that makes the data content self-evident. When the code is time-sensitive, purpose-specific data may include time data elements. The padding scheme (if used) can be identified from the control information.

[0138] A. Format the authentication code

[0139] In some implementations, the authentication code comprises two main parts, each of which may contain multiple elements. The first part may include plaintext information. The plaintext information includes information necessary to process the encrypted information. The second part may include encrypted information. The encrypted information contains protected data supplied by an authorized entity (e.g., an issuer) to enable a verification entity (e.g., a payment processor or access authorizer) to verify the authenticity and validity of the authentication code.

[0140] The first and second parts can be concatenated to construct an authentication code. The authentication code can be received at the first application and then transmitted as a single data element to a second application on the mobile device (e.g., via a digital wallet provider's API). In some implementations, the constructed authentication code may conform to the following layout, where each component value is separated by a hyphen (-): Type-Version-Key Index-Encryption Information

[0141] The "Type" can be a plaintext component that identifies the type of authentication code. For example, the code type could be a payment account supply code, building access code, payment account activation code, etc. The "Type" can be any suitable form, including letters, numbers, symbols, etc. For example, a mobile banking activation authentication code could be in the form of "MBAAC".

[0142] "Version" can be a plaintext component that specifies the format or version of the authentication code constructed by the issuer.

[0143] The "key index" can be a plaintext component, which identifies the part used for encryption. Encrypted information A specific data encryption key for the component. This value can be coordinated between the authorizing entity and the verifying entity. This value can be represented as a positive integer or any other suitable symbol, character, or identifier. In other embodiments of the invention, a "key name" can be used in place of or supplement the "key index" in the authentication code.

[0144] "Encrypted information" can be a component containing multiple data elements, formatted according to a specific syntax in ASCII text, encrypted, and then hexBinary encoded before being included in the authentication code data field. add Confidential information Each element in a component can use name / value pair syntax, where each name / value pair is separated by a semicolon. Name / value pairs can be used using the following syntax: name=value .

[0145] In some implementations, the following data elements may be included Encrypted information Within the scope of the application, an authentication code can be created that can be used to supply account data to a second application on a mobile device.

[0146] The following may be the sample data before encryption: pan=1234567890123456; datetime=20140424221300; authcode=846932 pan=1234567890123456; datetime=20140424221400; authcode=8AC93Z Then, the constructed data is encrypted. Once encrypted, it can be converted to hexBinary format for use as... Encrypted information The components are contained in the authentication code.

[0147] In some implementation schemes, Encrypted information The component can include all accessed data, making it possible to decrypt it. Encrypted letter interest The necessary information for supplying mobile device 10 exists. For example, in addition to the main account, it may include the expiration date. It may also include verification values, such as CVV or CVV2 values. Furthermore, to prevent repetition or relaying of authentication codes, as mentioned above, [the following can be done / implemented]... Encrypted information This includes additional device-specific information (e.g., device ID or wallet ID) or event-specific information (e.g., random number).

[0148] B. Sample Authentication Code

[0149] Below is an example of a constructed authentication code. Please note that the code shown... Encrypted information The component is an example, but the length of the authentication code can be shorter than the example shown below.

[0150] MBAAC-1-1-7AF291C91F3ED4EF92C1D45EFF127C1F9ABC12347E

[0151] C. Area Encryption Key Parameters

[0152] Used for protection Encrypted informationThe data encryption key for a component can be a double-length triple DES (TDEA) symmetric key. They can be used for the sole purpose of encrypting transient data between parties and are typically different from PINs, MACs, or other specific encryption keys.

[0153] One or more keys used can be transferred between the authorized and verified entities using conventional key transfer and protection schemes before use.

[0154] D. Encryption block formatting

[0155] The verification code Encrypted information Components can be formatted using a cryptographic blockization scheme. Blockization schemes can help protect authentication codes from attacks and provide a consistent method for receiving systems to identify important data within one or more cryptographic blocks.

[0156] The following sections describe the structure and formatting parameters of the encryption blocks before encryption. Each of these encryption blocks can be specially formatted with a consistent structure to facilitate processing and additional security. The first block may contain additional control information not present in the remaining blocks.

[0157] Control Field (First piece only) Control fields can include any data used to communicate information to the recipients who need to process the information (e.g., formatting, character encoding).

[0158] Second control field (First piece only)

[0159] random numbers or characters (First piece only).

[0160] Two-digit data length field – including the number of bits or characters of data to be encrypted. (First piece only). Exclude controls, reserves, length, padding, and random numbers or characters.

[0161] The data to be encrypted is a normal 7-digit ASCII number. (From the second piece to the last piece)

[0162] Includes ASCII character format Encrypted information The plaintext characters of the data to be protected—it can use one or more 8-byte (64-bit) encryption blocks to accommodate the length of the data to be protected as needed.

[0163] Remaining unused spaces can include padding characters as needed.

[0164] An exemplary cryptographic block formatting process can be described below.

[0165] The first piece

[0166] From the second piece to the last piece

[0167] In the example above, C1 can be control field 1. This can be a binary value, such as 00100000 (empty in ASCII text format). C2 can be control field 2. This can also be a binary value, such as 00100000 (empty in ASCII text format). R can be a randomization character. It can contain random 7-bit ASCII characters. L1 and L2 can indicate the length of the data. L1 and L2 can 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 the presence of twenty-six characters. D can be name / value pair data (e.g., 7-bit ASCII characters). D / F can be name / value pair data or padding characters. The labels of these fields are determined by the length field. F can be a padding character. F can be a binary value, such as 00100001 ('!' in ASCII text format).

[0168] The encrypted blocks can be encrypted using the Triple DES Encryption Algorithm with Cipher Block Chaining (CBC) (TDEA) to produce encrypted data to be included in the authentication code. Encrypted information In some implementations, Encrypted information The component can be converted to hexBinary format before being included in the authentication code.

[0169] An example of an encrypted block (plaintext before encryption) can be described as follows. The following data can be formatted so that it can be included in the encrypted message component: pan=1234567890123456; datetime=20140424221300; authcode=846932 Before encoding, nine 64-bit encryption blocks can be constructed in plaintext format (ordinary 7-bit ASCII encoded characters).

[0170]

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

[0172] The embodiments of the present invention have many advantages. For example, as described above, in the embodiments of the present invention, access data can be supplied to an untrusted application by first requesting access data through a trusted first application associated with an authorized entity. The user and the authorized entity can be assured that the request for access data is genuine and not fraudulent. Furthermore, the authentication code described above allows a party other than the authorized entity to supply access data. Finally, since the authentication code has an encrypted portion (i.e., time data elements) 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 supply request is genuine and valid.

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

[0174] It should be understood that the present invention described above can be implemented using computer software in a modular or integrated manner in the form of control logic. Based on the disclosure and teachings provided herein, those skilled in the art will know and understand other ways and / or methods of implementing the present invention using hardware and combinations of hardware and software.

[0175] Any software component or function described in this application can be implemented as software code executed by a processor using any suitable computer language (such as, for example, Java, C++, or Perl) and employing techniques such as conventional or object-oriented methods. The software code can be stored as a series of instructions or commands on a computer-readable medium, such as random access memory (RAM), read-only memory (ROM), magnetic media such as a hard disk drive or floppy disk, or optical media such as a CD-ROM. Any such computer-readable medium can reside on or within a single computing device and can exist on or within different computing devices within a system or network.

[0176] Although some exemplary embodiments have been described in detail and shown in the accompanying drawings, it should be understood that such embodiments are merely illustrative of the invention and not restrictive, and that the invention is not limited to the specific arrangements and structures shown and described, as various other modifications will be apparent to those skilled in the art.

[0177] As used herein, unless explicitly indicated otherwise, the use of “a,” “an,” or “the” is intended to mean “at least one.”

Claims

1. A method for supplying access data, the method comprising: The authorized computer system receives the account reference identifier from the mobile device; In response to receiving the account reference identifier, the authorized computer system generates an authentication code, wherein the authentication code includes encrypted access data; as well as The authorized computer system sends the authentication code to the mobile device. The mobile device sends the authentication code to the verification entity computer, which verifies the authentication code, obtains the access data from the authentication code, and initiates the provision of the access data to the mobile device. The access data is encrypted in the authentication code, and the verification entity computer obtains the access data from the authentication code by decrypting the encrypted access data in the authentication code.

2. The method of claim 1, wherein the mobile device sends the authentication code to the verification entity computer via a digital wallet server computer.

3. The method of claim 1, wherein the mobile device includes a first application and a second application, and the account reference identifier is received from the first application by an authorized computer system, and the access data is sent to the second application.

4. The method of claim 3, wherein the first application is a banking application and the second application is a digital wallet application.

5. The method of claim 1, wherein the verification entity computer verifies the authentication code by comparing the authentication code with another authentication code, wherein the authorization computer system has provided the other authentication code to the verification entity computer.

6. The method of claim 1, wherein the authorized computer system and the verification entity computer share a symmetric key, the symmetric key being used to decrypt and encrypt the access data.

7. The method according to claim 1, wherein the access data includes a master account and a token.

8. The method according to claim 1, further comprising: The authentication data is received by the authorized computer system; The authentication data is verified by the authorized computer system; as well as The authorized computer system sends a response indicating that the authentication data has been verified.

9. The method according to claim 1, wherein the authorized computer system is an issuer system.

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

11. An authorized computer system, comprising: processor; as well as A computer-readable medium comprising code executable by the processor to perform operations including: The authorized computer system receives the account reference identifier from the mobile device; In response to receiving the account reference identifier, the authorized computer system generates an authentication code, wherein the authentication code includes encrypted access data; and The authorized computer system sends the authentication code to the mobile device. The mobile device sends the authentication code to the verification entity computer, the verification entity computer verifies the authentication code, obtains the access data from the authentication code, and initiates the provision of the access data to the mobile device, wherein the access data is encrypted in the authentication code, and the verification entity computer obtains the access data from the authentication code by decrypting the encrypted access data in the authentication code.

12. The authorized computer system of claim 11, wherein the operation further comprises: The authentication data is received by the authorized computer system; The authentication data is verified by the authorized computer system; as well as The authorized computer system sends a response indicating that the authentication data has been verified.

13. The authorized computer system according to claim 11, wherein the authorized computer system is an issuer computer system.

14. The authorized computer system of claim 11, wherein the access data includes a master account or a token.

15. A system for supplying access data, the system comprising: Mobile devices; as well as Authorized computer systems, including: Processor; and A computer-readable medium comprising code executable by the processor to perform operations including: The account reference identifier is received from the mobile device by an authorized computer system; In response to receiving the account reference identifier, the authorized computer system generates an authentication code, wherein the authentication code includes encrypted access data; and The authorized computer system sends the authentication code to the mobile device. The mobile device sends the authentication code to the verification entity computer, which verifies the authentication code, obtains the access data from the authentication code, and initiates the provision of the access data to the mobile device. The access data is encrypted in the authentication code, and the verification entity computer obtains the access data from the authentication code by decrypting the encrypted access data in the authentication code.

16. The system of claim 15, further comprising: The verification entity computer.

17. The system of claim 15, wherein the access data is encrypted in the authentication code, and the verification entity computer obtains the access data from the authentication code by decrypting the encrypted access data in the authentication code.

18. The system of claim 17, wherein the access data includes a master account or a token.

Images