Secure reader with selective data element encryption

Abstract

A method is disclosed and includes generating, by a session key derivation module in a user device, a session key, and transmitting to a portable device, a command message. The method includes receiving a response message comprising a plurality of data elements including sensitive values and non-sensitive values. The user device determines, by a secure reader module in the user device, the sensitive values in the data elements, and encrypts, by the secure reader module in the user device using the session key, the sensitive values to form encrypted sensitive values. The method further comprises passing, by the secure reader module to an acceptance application in the user device, a data packet including the plurality of data elements including the encrypted sensitive values and the unencrypted non-sensitive values. The method further comprises transmitting, by the user device via the acceptance application, the data packet to a server computer.

Description

PATENT Attorney Docket No. 079900-1542828-10369W001Client Ref. No. 10369W001SECURE READER WITH SELECTIVE DATA ELEMENT ENCRYPTIONCROSS-REFERENCES TO RELATED APPLICATIONS

[0001] This application is a PCT application of and claims priority to and the benefit of the filing date of U.S. Provisional Application No. 63 / 777,584, filed on March 25, 2025, which is herein incorporated by reference in its entirety.BACKGROUND

[0002] A current interaction protocol between a portable device and a user device transmits data from the portable device to the user device. The portable device can be a card. The user device can be a mobile phone that behaves like an acceptance terminal. The transmitted data may include PH (personal identifiable information) data such as a PAN (primary account number), expiry date, etc.

[0003] An acceptance application (e.g., an acceptance I kernel application) on the user device, which processes the PH data, has to comply with PCI (payment card industry) requirements. Implementing PCI requirements in the acceptance application is complex, and is a barrier to widespread application of different acceptance applications. This is particularly true in the case where acceptance processing is to occur on a COTS (commercial, off-the-shelf) device such as a consumer’s smartphone.

[0004] Also, there are different types of acceptance application specifications, which multiplies the complexity and workload with respect PCI compliance in the development, certification, and maintenance of acceptance applications.

[0005] Further, if the PH data that is transmitted from the portable device to the user device changes in time (e.g., a new data field with a new PH data element is required in future transaction processing), then many different acceptance179505273V.1applications would need to be updated to handle such changes. This can be burdensome.

[0006] Embodiments of the invention address these and other problems, individually and collectively.BRIEF SUMMARY

[0007] One embodiment of the invention includes a method for performing an interaction, the method comprising: generating, by a session key derivation module in a user device, a session key; transmitting, by the user device to a portable device, a command message; receiving, by the user device from the portable device, a response message comprising a plurality of data elements including sensitive values and non-sensitive values; determining, by a secure reader module in the user device, the sensitive values in the data elements; encrypting, by the secure reader module in the user device using the session key, the sensitive values to form encrypted sensitive values, without encrypting the non-sensitive values; passing, by the secure reader module to an acceptance application in the user device, a data packet including the plurality of data elements including the encrypted sensitive values and the unencrypted non-sensitive values; and transmitting, by the user device via the acceptance application, the data packet to a server computer, wherein the server computer is programmed to obtain the session key and decrypt the encrypted sensitive values in the data packet using the session key to obtain plaintext sensitive values and process an interaction using the plurality of data elements including the unencrypted non-sensitive values and the plaintext sensitive values.

[0008] Another embodiment of the invention includes a user device comprising a processor and a computer readable medium. The computer readable medium comprises code, executable by the processor, for performing a method comprising: generating, by a session key derivation module in the user device, a session key; transmitting, by the user device to a portable device, a command message; receiving, by the user device from the portable device, a response message comprising a plurality of data elements including sensitive values and non-sensitive values; determining, by a secure reader module in the user device, the sensitive values in the data elements; encrypting, by the secure reader module in the 279505273V.1user device using the session key, the sensitive values to form encrypted sensitive values, without encrypting the non-sensitive values; passing, by the secure reader module to an acceptance application in the user device, a data packet including the plurality of data elements including the encrypted sensitive values and the unencrypted non-sensitive values; and transmitting, by the user device via the acceptance application, the data packet to a server computer, wherein the server computer is programmed to obtain the session key and decrypt the encrypted sensitive values in the data packet using the session key to obtain plaintext sensitive values and process an interaction using the plurality of data elements including the unencrypted non-sensitive values and the plaintext sensitive values.

[0009] Another embodiment of the invention includes a method comprising: receiving, by a server computer from a user device, a data packet including a plurality of data elements including encrypted sensitive values and unencrypted non-sensitive values, the encrypted sensitive values encrypted with a first session key on the user device; obtaining, by the server computer, a second session key; decrypting, by the server computer, the encrypted sensitive values with the second session key to obtain plaintext sensitive values; generating, by the server computer, an authorization request message comprising the plaintext sensitive values and the non-sensitive values; andtransmitting, by the server computer, the authorization request message to an authorizing entity computer for authorization.

[0010] These and other embodiments of the invention are described in further detail below.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 shows a diagram illustrating a system and an overlaid method according to an embodiment.

[0012] FIG. 2 shows a block diagram of a user device according to an embodiment.

[0013] FIG. 3 shows a block diagram of a server computer according to an embodiment.379505273V.1

[0014] FIG. 4 shows a diagram of a portable device according to an embodiment.

[0015] FIG. 5 shows a detailed diagram showing interactions between a portable device and a user device.DETAILED DESCRIPTION

[0016] Prior to discussing embodiments of the disclosure, some terms can be described in further detail.

[0017] A “resource provider” may be an entity that can provide a resource such as goods, services, information, and / or access. Examples of resource providers includes merchants, data providers, transit agencies, governmental entities, venue, and dwelling operators, etc. A “merchant” may typically be an entity that engages in transactions and can sell goods or services, or provide access to goods or services.

[0018] 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 operate an acquirer computer, which can also be generically referred to as a “transport computer.”

[0019] An “authorizing entity” may be an entity that authorizes a request.Examples of an authorizing entity may be an issuer, a governmental agency, a document repository, an access administrator, etc.

[0020] 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 user device, such as a cellular telephone, smart card, tablet, or laptop to the consumer.

[0021] A “credential” may be any suitable information that serves as reliable evidence of worth, ownership, identity, or authority. A credential may be a string of numbers, letters, or any other suitable characters, as well as any object or document that can serve as confirmation. Examples of credentials include value credentials,479505273V.1identification cards, certified documents, access cards, passcodes, and other login information, etc.

[0022] A “user device” may be any suitable device that a user can interact with (e.g., a payment card or mobile phone). User devices may be in any suitable form. Some examples of user devices include cards (e.g., payment cards such as credit, debit, or prepaid cards) with magnetic stripes or contactless elements (e.g., including contactless chips and antennas), cellular phones, PDAs, personal computers (PCs), tablet computers, and the like. In some embodiments, where a user device is a mobile device, the mobile device may include a display, a memory, a processor, a computer-readable medium, and any other suitable component.

[0023] A “processing network” may include data processing subsystems, networks, and operations. In embodiments of the invention, a processing network may be used to support and deliver authorization services, exception file services, and clearing and settlement services. A processing network may be a payment processing network able to transmit and receive financial system transaction messages (e.g., ISO 8583 messages), and process original credit and debit card transactions. An exemplary payment processing system may include VisaNet™. Payment processing systems such as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions.

[0024] A “portable device” may be a device that can be easily carried. A portable device may be a payment device which comprises a substrate such as a paper or plastic card, and information that is printed, embossed, encoded, or otherwise included at or near a surface of an object. A payment device may be associated with a value such as a monetary value, a discount, or store credit, and a payment device may be associated with an entity such as a bank, a merchant, a payment processing network, or a person. Suitable payment devices can be handheld and compact so that they can fit into a user's wallet and / or pocket (e.g., pocket-sized). Example payment devices may include smart cards, magnetic stripe cards, keychain devices (e.g., fobs), etc. Other examples of payment devices include payment cards, smart media, transponders, and the like. If the payment device is in the form of a debit, credit, or smartcard, the payment device may also optionally579505273V.1have features such as magnetic stripes. Such devices can operate in either a contact or contactless mode.

[0025] An “authorization request message” may be an electronic message that requests authorization for a transaction. In some embodiments, it is sent to a transaction processing computer 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 user 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 CW (card verification value), a dCW (dynamic card verification value), a PAN (primary account number or “account number”), a payment token, a username, 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, acquirer bank identification number (BIN), card acceptor ID, information identifying items being purchased, etc., as well as any other information that may be utilized in determining whether to identify and / or authorize a transaction.

[0026] An “authorization response message” may be a message that responds to an authorization request. In some cases, it may be an electronic message reply to an authorization request message generated by an issuing financial institution or a transaction processing computer. 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 transaction processing computer) to the679505273V.1merchant's access device (e.g., POS equipment) that indicates approval of the transaction. The code may serve as proof of authorization.

[0027] A “clearing and settlement process” may include a process of reconciling a transaction. A clearing process is a process of exchanging financial details between an acquirer and an issuer to facilitate posting to a party's account and reconciliation of the party's settlement position. Settlement involves the delivery of funds from one party to another.

[0028] A “server computer” may include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a web server. The server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. The server computer 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.

[0029] A “processor” may include a device that processes something. In some embodiments, a processor can 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 comprising 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, AMD Ryzen, AMD Threadripper, 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).

[0030] A “memory” may be any 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.779505273V.1

[0031] Embodiments of the invention relate to the selective encryption of sensitive data such as PH (personal identifiable information) data using a session key during an interaction between a portable device (e.g., a card) and a user device (e.g., a mobile phone, a POS terminal, etc.). The sensitive data such as PH data (e.g., a PAN or primary account number) from the portable device can be values in data elements that have a tag length value (TLV) format. The sensitive data can be encrypted by secure reader module on the user device using a session key. Nonsensitive data are not encrypted. The encrypted sensitive data and the plaintext nonsensitive data can be provided by the secure reader module to an acceptance application on the user device. The user device then sends, via the acceptance application, the encrypted sensitive data and the plaintext non-sensitive data to a server computer, which may be a gateway such as a payment gateway. The server computer can obtain (e.g., derive) a session key corresponding to the session key on the user device. The server computer can then decrypt the encrypted sensitive data to obtain plaintext sensitive data. The server computer can then generate an authorization request message with the plaintext sensitive data and the plaintext non-sensitive data. The server computer can then transmit the authorization request message to an authorizing entity computer for authorization.

[0032] More specifically, embodiments of the invention can include a secure reader module (e.g., a Secure EMV Card Reader Software (SEMVCRS)) in a user device such as a mobile phone. The user device can communicate with a portable device such as a card via NFC (near field communications). The secure reader module can parse responses with data elements in a TLV format from a portable device and selectively encrypt sensitive values that are identified by tags. The sensitive values may contain PH data (e.g., PAN, Track 2 Equivalent Data). The user device can encrypt the sensitive values using a user device derived session key. A data packet including TLV data elements including encrypted and non-encrypted values is then provided to an acceptance application such as an Acceptance / Kernel Application (AKAPP). The AKAPP can process the responses as per different payment networks’ kernel specifications using the unencrypted tags (e.g., PDOL, AIP, CDOL) without decrypting the encrypted tag values. The acceptance application then sends a transaction authorization request message including the data elements with both encrypted and unencrypted values to a server computer such as a879505273V.1payment gateway. The payment gateway derives the same session key, decrypts the encrypted values then processes the transaction authorization request message using the decrypted and unencrypted values.

[0033] FIG. 1 shows a system including a portable device 102 such as an EMV contactless card. The portable device 102 can communicate with a user device 104 (e.g., a mobile phone), which may comprise a contactless element including an antenna and a portable device reader 104A (e.g., an NFC chip reader), a secure reader module 104B such as a secure EMV card reader software or SEMVCRS, and an acceptance application 104C (e.g., an acceptance I kernal App or AKAPP), and a first or client-side session key derivation module 104D (e.g., a Device SKDM). The user device 104 can be an access device such as an acceptance device (e.g., a mobile PCS terminal), or it could be a personal device (e.g., a laptop computer) used by the user of the portable device 102. The system also includes a server computer 106, which may be a payment gateway, and a second or server-side session key derivation module 108 (or Server SKDM). The session key derivation module 108 may be on the server computer 106 or another computer. The server computer 106 may be in communication with a processing network 110 (e.g., a payment processing network). The processing network 110 can be in communication with an authorizing entity computer 112 such as an issuer computer. In some embodiments, a transport computer such as an acquirer computer (not shown) could be between the server computer 106 and the processing network 110.

[0034] Messages between the devices and the computers in the system 100 in FIG. 1 can be transmitted using a secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), SSL, ISO (e.g., ISO 8583) and / or the like. The communications network may include 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. The communications network can use any suitable communications protocol to generate one or more secure communication channels. A communications channel may, in some979505273V.1instances, comprise a secure communication channel, which may be established in any known manner, such as through the use of mutual authentication and a session key, and establishment of a Secure Socket Layer (SSL) session.

[0035] A method according to embodiments of the invention can be described with reference to FIG. 1. In some embodiments, the method can include generating, by a session key derivation module in a user device, a session key. The user device then transmits, to a portable device, a command message. The user device then receives, from the portable device, a response message comprising a plurality of data elements including sensitive values and non-sensitive values. The user device determines, by a secure reader module in the user device, the sensitive values in the data elements, and encrypts, by the secure reader module in the user device using the session key, the sensitive values to form encrypted sensitive values, without encrypting the non-sensitive values. The method also includes passing, by the secure reader module to an acceptance application in the user device, a data packet including the plurality of data elements including the encrypted sensitive values and the unencrypted non-sensitive values. The method further includes transmitting, by the user device via the acceptance application, the data packet to a server computer. The server computer can be programmed to obtain the session key and decrypt the encrypted sensitive values in the data packet using the session key to obtain plaintext sensitive values and process an interaction using the plurality of data elements including the unencrypted non-sensitive values and the plaintext sensitive values.

[0036] In step 1 , the second session key derivation module 108 injects a device master key to the first session key derivation module 104D. The second session key derivation module 108 also provides a list of tags (e.g., EMV tags) which are associated with PH data (e.g., ‘57’ Track 2 Equivalent Data, ‘5A’ Primary Account Number, ‘5F24’ Expiry Date’) to the first session key derivation module 104D. The injection can be performed when the user device 104 is manufactured, during the user device 104 initialization, or at any other time throughout the lifecycle of the user device 104. The injection can also be performed in a one time (fused) programming or reprogrammable manner. In other embodiments, the injection can be performed in wired or OTA (over-the-air) programming with key encryption and key MAC (message authentication code) verification. In some embodiments, the device master 1079505273V.1key can be rotated throughout the user device 104 device lifecycle, after a time period, or after a certain number of usage times. Still further, the tag list (e.g., an EMV tag list) can be updated throughout user device’s lifecycle.

[0037] In step 2, the acceptance application 104C starts a communication session with the secure reader module 104B in an interaction such as a transaction.

[0038] In step 3, the secure reader module 104B calls the first session key derivation module 104D to generate a new session key. The secure reader module 104B then receives from the first session key derivation module 104D, the session key and session data. The session data can include, for example, a session identifier, a user device identifier, a nonce, etc.). The first session key derivation module 104D can generate the session data, and can derive the session key using the injected device master key. The session key can also be derived from the session data. In one example, the session data can be concatenated and can be encrypted with the master key to derive the session key. The first session key derivation module 104D can securely store the session key securely in a memory and delete it after the session is closed.

[0039] In step 4, the secure reader module 104B in the user device 104 then triggers the portable device reader 104A to detect the portable device 102. The user device 104 and the portable device reader 104A can communicate via a wireless protocol such as NFC (near field communications, Bluetooth, etc.).

[0040] In step 5, the portable device 102 is detected by portable device reader 104A in the user device 104, and communication is established between them. In some embodiments, a portable device handle (e.g., a card handle) can be sent by the portable device 102 to the secure reader module 104B via the portable device reader 104A. The portable device handle can be a portable device type (e.g., processing network A type, processing network B type, etc.). The portable device handle can be used by the acceptance application 104C to determine what protocol to use to communicate with the portable device 102.

[0041] In step 6, the secure reader module 104B returns the portable device handle to the acceptance application 104C.1179505273V.1

[0042] In step 7, the acceptance application 104C can determine an appropriate protocol with the portable device handle. The acceptance application 104C then sends a command such as EMV APDll command to the secure reader module 104B consistent with the portable device handle.

[0043] In step 8, the secure reader module 104B sends the command (e.g., the EMV APDll command) to the portable device reader 104A.

[0044] In step 9, the portable device reader 104A sends the command (e.g., the EMV APDll command) to the portable device 102. In response, the portable device 102 sends a response message to the portable device reader 104A in the user device 104. The portable device reader 104A then receives the response message from the portable device. In some embodiments, the response message can be an EMV APDU response. The response message can include a plurality of data elements including sensitive and non-sensitive values.

[0045] In step 10, the portable device reader 104A sends the response message (e.g., the EMV APDU response) to the secure reader module 104B. The secure reader module 104B then performs a selective “encryption by tag” operation. The secure reader module 104B performs TLV (tag length value) parsing on the received response message (e.g., the EMV APDU response). The secure reader module 104B determines the tags in the response message and compares them against the injected list of tags obtained from the second session key derivation module 108 in step 1 to determine one or more tags in the response message (e.g., the EMV APDU response) which are associated with sensitive data such as PH data. If one or more tags associated with sensitive data (e.g., PH data) is / are found, then the secure reader module 104B encrypts the tag value(s) associated with those tags using the first session key, which may be obtained from the first session key derivation module 104D.

[0046] The encryption algorithm used to encrypt the sensitive data can be a stream cipher (e.g., Chacha20, RC4, ANSI X9.124-2) so that the plaintext and encrypted values have the same length without changing the TLV structure in the response message (e.g., the EMV APDU response). The following encrypted tag value in the same or following EMV APDU response, can resume in the stream cipher from previous encrypted tag value. In case of multiple encrypted tag values, the order of1279505273V.1the tag values feeds into the stream cipher and is maintained in the encrypted tag list in the session data. If the plaintext has checksum value (e.g., Luhn value) as in a PAN or primary account number, a new checksum value can be regenerated after encryption.

[0047] In step 11 , the secure reader module 104B sends the response message (e.g., the EMV APDll response) to the acceptance application 104C. The response message includes both tags and values associated with the plaintext tag values (e.g., non-sensitive) and encrypted tag values (e.g., sensitive). An example of a plaintext tag values that are non-sensitive may include Application File Locator (AFL). An example of an encrypted tag value may be a Primary Account Number (PAN). The acceptance application 104C analyzes the plaintext tags and the status word, determines the next command (e.g., an APDll command) if applicable, and then repeats steps 7-11. If the acceptance application 104C determines that the last response message (e.g., an EMV APDll response) is received, then it ends the communication session with the secure reader module 104B. At the end of the session, the secure reader module 104B returns the session data (session identifier, nonce, encrypted tag list sequence) to the acceptance application 104C.

[0048] In step 12, the acceptance application 104C sends a data packet including the plurality of data elements including the encrypted sensitive values and the unencrypted non-sensitive values to the server computer 106 together with the session data from the first session key derivation module 104D (from step 3).

[0049] In step 13, the server computer 106 processes the received data packet. If session data is found in the data packet, the server computer 106 calls the second session key derivation module 108 with the session data. The second session key derivation module 108 derives a second session key using same device master key identifiable by session data, and the session data. The second session key can be the same value as the first session key derived by the first session key derivation module 104D. The second session key derivation module 108 then sends the second session key to the server computer 106. The server computer 106 scans for tags in the data packet to identify tag(s) that have tag values which contain sensitive data (e.g., PH data) that is encrypted. The server computer 106 decrypts the encrypted values of the1379505273V.1encrypted tag elements. If the plaintext data uses a checksum (e.g., Luhn), a new checksum can be generated after decryption of the encrypted values.

[0050] In step 14, the server computer 106 can generate an authorization request message with the plurality of data elements including the unencrypted nonsensitive values and the plaintext sensitive values. The server computer 106 can then transmit the authorization request message to the authorizing entity computer 112 via the processing network 110 for authorization processing.

[0051] In some embodiments, a zone key encryption scheme can protect the sensitive values as they are passed in the authorization request message from the server computer 106 to the authorizing entity computer 112. One zone encryption key can be used to secure communications between the server computer 106 and the processing network 110. Another encryption key can be used to secure communications between the processing network 10 and the authorizing entity computer 112.

[0052] After the authorizing entity computer 112 receives the authorization request message, it can authorize or not authorize the authorization request message. It can then generate an authorization response message with an authorization indicator. The authorization entity computer 112 can then transmit the authorization response message back to the server computer via the processing network 110.

[0053] At the end of the day or any other suitable period of time, a clearing and settlement process can occur between at least the authorizing entity computer 112, the processing network 110, and an entity associated with a transport computer (e.g., an acquirer).

[0054] Table 1 below compares example APDll commands and responses in a situation where data are unencrypted and when data are encrypted using embodiments of the invention. The bolded and italicized values can be encrypted values or plaintext tags with associated encrypted values.1479505273V.11579505273V.1

[0055] The implementation options of the secure reader module 104B and the session key derivation module 104D can include (1) firmware in the portable device reader 104A (e.g., an NFC chip reader), (2) a secure element chip connected to portable device reader 104A, (3) a Trusted Execution Environment, (4) a device operating system, (5) a service, or (6) a stand-alone application.

[0056] The advantages of implementing secure reader module 104B include the following: (1) the acceptance application 104C does not handle sensitive data such as PH data from the portable device 102 (e.g., an EMV contactless card). This eliminates the risk of a sensitive data (e.g., payment data) breach on the user device 104; (2) it limits the PCI scope to the secure reader module 104B and the first session key derivation module 104D, and moves the acceptance application 104C out of PCI (payment card industry) scope, thereby reducing development and operation efforts; and (3) it is transparent to existing protocols, software and systems, such as EMV protocols, software and systems.

[0057] FIG. 2 is a block diagram illustrating an example user device 200. The user device 200 can be a mobile device (e.g., mobile phone) with an acceptance application 204. The user device 200 may include device hardware 208 coupled to a system memory 202.

[0058] Device hardware 208 may include a processor 210, input elements 212, a short range antenna 214, a user interface 216, output elements 218, and a long range antenna 220. Examples of input elements may include microphones, keypads, touchscreens, sensors, etc. Examples of output elements may include speakers, display screens, and tactile devices. The processor 210 can be implemented as one or more integrated circuits (e.g., one or more single core or multicore microprocessors and / or microcontrollers), and is used to control the operation of the user device 200. The processor 210 can execute a variety of programs in response to program code or computer-readable code stored in the system memory 202, and can maintain multiple concurrently executing programs or processes.

[0059] The long range antenna 220 may include one or more RF transceivers and / or connectors that can be used by user device 200 to communicate with other devices and / or to connect with external networks. The input and output elements1679505273V.1212, 208 allow a user to interact with and invoke the functionalities of first user device 200. The short range antenna 214 may be configured to communicate with external devices through a short range communication medium (e.g., using Bluetooth, Wi-Fi, infrared, NFC, etc.). The long range antenna 220 may be configured to communicate with a remote base station and a remote cellular or data network, over the air.

[0060] The system memory 202 can be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g., DRAM, SRAM), or any other non-transitory storage medium, or a combination thereof media. The system memory 202 may store an acceptance application 204A, a session key derivation module 202B, and a secure reader module 202C.

[0061] The system memory 202 can include a non-transitory computer readable medium. The non-transitory computer readable medium comprising code, executable by the processor for performing a method comprising: generating, by a session key derivation module in the user device, a session key; transmitting, by the user device to a portable device, a command message; receiving, by the user device from the portable device, a response message comprising a plurality of data elements including sensitive values and non-sensitive values; determining, by a secure reader module in the user device, the sensitive values in the data elements; encrypting, by the secure reader module in the user device using the session key, the encrypted values to form encrypted sensitive values, without encrypting the nonsensitive values; passing, by the secure reader module to an acceptance application in the user device, a data packet including the plurality of data elements including the encrypted sensitive values and the unencrypted non-sensitive values; and transmitting, by the user device via the acceptance application, the data packet to a server computer, wherein the server computer is programmed to obtain the session key and decrypt the encrypted sensitive values in the data packet using the session key to obtain plaintext sensitive values and process an interaction using the plurality of data elements including the unencrypted non-sensitive values and the plaintext sensitive values

[0062] FIG. 3 shows a block diagram of a processing network computer 300 according to embodiments. The exemplary processing network computer 300 may1779505273V.1comprise a processor 304. The processor 304 may be coupled to a memory 302, a network interface 306, and a computer readable medium 308. The computer readable medium 308 can comprise a session key derivation module 308A, an authorization processing module 308B, and a post authorization processing module 308C.

[0063] The computer readable medium 308 may comprise code, executable by the processor 304, for performing a method comprising: receiving, by a server computer from a user device, a data packet including a plurality of data elements including encrypted sensitive values and unencrypted non-sensitive values, the encrypted sensitive values encrypted with a first session key on the user device; obtaining, by the server computer, a second session key; decrypting, by the server computer, the encrypted sensitive values with the second session key to obtain plaintext sensitive values; generating, by the server computer, an authorization request message comprising the plaintext sensitive values and the non-sensitive values; andtransmitting, by the server computer, the authorization request message to an authorizing entity computer for authorization.

[0064] The session key derivation module 308A may comprise code or software, executable by the processor 304, for deriving session keys or session data as described above.

[0065] The authorization processing module 308B in conjunction with the processor 304, can perform authorization processing.

[0066] The post authorization processing module 308C, in conjunction with the processor 304, can perform post authorization processing such as clearing and settlement processing.

[0067] The network interface 306 may be any suitable combination of hardware and software that enables data to be transferred. Some examples of the network interface 306 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, a wireless communication interface, and / or the like.1879505273V.1

[0068] FIG. 4 shows an example portable device 400 in the form of a card. The portable device 400 comprises a substrate 400A such as a plastic substrate. A contactless element interface 400B for interfacing with a data access or data transfer device may be on or embedded within the substrate 400A. The contactless element interface 400B may include a chip and may include the capability to communicate and transfer data using near field communications (NFC) technology or other short range communications technology. The portable device 400 may be issued to a user by an authorizing entity.

[0069] The portable device 400 may also include a memory 400C, which may store user information such as an account number, expiration date, and a user name. Information in the memory 400C can be transmitted by the portable device 400 to another device such as a user device using the contactless element interface 400B. Information may also be printed or embossed on the substrate 400A. The substrate 400A may also have a magnetic stripe 400D on it.

[0070] FIG. 5 shows a flow diagram of interaction processing between an access device and a user device according to embodiments. In embodiments, a user may obtain a portable device 102 as described above and use it to interact with a user device 104 as described above. The user of the portable device 102 may wish to obtain a resource (e.g., a good or service) offered by a merchant operating the user device 104. The commands (e.g., from the user device 104) to the portable device 102) and responses (e.g., from the portable device 102 to the user device 104) described above with respect to FIG. 1 can be incorporated in the message flow in FIG. 5.

[0071] At step 501 , a contactless reader of the user device 104 may be configured to identify the presence of a portable device 102 within communication range. For example, a contactless interface of the portable device 102 may ping or otherwise attempt to find suitable devices to communicate with periodically. When the user device 104 detects the presence of portable device 102 in proximity to a contactless reader of the user device 104, for example, an application selection module of the user device 104 may initiate an interaction (e.g., a transaction) by sending a request for available account applets to the portable device 102. The request for available applets is sent in order to obtain information regarding which1979505273V.1mobile applications and corresponding account applets (e.g., a list of account applet identifiers) may be available on the portable device 102. In some embodiments, the request for available applets 201 may be in the form of a “select proximity payment system environment (PPSE)” command. In such embodiments, the request for available applets 201 may include a payment environment identifier (e.g., a PPSE name such as “2PAY.SYS.DDF01”) to identify the payment environment supported by the user device 104.

[0072] At step 502, upon receiving the available applications request 501 , the portable device 102 may identify and process the request by recognizing the payment environment identifier (e.g., PPSE name) included in the request, and respond by sending an available applications response 502 back to user device 104. For example, the available applications response 502 may include a list of available account applet identifiers (AIDs), a wallet identifier associated with a mobile application, application configuration options associated with the available AIDs, and / or may include the proximity payment environment identifier (e.g., PPSE name) as the dedicated file name.

[0073] In some embodiments, the available applications response 502 may be in the form of a “select PPSE” response and may include PPSE file control information (FCI). For example, the available applications response 502 may include a directory entry for each available AID on the portable device 102 with a wallet identifier associated with each available AID. Each directory entry may include information such as the AID, an application label associated with the AID (e.g., a mnemonic associated with the AID), a wallet identifier (WID) associated with the mobile application, an application priority indicator indicating the priority of the AID, a kernel identifier indicating the application's kernel preference, and / or additional information relating to the particular AID. The available applications response 502 may also include other data such as FCI issuer discretionary data or any other relevant information.

[0074] At step 503, the user device 104 may determine a supported account applet based on the received available applet identifiers and may send an “application selection” command 503 including the selected AID to the portable device 102.2079505273V.1

[0075] Additionally, in some embodiments, upon receiving the application selection message 503, at step 504, the portable device 102 may send a terminal transaction data request 504 to request transaction data from user device 104 which may be needed to execute the transaction using the selected application associated with the selected AID. In some embodiments, the terminal transaction data request 504 may be in the form of a “Select AID Response” and may include applet identifier (AID) file control information (FCI) with the selected AID as the dedicated file name. The terminal transaction data request may include a list of transaction data identifiers to request the appropriate data from the user device 104, and the list of transaction data identifiers can be in the form of a processing options data object list (PDOL).

[0076] The transaction data requested by, for example, the mobile application for the transaction may include an entity identifier associated with the user device 104 (e.g., a merchant identifier (MID)), terminal processing options (TPO), authorized amount, other amount, terminal country code, terminal verification results, transaction currency code, transaction data, transaction type, and / or an unpredictable number. The terminal transaction data request may also include other data such as FCI issuer discretionary data, application program identifier, and language preference. In other embodiments, the transaction information may be provided as part of the application selection message 503 and / or as part of the available applications request message 201.

[0077] At step 505, after receiving the terminal transaction data request 504, the user device 104 may send to the portable device 102, the terminal transaction data in 505 requested by the mobile application. In some embodiments, the terminal transaction data in 505 may be sent in the form of a get processing options (GPO) command, and may include the requested terminal transaction data in 505 in a processing options data object list (PDOL). In some embodiments, the terminal transaction data in 505 (e.g., Transaction Processing Options (TPO)) may include a TPO indicator that indicates which transaction data types the user device 104 supports.

[0078] At step 506, once the selected applet of the portable device 102 receives the terminal transaction data in 505, the portable device 102 obtains the relevant account credentials from the selected applet as well as any other relevant2179505273V.1payment information and may send a set of transaction processing information in 506 including the account credentials and any other relevant transaction processing information to the user device 104. In some embodiments, the transaction processing information in 506 can be sent in the form of a “get processing options” (GPO) response. In some embodiments, the transaction processing information may include one or more application file locators (AFLs) that can be used as file addresses by user device 104 to read account data stored on the portable device 102, and an application interchange profile (AIP) that can be used to indicate the capabilities of the payment application.

[0079] For example, the transaction processing information may include any credentials for the transaction including a transaction cryptogram generated using transaction information, Track-2 equivalent data, and additional data. The transaction processing information may include issuer application data (IAD), a form factor indicator (FFI), card transaction qualifiers (CTQ), cryptogram information data (CID), an application transaction counter (ATC), and / or an application PAN sequence number (PSN). In some embodiments, the issuer application data (IAD) may include a length indicator indicating the length of the IAD, cryptogram version number (CVN) indicating the version of the transaction cryptogram, a derived key indicator (DKI) that can be used to identify a master key (e.g. a master key associated with the issuer), and / or card verification results (CVR).

[0080] It should be understood that in some embodiments, the transaction processing information in 506 being sent from portable device 102 to user device 104 may include some or all of the information described above, and in some embodiments, may include additional information not specifically described.

[0081] At step 507, after the user device 104 receives the transaction processing information in 506, the user device 104 may send an account data request 507 to the portable device 102 to read additional account data in 508 that may be stored on the portable device 102. In some embodiments, the account data request 507 may be in the form of a “read record” command, and may include an application file locator (AFL) indicating the location of the account data that user device 104 is attempting to read. The AFL included in the account data request 5072279505273V.1may correspond to an AFL in the transaction processing information in 506 that was provided to user device 104 from portable device 102.

[0082] At step 508, in response to receiving the account data request 507 from the user device 104, the portable device 102 may send the account data in 508 stored at the location indicated by the AFL to user device 104. In some embodiments, the account data in 508 may be sent in the form of a “read record” response. The account data 508 may include, for example, application usage control that indicates the issuer's restrictions on the usage and services allowed for the application, the cardholder's name, customer exclusive data, issuer country code, and / or other account related data that is accessible at the AFL location and is stored in the portable device 102.

[0083] It should be understood that in some embodiments, the account data in 508 being sent from portable device 102 to user device 104 may include some or all of the information describe above, and in some embodiments, may include additional information not specifically described. Further, any and all of this information may be provided in response to receiving a selection message and / or obtaining payment credentials.

[0084] In some embodiments, after 508, the user device 104 can generate an authorization request message and then provide the authorization request message to a resource provider computer associated with the user device 104. The resource provider computer can provide the authorization request message to a transport computer that can provide the authorization request message to a network processing computer. The network processing computer can provide the authorization request message to an authorizing entity computer. The authorizing entity computer can determine whether or not to authorize the interaction between, for example, the user of the portable device 102 and a resource provider of the resource provider computer associated with the user device 104. The authorizing entity computer can generate an authorization response message comprising an indication of whether or not the interaction is authorized.

[0085] The authorizing entity computer can provide the authorization response message to the resource provider computer via the network processing computer and the transport computer. In some embodiments, the resource provider computer2379505273V.1can provide the authorization response message to the access device which can provide the user device with the indication of whether or not the interaction is authorized. In other embodiments, the resource provider computer can provide the indication of whether or not the interaction is authorized to the user of the user device and / or the portable device 102 itself.

[0086] At the end of the day or any other suitable period of time, a clearing and / or settlement process between the relevant parties can take place.

[0087] Although the steps in the flowcharts and process flows described above are illustrated or described in a specific order, it is understood that embodiments of the invention may include methods that have the steps in different orders. In addition, steps may be omitted or added and may still be within embodiments of the invention.

[0088] 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, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium for storage and / or transmission, suitable media include random access memory (RAM), 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.

[0089] 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 within2479505273V.1different 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.

[0090] 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.

[0091] 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.

[0092] As used herein, the use of "a," "an," or "the" is intended to mean "at least one," unless specifically indicated to the contrary.2579505273V.1

Claims

WHAT IS CLAIMED IS:

1. A method comprising:generating, by a session key derivation module in a user device, a session key;transmitting, by the user device to a portable device, a command message;receiving, by the user device from the portable device, a response message comprising a plurality of data elements including sensitive values and nonsensitive values;determining, by a secure reader module in the user device, the sensitive values in the data elements;encrypting, by the secure reader module in the user device using the session key, the sensitive values to form encrypted sensitive values, without encrypting the non-sensitive values;passing, by the secure reader module to an acceptance application in the user device, a data packet including the plurality of data elements including the encrypted sensitive values and the unencrypted non-sensitive values; and transmitting, by the user device via the acceptance application, the data packet to a server computer, wherein the server computer is programmed to obtain the session key and decrypt the encrypted sensitive values in the data packet using the session key to obtain plaintext sensitive values and process an interaction using the plurality of data elements including the unencrypted non-sensitive values and the plaintext sensitive values.

2. The method of claim 1 , wherein each of the data elements being in a tag-length-value format and comprising a tag, a length, and a value, the value being a sensitive value or a non-sensitive value.

3. The method of claim 2, wherein determining the sensitive values comprises determining the sensitive values using the tags in the data elements.

4. The method of claim 1 , wherein the portable device is a card and the user device is a mobile phone.2679505273V.

15. The method of claim 1 , wherein the portable device and the user device communicate using NFC (near field communications).

6. The method of claim 1 , further comprising:deleting, by the session key derivation module, the session key after passing the data packet to the acceptance application in the user device.

7. The method of claim 1 , wherein the session key derivation module is a first session key derivation module, and wherein the server computer also derives the session key using a second session key derivation module.

8. The method of claim 1 , wherein the session key is derived from a device master key.

9. The method of claim 1 , wherein the sensitive values include PH (personal identifiable information) information.

10. The method of claim 1 , wherein the encryption of the sensitive values includes using an encryption algorithm, the encryption algorithm comprising a stream cipher.

11. The method of claim 1 , wherein the sensitive data comprises access data, the access data comprising a credential or a token.

12. The method of claim 1 , wherein the server computer is further programmed to generate an authorization request message comprising the plaintext sensitive values and transmit the authorization request message to an authorizing entity computer for authorization.

13. The method of claim 1 , The method of claim 1 , wherein the session key is derived from a device master key which was provisioned to the user device by the server computer.

14. A user device comprising:2779505273V.1a processor; anda non-transitory computer readable medium coupled to the processor, the non-transitory computer readable medium comprising code, executable by the processor for performing a method comprising:generating, by a session key derivation module in the user device, a session key;transmitting, by the user device to a portable device, a command message;receiving, by the user device from the portable device, a response message comprising a plurality of data elements including sensitive values and nonsensitive values;determining, by a secure reader module in the user device, the sensitive values in the data elements;encrypting, by the secure reader module in the user device using the session key, the encrypted values to form encrypted sensitive values, without encrypting the non-sensitive values;passing, by the secure reader module to an acceptance application in the user device, a data packet including the plurality of data elements including the encrypted sensitive values and the unencrypted non-sensitive values; and transmitting, by the user device via the acceptance application, the data packet to a server computer, wherein the server computer is programmed to obtain the session key and decrypt the encrypted sensitive values in the data packet using the session key to obtain plaintext sensitive values and process an interaction using the plurality of data elements including the unencrypted non-sensitive values and the plaintext sensitive values.

15. The user device of claim 14, wherein the user device is a mobile phone.

16. The user device of claim 14, further comprising a portable device reader coupled to the processor.2879505273V.

117. The user device of claim 14, further comprising a portable device reader coupled to the processor, the portable device reader being an NFC (near field communications) chip reader.

18. The user device of claim 14, wherein each of the data elements being in a tag-length-value format and comprising a tag, a length, and a value, the value being a sensitive value or a non-sensitive value.

19. The user device of claim 18, wherein in the method, determining the sensitive values comprises determining the sensitive values using the tags.

20. A method comprising:receiving, by a server computer from a user device, a data packet including a plurality of data elements including encrypted sensitive values and unencrypted non-sensitive values, the encrypted sensitive values encrypted with a first session key on the user device;obtaining, by the server computer, a second session key; decrypting, by the server computer, the encrypted sensitive values with the second session key to obtain plaintext sensitive values;generating, by the server computer, an authorization request message comprising the plaintext sensitive values and the non-sensitive values; and transmitting, by the server computer, the authorization request message to an authorizing entity computer for authorization.2979505273V.1

Images