Secure transfer of data during user device interaction

Abstract

Systems and methods securely transfer data during an interaction. An access device receives interaction data from a user device and transmits back an indication of one or more types of supplemental data requested. The access device receives, from the user device, the supplemental data in an encrypted form. The user device encrypted the supplemental data using a session key generated based on at least a subset of the interaction data. The access device transmits, to an issuer server, an authorization request message comprising the interaction data and the indication of the types of supplemental data. The access device receives, from the issuer server, an authorization response message comprising an authorization result and the session key. The issuer server derived the session key responsive to the authorization request message. The access device decrypts the supplemental data and completes the interaction based on the authorization result and the decrypted supplemental data.

Description

SECURE TRANSFER OF DATA DURING USER DEVICE INTERACTIONCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] None.BACKGROUND

[0002] Computer-implemented interactions commonly involve a series of messages between computing devices aimed to determine whether an entity has appropriate credentials to access a secure resource. For example, when an employee scans a key card at a secure location, the scanning device may transmit a request to a central computer that validates the employee’s credentials. As another example, when a customer scans a credit card at a store terminal, the terminal will typically prepare and send request messages to verify the identity and fund availability associated with the credit card.

[0003] Typically, such interactions rely on a structured set of requests and responses. This structure generally limits what types of data can be shared. Although in some cases data can be appended to preestablished data exchange mechanisms for an interaction, there is a lack of security and control over access to the appended data.

[0004] Embodiments address these and other problems, individually and collectively.SUMMARY

[0005] In some embodiments, a computer-implemented method includes receiving, by an access device from a user device, interaction data for an interaction; transmitting, by the access device to the user device, an indication of one or more types of supplemental data requested; receiving, by the access device from the user device, the requested supplemental data in an encrypted form, wherein the user device encrypted the supplemental data using a session key generated based on at least a subset of the interaction data; transmitting, by the access device to an issuer server, an authorization request message comprising the interaction data and theindication of the one or more types of supplemental data requested; receiving, by the access device from the issuer server, an authorization response message comprising an authorization result and the session key, wherein the issuer server derived the session key responsive to the authorization request message; decrypting, by the access device, the encrypted supplemental data; and completing, by the access device, the interaction based on the authorization result and the decrypted supplemental data.

[0006] In some aspects, completing the interaction comprises granting, by the access device, the user device access to a resource. In some aspects, the supplemental data comprises one or more of: an address or a loyalty identifier.

[0007] In some aspects, the interaction is a contactless interaction between the user device and the access device. In some aspects, the indication of the one or more types of supplemental data requested is sent in the form of a processing options command.

[0008] In some aspects, the session key is provided after the issuer server confirms that providing the supplemental data complies with predetermined rules, the predetermined rules being based on a category of the supplemental data and / or a category of a resource provider associated with the access device.

[0009] In some aspects, the user device generated the session key from a secret symmetric key and a diversifier that is based on the at least a subset of the interaction data.

[0010] In some aspects, the access device comprises a contactless interface used to communicate with the user device.

[0011] In some embodiments, a computer-implemented method includes receiving, by an issuer server from an access device, an authorization request message for an interaction with a user device, the authorization request message comprising interaction data and an indication of one or more types of supplemental data requested; generating, by the issuer server, a session key based on at least a subset of the interaction data; and transmitting, by the issuer server to the accessdevice, an authorization response message comprising an authorization result and the session key, thereby causing the access device to: decrypt encrypted supplemental data received from the user device, and complete the interaction based on the authorization result and the decrypted supplemental data.

[0012] In some aspects, the method further comprises confirming, by the issuer server, that providing the supplemental data complies with predetermined rules, the predetermined rules being based on a category of the supplemental data and / or a category of a resource provider associated with the access device, wherein the session key is provided based on confirming compliance with the predetermined rules.

[0013] In some aspects, the method further comprises establishing the rules based on input received from the user device via an issuer application on the user device. In some aspects, the method further comprises generating, by the issuer server, the authorization result based on analysis of the interaction data.

[0014] In some aspects, the supplemental data comprises one or more of: an address or a loyalty identifier. In some aspects, the issuer server generated the session key from a secret symmetric key and a diversifier that is based on the at least a subset of the interaction data.

[0015] Embodiments further include computer systems and computer- readable media for performing the techniques described herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0016] FIG. 1 illustrates an overview of a system and method for secure transfer of data during a user device interaction according to some embodiments.

[0017] FIG. 2 shows an access device according to some embodiments.

[0018] FIG. 3 shows an issuer server according to some embodiments.

[0019] FIG. 4 shows a user device according to some embodiments.

[0020] FIG. 5 is a flow chart illustrating techniques for secure transfer of data during a user device interaction according to some embodiments.DETAILED DESCRIPTION

[0021] Techniques for secure transfer of data during user device interaction include managing requests for supplemental data such as an address or loyalty information using issuer-managed rules and keys. In an interaction between a user device and an access device, the access device receives interaction data for the interaction from the user device. The access device transmits an indication of one or more types of supplemental data requested to the user device. The user device encrypts the supplemental data using a session key and transmits the requested supplemental data to the access device in an encrypted form. The access device transmits an authorization request message, including the interaction data and the types of supplemental data requested, to an issuer server. Based on the interaction data, the issuer server determines an authorization result. The issuer server also analyzes the requested types of supplemental data based on stored access rules to determine whether access to the requested supplemental data should be granted. If the rules permit, then the issuer server derives a session key and includes the session key in an authorization response message back to the access device. The access device uses the session key to decrypt the encrypted supplemental data and completes the interaction based on the authorization result and the decrypted supplemental data.

[0022] The techniques described herein allow a resource provider associated with the access device to request certain types of supplemental data (e.g., within a contactless interaction). The user device encrypts the supplemental data with a secure session key generated based on the interaction data (e.g., so that the session key is unique to the interaction and cannot be reused in another interaction). The issuer server manages rules for the circumstances in which supplemental data can be shared, and can share a session key to decrypt it when appropriate. Thus, the user device, which typically has limited storing and processing capabilities, need not store and decipher the rules used to determine when access to the supplemental data should be granted.

[0023] Prior to discussing specific embodiments, some terms may be described in detail.

[0024] A “user device” may include a device operable by a user. A user device may provide communication capabilities including communication over a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network. Examples of user devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, net books, laptop computers, desktop computers, personal music players, hand-held specialized readers, wearable devices (e.g., watches), vehicles (e.g., cars), etc. A user device may comprise any suitable hardware and software for performing such functions, and may also include multiple devices or components (e.g., when a device has remote access to a network by tethering to another device — i.e. , using the other device as a relay — both devices taken together may be considered a single user device). In some examples, a “user device” is a chip-enabled card such as a credit or debit card.

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

[0026] A “resource provider” may include any entity that can provide resources such as goods, services, information and / or access. Examples of resource providers include merchants, governmental entities, entities that provide access to secure locations, data access providers, etc. A “merchant” may be an entity that engages in transactions and can sell goods or services, or provide access to goods or services.

[0027] An “access device” may be any suitable device for communicating with a merchant computer or transaction processing network (e.g., payment processing network), and for interacting with a consumer communication device. An access device may generally be located in any suitable location, such as at the location of a merchant. An access device may be in any suitable form. Some examples of access devices include POS devices, cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs),kiosks, security systems, access systems, websites, and the like. An access device may use any suitable contact or contactless mode of operation to send or receive data from, or associated with, a consumer communication device. In some embodiments, where an access device may comprise a POS terminal, any suitable POS terminal may be used and may include a reader, a processor, and a computer- readable medium. A reader may include any suitable contact or contactless mode of operation. For example, exemplary readers can include radio frequency (RF) antennas, optical scanners, bar code readers, or magnetic stripe readers to interact with a consumer communication device.

[0028] An “acquirer” may typically be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities can perform both issuer and acquirer functions. Some embodiments may encompass such single entity issuer-acquirers. An acquirer may be associated with one or more “transport computers.”

[0029] An “issuer” may include any entity that issues and manages accounts. An “issuer” may typically refer to a business entity (e.g., a bank) that maintains an account for a user. An issuer may also issue payment credentials stored on a mobile device, such as a cellular telephone, smart cart card, tablet, or laptop to the consumer. An issuer may authorize or decline interactions based on interaction data. An issuer may operate an issuer server.

[0030] A “server” or “server computer” may include a powerful computer or cluster of computers. For example, the server can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server may be a database server coupled to a Web server. The server may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.

[0031] A “processing system” may include a network of one or more devices that can process and route transaction request messages. An example of a processing system may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, transactionscoring services, and clearing and settlement services. An example of a processing system is VisaNet™. Transaction processing systems such as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, may include a VIP system (Visa Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services. A processing system may operate one or more “processor server computers.’’

[0032] An “interaction” can be a reciprocal action, effect, or influence. Example interactions include a transaction between two parties and a data exchange between two devices. In some embodiments, an interaction can include a user requesting access to secure data, a secure webpage, a secure location, and the like. In other embodiments, an interaction can include a payment transaction in which two devices can interact to facilitate a payment. An interaction may involve the exchange of monetary funds, or the exchange of goods or services for monetary funds between two individuals or entities.

[0033] “Interaction data” may include any suitable data that can be used to facilitate an interaction. Interaction data may be in any suitable form. Examples of interaction data may include a PAN (primary account number or “account number”), user name, expiration date, CW (card verification value), dCW (dynamic card verification value), CW2 (card verification value 2), etc. Interaction data may be any information that identifies or is associated with a payment account. Interaction data may be provided in order to make a payment from a payment account. Interaction data can also include a user name, an expiration date, a gift card number or code, and any suitable information.

[0034] An “account identifier” may include an original account identifier associated with a payment account. For example, an account identifier may be a primary account number (PAN) issued by an issuer for a card account (e.g., credit card, debit card, etc.). For instance, in some embodiments, an account identifier may include a sixteen digit numerical value such as “4147 0900 0000 1234.” The first six digits of the account identifier (e.g., “414709”) may represent an authorization entity identifier (BIN) that may identify an issuer associated with the account identifier.

[0035] “Supplemental data” may include data that supplements interaction data. Supplemental data may be associated with the interaction data but may not be strictly required to complete the interaction. Examples of supplemental data include an address (e.g., a shipping address or billing address), loyalty information (e.g., a loyalty account number or status), or other contact information (e.g., a phone number or email address). Examples of supplemental data may include non-payment data.

[0036] The term “message” may include any data or information that may be transported from one entity to another entity (e.g., one computing device to another computing device). Messages may be communicated internally between devices / components within a computer or computing system or externally between devices over a communications network. Additionally, messages may be modified, altered, or otherwise changed to comprise encrypted or anonymized information.

[0037] An “authorization request message” may include any electronic message that is sent to request authorization for a transaction. In some embodiments, an authorization request message may be an electronic message that is sent to a payment processing network and / or an issuer of a payment card to request authorization for a transaction. An authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a consumer using a payment device or payment account. The authorization request message may include an issuer account identifier that may be associated with a payment device or payment account. An authorization request message may also comprise additional data elements corresponding to “identification information” including, by way of example only: a service code, a CVV (card verification value), a dCW (dynamic card verification value), an expiration date, etc. An authorization request message may also comprise “transaction information,” such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location, etc., as well as any other information that may be utilized in determining whether to identify and / or authorize a transaction.

[0038] An “authorization response message” may include any electronic message reply to an authorization request message. It may be generated by anissuing financial institution or a payment processing network. The authorization response message may include, by way of example only, one or more of the following status indicators: Approval — transaction was approved; Decline — transaction was not approved: or Call Center — response pending more information, merchant must call the toll-free authorization phone number. The authorization response message may also include an authorization code, which may be a code that a credit card issuing bank returns in response to an authorization request message in an electronic message (either directly or through the payment processing network) to the merchants access device (e.g., PCS equipment) that indicates approval of the transaction. The code may serve as proof of authorization.

[0039] A “memory” may include suitable device or devices that can store electronic data. A suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor to implement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and / or magnetic mode of operation.

[0040] A “processor” may include any suitable data computation device or devices. A processor may comprise one or more microprocessors working together to accomplish a desired function. The processor may include a CPU that comprises at least one high-speed data processor adequate to execute program components for executing user and / or system-generated requests. The CPU may be a microprocessor such as AMD's Athlon, Duron and / or Opteron; IBM and / or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or the like processor(s).

[0041] FIG. 1 shows an overview of a system 100 and method for secure transfer of data during a user device interaction according to some embodiments. The system 100 can include a user device 102, an access device 104, a transport computer 106, a processor server 108, and an issuer server 110. For simplicity of illustration, a limited number of components are shown in FIG. 1 . It is understood, however, that embodiments may include more than one of each component.

[0042] The components in the system depicted in FIG. 1 can be in operative communication with each other through any suitable communication channel or communications network. Suitable communications networks may be any one and / or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), l-mode, and / or the like); and / or the like. Messages between the computers, networks, and devices may be transmitted using a secure communications protocol such as, but not limited to, Secure File Transfer Protocol (SFTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), and / or the like.

[0043] In some embodiments, the user device 102 is a device operable by a user and capable of executing applications. As examples, the user device 102 may be a smartphone, a computer, a tablet, or the like. Alternatively, the user device 102 may be a payment instrument such as a credit card. The user device 102 includes functionality to store, encrypt, and share supplemental data as described herein. An example of a user device is described in further detail below with respect to FIG. .4

[0044] The access device 104 is a device that can be used to access an external system. As described above, some examples of access devices include POS devices, cellular phones, PDAs, personal computers (PCs), tablet PCs, handheld specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, Websites, and the like. An example access device 200 is described below in further detail with respect to FIG. 2.

[0045] The transport computer 106 may be associated with the resource provider device, and may manage requests (e.g., authorization requests) on behalf of the resource provider. In some embodiments, the transport computer 106 may be operated by an acquirer.

[0046] The processor server 108 may include functionality to process interactions. In some examples, the processor server 108 is associated with a payment network.In some embodiments, the processor server 108 is configured to route messages to appropriate entities such as transport computers and issuer computers.

[0047] The issuer server 110 may be a server computer associated with an issuer or entity (e.g., a bank) that has a business relationship with a processor server 108 or other entity. In some embodiments, the issuer server 110 is configured to send and receive interaction-related messages, as well as identify whether a particular interaction should be authorized. The issuer server 110 further includes functionality to manage access to supplementary data by rule checking and generating and issuing a session key when appropriate.

[0048] In some instances, prior to the processing of steps S112 - S136, initial setup is performed. A user associated with the user device provides supplemental data (e.g. , shipping address) to the issuer for injection to the user device during personalization of the user device. In some examples, the injection or update of supplemental data is performed through an issuer application executing on the user device.

[0049] In some aspects, the initial setup further comprises establishing privacy access rules for sharing of supplemental data with one or more resource providers. The user and / or issuer can establish that some or all types of supplemental data can be shared with some or all resource providers. For example, rules can be established to share all supplemental data, certain categories of supplemental data (e.g., retail, health, etc.), or individual types of supplemental data (e.g., shipping address, loyalty identifier for Store A, etc.). Alternatively, or additionally, rules can be established to share supplemental data with all resource providers, with certain resource providers based on merchant category code (MCC), with certain resource providers based on country code, with certain resource providers based on merchant allowlist, or with certain resource providers based on merchant denylist.Alternatively, or additionally, rules can be established to share supplemental data for different types of interactions, such as for all interactions or only for approved interactions.

[0050] In some embodiments, at step S112, the user device initiates an interaction with the access device. In some examples, the user of the user deviceinitiates a payment transaction to transmit payment to the access device in exchange for access to a resource such as goods or services. The user device may, for example, be tapped on a contactless reader of an access device such as a POS terminal to initiate a contactless interaction. As the contactless interaction is initiated, interaction data is transmitted from the user device to the access device. The interaction data may include, for example, an account identifier, CVV code, expiration date, token, Application Transaction Counter (ATC) value, Application Cryptogram and / or timestamp.

[0051] In some embodiments, at step S114, the access device identifies and requests one or more types of supplemental data from the user device. For example, the access device sends a list of one or more types of supplemental data to the user device. In some examples, the supplemental data list is transmitted in a GET PROCESSING OPTIONS command in a contactless transaction (e.g., 5F42 - Shipping Address).

[0052] In some embodiments, at step S116, upon receiving the requested type(s) of supplemental data, the user device searches its storage for the matching supplemental data.

[0053] At step S117, if the requested supplemental data is found on the user device, then the user device derives a session key. In some instances, the session key is derived from a secret symmetric key (e.g., a Europay, MasterCard, and Visa (EMV) application cryptogram (AC) key or a dedicated key for supplemental data) and a diversifier. In some examples, the diversifier is built based on some or all of the interaction data. For example, the diversifier is derived from EMV data such as an ATC value. The user device uses the session key to encrypt the requested supplemental data.

[0054] At step S118, the user device transmits the encrypted supplemental data to the access device. The user device may, for example, transmit the encrypted supplemental data to the access device in the course of a contactless interaction.

[0055] At steps S120-S124, the access device transmits an authorization request message to the issuer server. The authorization request message includes the interaction data and an indication of the requested supplemental data. In the example depicted in FIG. 1 , the access device transmits the authorization request message to the transport computer at S120. The transport computer forwards the authorization request message to the processor computer at S122. The processor computer forwards the authorization request message to the issuer server at S124.

[0056] At step S126, the issuer server determines whether to authorize the interaction, and checks the privacy rules against the requested supplemental data. The issuer server compares the type(s) of supplemental data requested to the rules (e.g., is the type of supplemental data requested sharable with the type or resource provider requesting it).

[0057] At step S127, if the sharing of the supplemental data requested is allowed, then the issuer server derives a session key for decrypting the supplemental data. The session key can be derived in a similar fashion as described above with respect to step 117.

[0058] At step S128, the issuer server transmits an authorization response message to the access device. The authorization response message includes the session key and an indication whether the interaction is approved or declined. In the example depicted in FIG. 1 , the issuer server transmits the authorization response message to the processor server at S128. The processor server transmits the authorization response message to the transport computer at S130. The transport computer forwards the authorization request message to the access device at S132.

[0059] At step S134, the access device decrypts the encrypted supplemental data using the received session key. The access device may then use the decrypted supplemental data, along with the authorization result received, to complete the interaction with the user device at step S136.

[0060] FIG. 2 shows a block diagram of an access device 200 according to some embodiments. As described above with respect to FIG. 1 , the access device 200 may be associated with a resource provider and configured to manage accessto resources by the resource provider. The access device 200 may include a processor 202. The processor 202 may be any suitable processing apparatus or device as described above. The processor 202 may be coupled to communication interfaces 204 and a computer-readable medium 206.

[0061] The communication interfaces 204 may include one or more interfaces that can allow the access device 200 to communicate with external computing devices. The communication interfaces 204 may enable the access device 200 to communicate data to and from another device (e.g., the user device, the issuer server, etc.). Some examples of a communication interfaces 204 may include a modem, a physical network interface (such as an Ethernet card or other Network Interface Card (NIC)), a virtual network interface, a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, or the like. The wireless protocols enabled by the communication interfaces 204 may include Wi-Fi™. Data transferred via the communication interfaces 204 may be in the form of signals which may be electrical, electromagnetic, optical, or any other signal capable of being received by the external communications interface (collectively referred to as “electronic signals” or “electronic messages”). These electronic messages that may comprise data or instructions may be provided between the communication interfaces 204 and other devices via a communications path or channel. As noted above, any suitable communication path or channel may be used such as, for instance, a wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link, a WAN or LAN network, the Internet, or any other suitable medium. The communication interfaces 204 can utilize a long-range communication channel and / or a short-range communication channel.

[0062] In some aspects, the communication interfaces 204 include a contactless interface 204A and a network interface 204B. The contactless interface 204A may include one or more RF transceivers to interact with a contactless interface of the user device to exchange information to perform an interaction. The network interface 204B may include a wired or wireless network interface configured to communicate with remote devices such as the issuer server, processor server, and transport computer.

[0063] The computer-readable medium 206 may be a non-transitory computer-readable medium that includes software code stored as a series of instructions or commands. The computer-readable medium 206 may comprise code, executable by the processor 202, to implement a method comprising: receiving, by the access device from a user device, interaction data for an interaction; transmitting, by the access device to the user device, an indication of one or more types of supplemental data requested; receiving, by the access device from the user device, the requested supplemental data in an encrypted form, wherein the user device encrypted the supplemental data using a session key generated based on at least a subset of the interaction data; transmitting, by the access device to an issuer server, an authorization request message comprising the interaction data and the indication of the one or more types of supplemental data requested; receiving, by the access device from the issuer server, an authorization response message comprising an authorization result and the session key, wherein the issuer server derived the session key responsive to the authorization request message; decrypting, by the access device, the encrypted supplemental data; and completing, by the access device, the interaction based on the authorization result and the decrypted supplemental data.

[0064] The computer-readable medium 206 may include a communication module 208, a secure data handling module 210, and an interaction module 212. Each of these modules may include code configured to perform the functions described below in conjunction with the processor 202.

[0065] The communication module 208 may comprise code that causes the processor 202 to generate messages, forward messages, reformat messages, and / or otherwise communicate with other entities.

[0066] The secure data handling module 210 may comprise code that causes the processor 202 to perform secure data handling operations. The secure data handling operations can include identifying types of supplemental data to request, and decrypting and analyzing the supplemental data.

[0067] The interaction module 212 may include code that causes the processor 202 to conduct interactions with user devices. Conducting interactions with user devices may include granting access to resources when appropriate and processing interaction data. Conducting interactions with user devices may also include applying supplemental data for tasks such as arranging shipping or granting or redeeming loyalty points.

[0068] FIG. 3 shows a block diagram of an issuer server 300 according to some embodiments. As described above with respect to FIG. 1 , the issuer server 300 can be associated with an authorizing entity such as the issuer of an account. The issuer server 300 may include a processor 302 coupled to a communication interface 304 and a computer-readable medium 306. The processor 302 and communication interface 304 may be similar to the processor 202 and communication interface 204 described above with respect to FIG. 2.

[0069] The computer-readable medium 306 may be a non-transitory computer-readable medium that includes software code stored as a series of instructions or commands. The computer-readable medium 306 may comprise code, executable by the processor 302, to implement a method comprising: receiving, by the issuer server from an access device, an authorization request message for an interaction with a user device, the authorization request message comprising interaction data and an indication of one or more types of supplemental data requested; generating, by the issuer server, a session key based on at least a subset of the interaction data; and transmitting, by the issuer server to the access device, an authorization response message comprising an authorization result and the session key, thereby causing the access device to: decrypt encrypted supplemental data received from the user device, and complete the interaction based on the authorization result and the decrypted supplemental data.

[0070] The computer-readable medium 306 may include a supplemental data management module 308, a key management module 310, and an authorization module 312. Each of these modules may include code configured to perform the functions described below in conjunction with the processor 302.

[0071] The supplemental data management module 308 may include code that causes the processor 302 to manage requests for supplemental data.Managing the requests may include identifying requested types of supplemental data and determining whether access to the requested supplemental data should be granted based on access rules 309.

[0072] The access rules 309 are configured rules that establish what types of supplemental data should be shared with what types or resource providers under what circumstances. As described above with respect to FIG. 1 , the access rules may specify types of supplemental data (e.g., address, loyalty information, etc.) to share with types of resource providers (e.g., based on MCC, specific resource provider, etc.).

[0073] The key management module 310 may comprise code that causes the processor 302 to manage keys. Managing keys may include generating session keys as described herein. Key management performed by the key management module 310 may further include sharing the session keys, when appropriate, with an access device.

[0074] The authorization module 312 may include code that causes the processor 302 to determine whether or not to authorize an interaction. For example, the authorization module 312 may be configured to identify an account and determine whether the account is in good standing and has adequate funds for an interaction.

[0075] FIG. 4 shows an example of a user device 400 according to some embodiments. The user device 400 may include circuitry that is used to enable certain device functions, such as wireless communication or telephony. The functional elements responsible for enabling those functions may include a processor 402 that can execute instructions that implement the functions and operations of the user device. Processor 402 may access application I data storage 410 (or another suitable memory region or element) to retrieve instructions or data used in executing the instructions. The user device 400 may include more or fewer components than depicted in FIG. 4, according to various implementations. Forexample, in implementations in which the user device is a credit card, the display 404 may be omitted or modified.

[0076] Data input / output 406, such as a keyboard or touchscreen, may be used to enable a user to operate the user device 400 (for example, allowing the user to navigate to an issuer application 416). Data input / output 406 may also be configured to output data (via a speaker, for example). Display 404 may also be used to output data to a user. Communications elements 408 may be used to enable data transfer between the user device 400 and a wired or wireless network (via antenna 408C, for example), enable data transfer functions, and may be used to assist in connectivity to the Internet or another network. The communications elements 408 can include a contactless interface 408A and a network interface 408B, which may be similar to the contactless interface 204A and network interface 204B described above with respect to FIG. 2.

[0077] The application I data storage 410 may comprise a computer-readable medium that may include a number of software modules, such as communications module 142, key management module 414, and issuer application 416.

[0078] The communications module 412 may comprise code enabling the processor 402 to implement or enable communications between the user device 400 and other devices, such as access devices, other user devices, or server computers. The communications module 412 may allow communication according to any appropriate protocol, such as TCP, UDP, IS-IS, OSPF, IGRP, EIGRP, RIP, BGP, etc. The communications module 412 may allow secure communication by enabling the processor 402 to establish a secure or encrypted communication channel between the user device 400 and other devices. The communications module 412 may allow the transmission of interaction data, supplemental data, and other data to other devices, such as the access device 200.

[0079] The key management module 414 may comprise code enabling the user device 400 to manage keys. Managing keys may include generating session keys as described herein. Key management performed by the key management module 414 may further include encrypting supplemental data with a generated session key.

[0080] The issuer application 416 may be an application that can be used to configure rules or preferences applied by an issuer. The issuer application 416 may be any suitable type of application such as a banking application. In some aspects, the issuer application 416 includes functionality for a user device to establish rules for access to supplemental data.

[0081] FIG. 5 is a flow chart illustrating a process 500 for authentication enrollment according to some embodiments. The process 500 may be performed by an access device in cooperation with a user device and issuer server and other computing devices and illustrated in FIGS. 1-4.

[0082] At step 502, the access device receives interaction data for an interaction from the user device. The interaction data may be received for an interaction between the user device and the access device, such as a contactless interaction between the user device and the access device. The interaction data may be transmitted from the user device to the access device in the course of a contactless interaction (e.g., a tap payment transaction). Alternatively, or additionally, the interaction data may be transmitted via contact interaction (e.g., chip or swipe), or over the internet. The interaction data may include data for facilitating an interaction such as an account identifier, CVV code, expiration date, token, ATC value, application cryptogram, and / or timestamp.

[0083] At step 504, the access device transmits an indication of one or more types of supplemental data requested to the user device. The access device may identify supplemental data that would be necessary or useful for facilitating the interaction, such as a shipping address, loyalty account number, or other types of supplemental data. The access device prepares a message for requesting the supplemental data. The supplemental data may be requested in association with an interaction with the user device (e.g., in one of a series of transmissions of an interaction between the access device and the user device). In some aspects, the request is sent via contactless interaction. For example, the indication of the one or more types of supplemental data requested is sent in the form of a processing options command. As a specific example, the requested supplemental data type(s)are transmitted in a GET PROCESSING OPTIONS command in a contactless transaction (e g., 5F42 - Shipping Address).

[0084] Responsive to receiving the request for supplemental data, the user device generates a session key and encrypts the supplemental data with the session key. The user device may traverse stored supplemental data to identify the supplemental data requested by the access device (e.g., the user device may store a shipping address and loyalty information for various resource providers. Resource provider A requests loyalty information for Resource provider A, which is identified by the user device responsive to the request). The user device generates a session key based on at least a subset of the interaction data. For example, the user device generates a diversifier based on some or all of the interaction data. As a specific example, the diversifier is derived from EMV data such as an ATC value. The user device derives the session key from the diversifier. In some examples, the session key is further generated using a secret symmetric key (e.g., an ENC or AC key, or dedicated key for supplemental data). In some examples, the secret symmetric key is used to encrypt the diversifier to generate the session key. In some implementations, the user device obtains a master key and encrypts the account identifier to generate a card key, then encrypts the diversifier using the card key to generate the session key. The user device uses the session key to encrypt the requested supplemental data.

[0085] At step 506, the access device receives, from the user device, the requested supplemental data in an encrypted form. The encrypted supplemental data may, for example, be received via contactless transmission from the user device to the access device. As described above, the user device encrypted the supplemental data using a session key generated based on at least a subset of the interaction data, and in some examples, the user device generated the session key from a secret symmetric key and a diversifier that is based on the at least a subset of the interaction data.

[0086] At step 508, the access device transmits, to the issuer server, an authorization request message comprising the interaction data and the indication of the one or more types of supplemental data requested. The access device preparesthe authorization request message to include the interaction data and the indication of the one or more types of supplemental data requested. The access device transmits the authorization request message to the issuer server (e.g., via a network transmission over a wireless or wired connection). In some implementations, as depicted in FIG. 1 , the access device transmits the authorization request message to a transport computer, which forwards the authorization request message to a processor server, which forwards the authorization request message to the issuer server.

[0087] Subsequent to step 508, the issuer server receives and processes the authorization request message. The issuer server performs authorization operations to determine whether to approve or decline the interaction (e.g., by comparing an interaction amount to an amount in an account of the user, checking account status, etc.). The issuer server analyzes the type(s) of supplemental data requested based on stored access rules. As described above with respect to FIG. 1 , the issuer server manages access rules that may specify that certain types of supplemental data (e.g., loyalty information, shipping address, etc.) can be shared with certain resource providers or types or resource providers (e.g. , with Merchant A or Merchant B; with healthcare providers or car sellers; etc.). The access rules may further specify a type of interaction in which certain types of supplemental information can be shared (e.g., for all interactions or approved interactions). The issuer server compares the requested type(s) of supplemental data to the access rules to determine whether the requesting resource provider should be granted access to the requested supplemental data. For example, the interaction data received may include an MCC specifying that the resource provider is a grocery store. The issuer consults the rules to determine whether the requested type of supplemental data can be shared with grocery stores.

[0088] If the requested supplemental data should be shared based on the access rules, then the issuer server generates a session key. The issuer server may, for example, generate the session key from a secret symmetric key and a diversifier that is based on at least a subset of the interaction data. The session key can be generated by the issuer server in a similar fashion as the session key is generated by the user device, as described above.

[0089] If the requested data should be shared based on the access rules, then the issuer server prepares an authorization response message, comprising the authorization result and the session key, and transmits the authorization request message to the access device. In cases where the access rules do not permit sharing the supplemental data, the issuer server refrains from transmitting or generating the session key, and the authorization response message includes the authorization result but not the session key. In some implementations, as depicted in FIG. 1 , the issuer server transmits the authorization request message to a processor server, which forwards the authorization request message to a transport computer, which forwards the authorization request message to the access device.

[0090] At step 510, the access device receives, from the issuer server, an authorization response message comprising an authorization result and the session key, wherein the issuer server derived the session key responsive to the authorization request message. As described above, the session key is provided after the issuer server confirms that providing the supplemental data complies with predetermined rules. The predetermined rules can be based on criteria such as a category of the supplemental data (e.g., shipping address, loyalty account information, etc.) and / or a category of a resource provider associated with the access device (e.g., grocery store, travel, healthcare, retail store, service provider, etc.).

[0091] At step 512, the access device decrypts the encrypted supplemental data. The access device uses the session key received at step 510 to decrypt the encrypted supplemental data.

[0092] At step 514, the access device completes the interaction based on the authorization result and the decrypted supplemental data. Completing the interaction may include granting, by the access device, the user device access to a resource. The access device may use the decrypted supplemental data to perform functions such as shipping goods to a determined shipping address, granting or redeeming points from an identified loyalty account, and / or the like.

[0093] The techniques described herein provide security improvements by encrypting supplemental data using an interaction-specific session key and onlyreleasing the session key to resource providers that fit a set of established privacy access rules. The user device stores and shares encrypted supplemental data with resource providers. The issuer server manages rules for the circumstances in which supplemental data can be shared, and can derive and share a session key to decrypt the encrypted supplemental data when appropriate. Thus, the user device, which typically has limited storing and processing capabilities, need not store or apply the rules used to determine when access to the supplemental data should be granted. And, by transmitting the encrypted user data from the user device to the access device and the key to decrypt the encrypted supplemental data from the issuer server to the access device, the supplemental data can be securely shared within the confines of an interaction such as a contactless payment interaction, which limits what types of data can be transmitted in interaction processing messages.

[0094] Any of the computer systems mentioned herein may utilize any suitable number of subsystems. In some embodiments, a computer system includes a single computer apparatus, where the subsystems can be components of the computer apparatus. In other embodiments, a computer system can include multiple computer apparatuses, each being a subsystem, with internal components.

[0095] A computer system can include a plurality of the components or subsystems, e.g., connected together by external interface or by an internal interface. In some embodiments, computer systems, subsystems, or apparatuses can communicate over a network. In such instances, one computer can be considered a client and another computer a server, where each can be part of a same computer system. A client and a server can each include multiple systems, subsystems, or components.

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

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

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

[0099] Any of the methods described herein may be totally or partially performed with a computer system including one or more processors, which can be configured to perform the steps. Thus, embodiments can involve computer systems configured to perform the steps of any of the methods described herein, potentially with different components performing a respective step or a respective group ofsteps. Although presented as numbered steps, steps of methods herein can be performed at a same time or in a different order. Additionally, portions of these steps may be used with portions of other steps from other methods. Also, all or portions of a step may be optional. Additionally, and of the steps of any of the methods can be performed with modules, circuits, or other means for performing these steps.

[0100] The specific details of particular embodiments may be combined in any suitable manner without departing from the spirit and scope of embodiments of the invention. However, other embodiments of the invention may be involve specific embodiments relating to each individual aspect, or specific combinations of these individual aspects. The above description of exemplary embodiments of the invention has been presented for the purpose of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form described, and many modifications and variations are possible in light of the teaching above. The embodiments were chosen and described in order to best explain the principles of the disclosure and its practical applications to thereby enable others skilled in the art to best utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated.

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

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

[0103] A recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary. The use of “or” is intended to mean an “inclusive or,” and not an “exclusive or” unless specifically indicated to the contrary.

[0104] All patents, patent applications, publications and description mentioned herein are incorporated by reference in their entirety for all purposes. None is admitted to be prior art.

Claims

WHAT IS CLAIMED IS:1 . A computer-implemented method comprising: receiving, by an access device from a user device, interaction data for an interaction; transmitting, by the access device to the user device, an indication of one or more types of supplemental data requested; receiving, by the access device from the user device, the requested supplemental data in an encrypted form, wherein the user device encrypted the supplemental data using a session key generated based on at least a subset of the interaction data; transmitting, by the access device to an issuer server, an authorization request message comprising the interaction data and the indication of the one or more types of supplemental data requested; receiving, by the access device from the issuer server, an authorization response message comprising an authorization result and the session key, wherein the issuer server derived the session key responsive to the authorization request message; decrypting, by the access device, the encrypted supplemental data; and completing, by the access device, the interaction based on the authorization result and the decrypted supplemental data.

2. The method of claim 1 , wherein: completing the interaction comprises granting, by the access device, the user device access to a resource.

3. The method of claim 1 , wherein: the supplemental data comprises one or more of: an address or a loyalty identifier.

4. The method of claim 1 , wherein the interaction is a contactless interaction between the user device and the access device.

5. The method of claim 1 , wherein the indication of the one or more types of supplemental data requested is sent in the form of a processing options command.

6. The method of claim 1 , wherein the session key is provided after the issuer server confirms that providing the supplemental data complies with predetermined rules, the predetermined rules being based on a category of the supplemental data and / or a category of a resource provider associated with the access device.

7. The method of claim 1 , wherein the user device generated the session key from a secret symmetric key and a diversifier that is based on the at least a subset of the interaction data.

8. An access device comprising: a processor; and a non-transitory computer-readable medium comprising code, executable by the processor, for implementing operations comprising: transmitting, to a user device, an indication of one or more types of supplemental data requested in association with an interaction with the user device; receiving, from the user device, the requested supplemental data in an encrypted form, wherein the user device encrypted the supplemental data using a session key generated based on interaction data for the interaction; transmitting, to an issuer server, an authorization request message comprising the interaction data and the indication of the one or more types of supplemental data requested; receiving, from the issuer server, an authorization response message comprising an authorization result and the session key, wherein the issuer server derived the session key responsive to the authorization request message; decrypting the encrypted supplemental data; and completing the interaction based on the authorization result and the decrypted supplemental data.

9. The access device of claim 8, wherein:completing the interaction comprises granting the user device access to a resource.

10. The access device of claim 8, wherein the supplemental data comprises one or more of: an address, a loyalty identifier, or a phone number.11 . The access device of claim 8, wherein the interaction is a contactless interaction between the user device and the access device.

12. The access device of claim 8, further comprising a contactless interface used to communicate with the user device.

13. The access device of claim 8, wherein the indication of the one or more types of supplemental data requested is sent in the form of a processing options command.

14. The access device of claim 8, wherein the session key is provided after the issuer server confirms that providing the supplemental data complies with predetermined rules, the predetermined rules being based on a category of the supplemental data and / or a category of a resource provider associated with the access device.

15. A computer-implemented method comprising: receiving, by an issuer server from an access device, an authorization request message for an interaction with a user device, the authorization request message comprising interaction data and an indication of one or more types of supplemental data requested; generating, by the issuer server, a session key based on at least a subset of the interaction data; and transmitting, by the issuer server to the access device, an authorization response message comprising an authorization result and the session key, thereby causing the access device to:decrypt encrypted supplemental data received from the user device, and complete the interaction based on the authorization result and the decrypted supplemental data.

16. The method of claim 15, further comprising: confirming, by the issuer server, that providing the supplemental data complies with predetermined rules, the predetermined rules being based on a category of the supplemental data and / or a category of a resource provider associated with the access device, wherein the session key is provided based on confirming compliance with the predetermined rules.

17. The method of claim 16, further comprising: establishing the rules based on input received from the user device via an issuer application on the user device.

18. The method of claim 15, further comprising: generating, by the issuer server, the authorization result based on analysis of the interaction data.

19. The method of claim 15, wherein: the supplemental data comprises one or more of: an address or a loyalty identifier.

20. The method of claim 15, wherein: the issuer server generated the session key from a secret symmetric key and a diversifier that is based on the at least a subset of the interaction data.

Images