Patent Description:
The information sent by a smart card can include sensitive data such as a user's account identifier (e.g., a personal account number). As a result, security measures are needed to protect the user from sophisticated fraudsters who may intercept this information. Current techniques may be problematic because the entire account identifier is unencrypted. In other conventional techniques, the account identifier may be encrypted but is still transmitted and/or provided according to a known protocol having known data fields. An intelligent fraudster may still easily identify the encrypted data field within a message and are thus, more likely to be able to utilize the information for their nefarious acts. Additionally, using conventional techniques, the account identifier may remain static, potentially allowing a fraudster to track a user's transactions.

Still further, conventional system do not restrict usage of sensitive information. For example, a fraudster, once having obtained sensitive information may utilize the sensitive information in a variety of contexts.

<CIT> discloses methods for verifying tokens using limited-use certificates.

<CIT> discloses a method including generating an obfuscated portion using a dynamic cryptogram unique to a transaction, where the dynamic cryptogram is determined using a uniquely derived key.

Embodiments of the invention address these and other problems, individually and collectively.

According to a first aspect of the present invention, there is provided a computer-implemented method according to appended claim <NUM>. According to a second aspect of the present invention, there is provided a user device according to appended claim <NUM>. According to a third aspect of the present invention, there is provided a system according to appended claim <NUM>.

Embodiments of the present invention are directed to methods, systems, devices, and computer readable media that can be used to securely communicate an account identifier (e.g., a PAN) associated with a user device such as a contactless smart card. In some embodiments, a user device may store a primary account number (PAN) and a secondary account number (SAN). An account identifier (e.g., the PAN) may be communicated in a manner that does not allow the account identifier to be tracked for privacy protection. Advantageously, in embodiments of the invention, account information is communicated in a manner that is secure and that does not require updating the existing payment infrastructure in any significant way.

An additional account identifier (e.g., the SAN) may be utilized in embodiments discussed herein in contexts in which a static identifier is needed. By way of example, some types of access devices are expected to allow or deny access to a resource by the user in near real time. Accordingly, such access devices may utilize a static identifier to check against an allow list and/or a block list in order to quickly allow or reject access to a user of the smart card. The additional account identifier (e.g., the SAN) may be utilized only in certain situations. For example, the system may ensure that a SAN is only usable in transactions involving a terminal and/or merchant and/or transaction of a particular type. As a non-limiting example, the system may be configured to ensure that a SAN may only be utilized in a transaction involving a transit terminal (e.g., a turnstile of a transit authority).

One embodiment of the invention is directed to a method comprising, receiving, by a user device from an access device, a first message comprising a terminal type indicator. The method may further comprise, in response to the terminal type indicator indicating a first terminal type, transmitting, from the user device to the access device, a request message comprising a first identifier (e.g., a SAN) and an encrypted identifier (e.g., an encrypted identifier generated from a PAN and a transaction counter). The method may further comprise, in response to the terminal type indicator indicating a second terminal type, generating, by the user device, an obfuscated identifier based at least in part on a first portion of a second identifier (e.g., a primary PAN) and a second portion of the encrypted identifier. The method may further comprise transmitting, from the user device to the access device. In some embodiments, the request message may comprise the obfuscated identifier and the encrypted identifier.

Another embodiment of the invention is directed to a user device comprising one or more processors, and one or more memories comprising computer-executable instructions that, when executed by the one or more processors causes the user device to perform operations. The operations may comprise receiving, by a user device from an access device, a first message comprising a terminal type indicator. The operations may further comprise, in response to the terminal type indicator indicating a first terminal type, transmitting, from the user device to the access device, a request message comprising a first identifier (e.g., a SAN) and an encrypted identifier (e.g., an encrypted identifier generated from a primary PAN and a transaction counter). The operations may further comprise, in response to the terminal type indicator indicating a second terminal type, generating, by the user device, an obfuscated identifier based at least in part on a first portion of a second identifier (e.g., a primary PAN) and a second portion of the encrypted identifier. The operations may further comprise transmitting, from the user device to the access device. In some embodiments, the request message may comprise the obfuscated identifier and the encrypted identifier.

Another embodiment of the invention is directed to a (non-transitory) computer readable medium. The computer readable medium comprises code for performing the methods discussed herein. In some embodiments, a user device such as a smart card may comprise this computer-readable medium.

These and other embodiments of the invention are described in further detail below, with reference to the figures.

As described above, in a convention payment transaction, an account identifier (e.g., a personal account identifier, also referred to as a primary PAN) is not encrypted when it passes from a user device such as a contactless smart card to an access device (e.g., a POS terminal, a turnstile reader, etc.) and eventually through the traditional payment processing network. In some conventional techniques, the account identifier may be encrypted and/or obfuscated, however the encrypted/obfuscated data may still be provided in a traditional data field of a transaction message and thus, the data field is readily identifiable to potential fraudsters.

While encryption of the entire account identifier is possible, it may not be practical under all circumstances. If the account identifier is encrypted, a conventional transaction processing system may not be able to successfully process the transaction. For example, a typical account identifier includes a bank identification number (BIN). The BIN is used to route an authorization request message to the proper issuer or payment processor. If the account identifier is encrypted, then the BIN will change. If the BIN changes, then a proper authorization request message cannot be routed to the correct issuer.

Another restriction associated with encrypting the entire account identifier is related to an error check that is associated with the sequence of digits in an account identifier. Error checking may be achieved using a checksum algorithm that determines if the digits of the account identifier are in the proper sequence. An example checksum algorithm is a modulo <NUM> algorithm (which is also known as a "Luhn check").

Therefore, encryption of an entire account identifier would corrupt at least the BIN, the checksum, and the ability to identify an account identifier via printed digits on a receipt.

The processes described herein can be used to protect the account identifier at the initiating device (e.g., the smart card). As will be illustrated in further detail below, embodiments of the invention obfuscate only a portion of an account identifier, which allows the BIN the account to remain unencrypted and the Luhn check to continue to be utilized. In addition, embodiments of the invention can also be used not only obfuscate an account identifier within a typical authorization request message, but also to ensure that the entire encrypted account identifier is provided elsewhere in the message so as to make it less likely to be identifiable.

The techniques discussed herein also enable the obfuscated identifier or a SAN to be utilized by the user device depending on the context of the transaction (e.g., what type of terminal is requesting the information). Accordingly, for transactions being associated with a first set of transaction types, terminal types, etc., the obfuscated PAN may be utilized in the transaction while the SAN may be utilized for transactions associated with a second set of transaction types, terminal types, etc. The SAN may be restricted to only be processed by an authorizing entity when utilized in the allowable contexts. For the first set of transaction/terminal type transactions, the obfuscated PAN may be utilized such that the user's activities may not be tracked. These techniques enable a static identifier to be utilized for offline transactions (e.g., transactions in which a terminal authenticates the smart card at the terminal) and subsequent online transactions stemming from the offline transaction, while a dynamic identifier (e.g., a dynamic value) may be utilized for online authentication transactions for which no counterpart offline authentication is needed.

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

A "computing device" (also referred to as a "user device") may be any suitable device that can perform computations, and that can communicate with other devices. A portable consumer device such as a smart card is an example of a computing device. Other types of computing devices may not be portable.

A "dynamic value" is intended to refer to a value that changes dynamically. The computing device can maintain various dynamic values. An example of a dynamic value is an application transaction counter (ATC). The ATC may initially be set by the issuer of the computing device (e.g., an authorizing entity) to a predetermined value. Thereafter, the ATC may be incremented with each transaction. Alternately, the ATC may be decremented from its initial predetermined value with each transaction. The ATC may be a value of any length. In addition, the issuer may maintain a corresponding ATC accessible to the issuer's computer. This corresponding ATC may be used to identify payment services which may have been replayed for fraudulent purposes. In an alternate embodiment, a cryptogram, digital signature, or hash value based on transaction data may be used in place of or in conjunction with the ATC stored at the computing device.

Examples of other dynamic values (e.g., data elements) may include a time of day, a current transaction amount, and a randomly generated number from a terminal, etc. The data elements are dynamic in the sense that they can change with each transaction or nearly each transaction. The dynamic data elements may relate to a user's computing device and/or may relate to the user generally.

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. 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. An "authorizing entity computer" may be operated by, or on behalf of, an authorizing entity.

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.

A "resource provider" may be an entity that can provide a resource such as goods, services, information, and/or access. Examples of a resource provider includes merchants, access devices, secure data access points, 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. A "resource provider computer" may be any suitable computing device that may be operated by, or on behalf of, a resource provider.

A "processing network computer" (also referred to as a central server computer) may include a server computer used for processing network data. In some embodiments, the processing network 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 processing network 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. In some embodiments, the processing network computer may operate multiple server computers. In such embodiments, each server computer may be configured to process transaction for a given region or handles transactions of a specific type based on transaction data.

The processing network computer may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary processing network computer may include VisaNet™. Networks that include VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, includes an integrated payments system (Integrated Payments system) which processes authorization requests and a Base II system, which performs clearing and settlement services. The processing network computer may use any suitable wired or wireless network, including the Internet.

An "authorization request message" may be an electronic message that is sent to a transaction processing computer and/or an authorizing entity computer (e.g., issuer of a payment card) to request authorization for a transaction. An authorization request message according to some embodiments may comply with ISO <NUM>, 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 dCVV (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.

An "authorization response message" may be an electronic message reply to an authorization request message generated by an authorizing entity computer or a transaction processing computer. The authorization response message may include, by way of example only, one or more of the following status indicators: Approvaltransaction was approved; Decline -- transaction was not approved; or Call Centerresponse 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 an authorizing entity (e.g., an issuer bank) returns in response to an authorization request message in an electronic message (either directly or through the transaction processing computer) to a resource provider computer that indicates approval of the transaction. The code may serve as proof of authorization. In some embodiments, a transaction processing computer may generate or forward the authorization response message to the resource provider.

A "primary account number" (PAN) may be an identifier for a payment account. A PAN may include a series of alphanumeric characters (e.g., <NUM>). A PAN (or an obfuscated or encrypted version of the PAN) may be used to initiate, authorize, settle or resolve a payment transaction. In some embodiments, a PAN may be utilized for any type of transaction.

A "- account number" (SAN) may be another identifier for a payment account. A SAN may include a series of alphanumeric characters (e.g., <NUM>). A SAN (or an obfuscated or encrypted version of the PAN) may be used to initiate, authorize, settle or resolve a transaction. In some embodiments, use of a SAN may be restricted to certain types of transactions. For example, a SAN may be utilized when the transaction includes a merchant of a particular type (e.g., a transit authority, a transit merchant, a sports stadium merchant, etc.), when the transaction is initiated by a terminal of a particular terminal type (e.g., a turnstile, etc.), and/or when the transaction is a particular type of transaction (e.g., a transit transaction, a fare checking transaction, etc.). In some embodiments, the SAN may be associated with a PAN and both may be associated with a particular user's account (e.g., a financial account maintained by an issuer on behalf of the user). In some embodiments, a PAN and the associated SAN each may include the same <NUM> left-most digits (e.g., corresponding to a bank identifier number (BIN)).

An "obfuscated identifier" may include an identifier that is an obfuscated version of an identifier (e.g., a <NUM> digit PAN). In some embodiments, an obfuscated identifier may be "format preserving" and may have a numeric format that conforms to the account identifiers used in existing transaction processing networks (e.g., ISO <NUM> financial transaction message format). In some embodiments, an obfuscated identifier may be used in place of a PAN to initiate, authorize, settle or resolve a payment transaction or represent the original credential in other systems where the original credential would typically be provided.

An "encrypted identifier" may include any suitable encrypted value. An encrypted value may be generated from an identifier (e.g., a primary PAN) utilizing any suitable encryption techniques utilizing, for example, symmetric and/or asymmetric encryption techniques. In some embodiments, an encrypted identifier may be generated utilizing a primary PAN and a dynamic value, both stored at a user device.

For purposes of this application, "payment data" can include, with respect to financial applications those data elements used by the payment service to execute a transaction, and with respect to non-financial transactions any necessary data elements exclusive of the present invention. For example, when the payment service is a magnetic stripe credit card transaction, "payment data" would comprise Track <NUM> and/or Track <NUM> data, as that is understood by one of ordinary skill in the credit card industry, such as the primary account number, expiration date, service codes, and discretionary data. "Payment data" may also comprise a unique card identification number or a unique identification number for a service provider. The payment data may reside in a memory located on the user device (e.g., a credit and/or debit card, a smart card, etc.).

A "server computer" is typically 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.

A "processor" may refer to 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 CPU 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).

<FIG> shows a block diagram of a system <NUM> for processing a transaction, according to some embodiments. The system <NUM> may be used to facilitate data communications between the various computers depicted in <FIG> for authentication and/or authorizing financial and non-financial transactions. The system <NUM> includes a user device <NUM>, a resource provider computer <NUM>, a transport computer <NUM>, a central server computer <NUM>, and an authorizing entity computer <NUM>. Each of these systems and computers may be in operative communication with each other. For simplicity of illustration, a certain number of components are shown in <FIG>. It is understood, however, that embodiments of the invention may include more than one of each component. In addition, some embodiments of the invention may include fewer than or greater than all of the components shown in <FIG>. In addition, the components in <FIG> may communicate via any suitable communication medium (including the Internet), using any suitable communications protocol.

The resource provider computer <NUM> may be operated by or on behalf of a resource provider (e.g., a merchant, a transit system, etc.) and the transport computer may be associated with the resource provider. For example, the transport computer may be operated by an acquirer (e.g., a financial institution) responsible for managing an account associated with the resource provider. The authorizing entity computer <NUM> may be operated by an issuer (e.g., another financial institution). In some embodiments, entities are both acquirers and issuers, and embodiments of the invention include such entities.

The user device <NUM> may be in any suitable form. For example, the user device <NUM> can be hand-held and compact so that it can fit into a wallet and/or pocket. Examples of the user device <NUM> may include smart cards, credit and/or debit cards, key chain devices, or the like. Other examples of the user device <NUM> may include cellular phones, personal digital assistants (PDAs), pagers, payment cards, security cards, access cards, smart media, transponders, and the like. The user device <NUM> can also be a stored value card for storing retail store credit or the like.

The user device <NUM> may comprise a computer readable medium (CRM) <NUM> and a body <NUM>. The CRM <NUM> may be on the body <NUM>, which may in the form a plastic substrate, housing, or other structure. If the user device <NUM> is in the form of a card, it may have an embossed region <NUM> which is embossed with a personal account number (PAN). In some embodiments, the CRM <NUM> may store the PAN, and a secondary account number (e.g., a SAN), and/or a counter.

The computer readable medium <NUM> may be a memory that stores data and may be in any suitable form. Exemplary CRM <NUM> may be in the form of a magnetic stripe, a memory chip, etc. The computer readable medium <NUM> may electronically store the primary and/or an encrypted and/or obfuscated PAN in encrypted or unencrypted form.

The central server computer <NUM> may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network may include VisaNet™. Payment processing networks such as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, includes a VIP system (Visa Integrated Payments system) which processes authorization requests and a Base <NUM> system which performs clearing and settlement services.

The central server computer <NUM> may include a server computer. A server computer is typically 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 central server computer <NUM> may use any suitable wired or wireless network, including the Internet.

The resource provider computer <NUM> may also have, or may receive communications from, an access device <NUM> (e.g., a turnstile, a door, a point of sale terminal, etc.) that can interact with the user device <NUM>. In <FIG>, the access device <NUM> may be a component of the resource provider computer <NUM> and/or the access device <NUM> may be accessible by the resource provider computer and/or in communication with the resource provider computer <NUM>. In some embodiments, the access device <NUM> could be located at any other suitable location in other embodiments of the invention. The resource provider computer <NUM> may include any suitable computational apparatus operated by a resource provider (e.g., a merchant). In some embodiments, the resource provider computer <NUM> may include one or more server computers that may host one or more websites associated with the resource provider (e.g., a merchant). In some embodiments, the resource provider computer <NUM> may be configured to send data to a central server computer <NUM> via a transport computer <NUM> as part of a payment verification and/or authentication process for a transaction between the user (e.g., consumer) and the resource provider. The resource provider computer <NUM> may also be configured to generate authorization request messages for transactions between the resource provider and the user <NUM>, and route the authorization request messages to the authorizing entity computer <NUM> (e.g., via the transport computer <NUM> and/or the central server computer <NUM>) for additional transaction processing.

The access devices according to embodiments of the invention can be in any suitable form. Examples of access devices include point of sale (POS) devices, turnstiles, doors, 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, and the like.

The access device <NUM> may include a reader <NUM>, a processor <NUM>, and a computer readable medium <NUM>. The reader <NUM> may use any suitable contact or contactless mode of operation. For example, exemplary card readers can include RF (radio frequency) antennas, magnetic stripe readers, etc. to interact with the user device <NUM>.

In at least one embodiment, the user <NUM> may initiate a purchase of a good or service at the resource provider computer <NUM> using the user device <NUM> (e.g., a credit card). The user device <NUM> can interact with an access device <NUM> such as a POS (point of sale) terminal. For example, the user <NUM> may take a credit card and may swipe it through an appropriate slot in the POS terminal. Alternatively, the POS terminal may be a contactless reader, and the user device <NUM> may be a contactless device such as a contactless card. During this interaction, the user device <NUM> may be configured to determine that the access device <NUM> is of a particular type of terminal (e.g., a POS device). Given that the access device <NUM> is of this particular type of terminal, the user device <NUM> may provide an obfuscated version of a primary PAN stored at the user device <NUM> and an encrypted version of the primary PAN to the access device <NUM>.

An authorization request message may then forwarded to the transport computer <NUM>. The transport computer <NUM> is typically associated with a business entity (e.g., a commercial bank) that has a business relationship with a particular resource provider (e.g., merchant) or other entity and that may be involved in the process of transaction. The transport computer <NUM> may issue and manage accounts for resource providers and exchange funds with the authorizing entity computer <NUM> on behalf of the resource provider. Some entities can perform both authorizing entity computer <NUM> and transport computer <NUM> functions. Embodiments of the present invention encompass such single entity issuer-acquirer computers. After receiving the authorization request message, the transport computer <NUM> may send the authorization request message to the central server computer <NUM>. The central server computer <NUM> may then forward the authorization request message to the authorizing entity computer <NUM>, or a third party entity acting on behalf of the authorizing entity, of the user device <NUM>.

The central server computer <NUM> may be a network that includes or operates at least one server computer used for processing (e.g., payment processing). The server computer in the central server computer <NUM> may include a processor and a computer readable medium coupled to the processor, the computer readable medium comprising code, executable by the processor for performing the functionality described herein. In some embodiments, 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. In some embodiments, the central server computer <NUM> may operate multiple server computers. In such embodiments, each server computer may be configured to process transaction for a given region or handles transactions of a specific type based on transaction data.

The central server computer <NUM> may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. The central server computer <NUM> may include VisaNet™. Networks that include VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, includes an integrated payments system (Integrated Payments system) which processes authorization requests and a Base II system, which performs clearing and settlement services. The payment processing network may use any suitable wired or wireless network, including the Internet.

The central server computer <NUM> may process transaction request messages and determine the appropriate destination (e.g., authentication computer(s)) for the transaction request messages. The central server computer <NUM> may also handle and/or facilitate the clearing and settlement of transactions.

The authorizing entity computer <NUM> is typically associated with a business entity (e.g., a bank) which issues and maintains consumer accounts for a consumer (e.g., the user <NUM>). The authorizing entity computer <NUM> may issue payment devices for the consumer account, including credit cards and debit cards, and the like.

After the authorizing entity computer, or a third party entity acting on behalf of the authorizing entity, receives the authorization request message, the authorizing entity computer <NUM>, or the third party entity acting on behalf of the issuer, may determine that a PAN is to be utilized for the transaction. For example, the authorizing entity computer <NUM> may determine that an obfuscated PAN is being utilized in the authorization request message, that a merchant type of the authorization request message indicates inclusion of a PAN, and/or that a transaction type of the authorization request message indicates inclusion of a PAN. In some embodiments, a PAN included in the authorization request message may be checked against a mapping of known secondary account identifiers (SANs) and if identified, the authorization request message may be declined. In some embodiments, if the PAN in the authorization request message is not included in a mapping of known SANs (e.g., it is not a SAN), the message may be processed further. Once it is determined that a PAN is being utilized, the authorizing entity computer may process the authorization request message to grant or decline the transaction. The authorizing entity computer may send an authorization response message back to the central server computer <NUM> to indicate whether or not the current transaction is authorized (or not authorized). The central server computer <NUM> then forwards the authorization response message back to the transport computer <NUM>. The transport computer <NUM> then sends the response message back to the resource provider computer <NUM>.

After the resource provider computer <NUM> receives the authorization response message, the access device <NUM> at the resource provider computer <NUM> may then provide the authorization response message for the user <NUM>. The response message may be displayed by the access device <NUM>, or may be printed out on a receipt.

At the end of the day, a normal clearing and settlement process can be conducted by the system <NUM>. A clearing process is a process of exchanging financial details between and acquirer and an issuer to facilitate posting to a user's account and reconciliation of the user's settlement position.

In another exemplary embodiment, the user <NUM> may utilize user device <NUM> to initiate an offline transaction. For example, the user <NUM> may present user device <NUM> at an access device <NUM> having a particular terminal type (e.g., indicating a transit turnstile and/or fare checking device that allows/restricts access to a transit system). In some embodiments, the access device may be a contactless reader, and the user device <NUM> may be a contactless device such as a contactless card. In some embodiments, upon presenting the user device <NUM> the access device <NUM> may request authentication data from the user device <NUM>. Due to the access device <NUM> being of a particular terminal type, the user device may provide information such as a SAN stored at the user device <NUM> in CRM <NUM>. Additionally, the user device may provide an encrypted version of a PAN within the data provided to the access device <NUM>.

After the authorizing entity computer, or a third party entity acting on behalf of the authorizing entity, receives the authorization request message, the authorizing entity computer <NUM>, or the third party entity acting on behalf of the issuer, may be configured to determine that a SAN is included in the authorization request message. By way of example, the authorizing entity computer <NUM> may determine that a SAN is included in the authorization request message based at least in part on determining that the data in an account number field included in the message does not end in <NUM> zeros, determining that the requesting merchant is associated with a particular merchant type (e.g., a transit merchant type), and/or that the authorization request message indicates a type of transaction (e.g., a transit transaction) and/or a type of terminal (e.g., a transit terminal) from which the authorization request message was generated. The authorizing entity computer may be configured to decline any authorization request message that includes a SAN in transactions for which SAN usage are disallowed. If a SAN is included in a message for a transaction for which SANs are allowed (e.g., transit transactions, fare transactions, etc.), the authorization entity computer may proceed to process the authorization request message to approve or decline the transaction. The authorizing entity computer may send an authorization response message back to the central server computer <NUM> to indicate whether or not the current transaction is authorized (or not authorized). The central server computer <NUM> then forwards the authorization response message back to the transport computer <NUM>. The transport computer <NUM> then sends the response message back to the resource provider computer <NUM>.

In at least one embodiment, the authorizing entity may conduct a personalization process for the user device <NUM>. During this personalization process, a master derivation key (MDK), a PAN, and a SAN may be stored at the user device <NUM> (e.g., within CRM <NUM>). The user device <NUM> may be configured to perform functionality to derive one or more unique derivation keys from the master key. In some embodiments, the user device <NUM> may derive a UDK using the master key and at least a portion of the PAN. For example, the UDK may be derived using the master key and a left-most <NUM> digits of the PAN. In some embodiments, the left-most <NUM> digits of the PAN may be associated with a bank identification number (BIN).

Once generated, the UDK may be utilized at any suitable time to generate an encrypted identifier and/or an obfuscated identifier. In some embodiments, the UDK may encrypt the entire identifier (e.g., the PAN) as well as a dynamic value such as a counter, date, time, and/or transaction amount. By way of example, the PAN may be concatenated with a dynamic value (e.g., a transaction counter) stored on the user device <NUM> and encrypted using the UDK and an encryption algorithm. In some embodiments, a portion of the encrypted identifier (e.g., the right-most <NUM> digits) may be identified and used to generate an obfuscated identifier. In some embodiments, the obfuscated identifier may include the original <NUM> digits of the PAN (corresponding to a BIN), the portion of the encrypted identifier, and a checksum value (e.g., corresponding to a Luhn checksum). In still further embodiments, the obfuscated identifier may include the original <NUM> digits of the PAN (corresponding to a BIN), any suitable number of padding values (e.g., <NUM> zeros), and a checksum value. The obfuscated identifier and/or the encrypted identifier may be stored at the user device <NUM>.

Upon initialization of a transaction (e.g., a non-transit transaction), or at another suitable time, the user device <NUM> may be configured to provide the obfuscated value and the encrypted identifier in the form of a data track. A data track can be formatted as a Track <NUM> or Track <NUM> data track. Track <NUM> ("International Air Transport Association") stored more information than Track <NUM>, and contains the cardholder's name as well as account number and other discretionary data. This track is sometimes used by airlines when securing reservation with a credit card. Track <NUM> ("American Banking Association" (ABA)) is currently most commonly used. Track <NUM> may be read by ATMs and credit card checkers. The ABA designed the specifications of Track <NUM> and all world banks must abide by it. It contains the cardholder's account, an encrypted PIN, plus other discretionary data.

In some embodiments, the obfuscated value may be provided in a data field of the Track <NUM> data track traditionally including the user's account number (e.g., tag <NUM>). In some embodiments, the encrypted identifier may be provided in a different portion of the Track <NUM> data track (e.g., in Tag 9F1F (Discretionary Data tag), in Tag 9F7C (Customer Exclusive Data Tag), in Tag 9F10 (Issuer Application Data), or in any suitable portion of the Track <NUM> data, or any suitable combination of the above).

In other embodiments, upon initialization of a transaction (e.g., a transit transaction), or at another suitable time, the user device <NUM> may be configured to provide the SAN and the encrypted identifier in the form of a data track. In some embodiments, the SAN may be provided in a data field of the Track <NUM> data track traditionally including the user's account number (e.g., tag <NUM>). In some embodiments, the encrypted identifier may be provided in a different portion of the Track <NUM> data track (e.g., in Tag 9F1F (Discretionary Data tag), in Tag 9F7C (Customer Exclusive Data Tag), in Tag 9F10 (Issuer Application Data), or in any suitable portion of the Track <NUM> data, or any suitable combination of the above).

According to traditional transaction processing, the access device <NUM> may receive the Track <NUM> data track and provide the data to the resource provider computer <NUM> which may then forward at least a portion of the Track <NUM> data to the transport computer <NUM> via an authorization request message. In some embodiments, the access device <NUM> may generate the authorization request message, include at least a portion of the track <NUM> data and forward the authorization request message directly to the transport computer <NUM>.

Upon receipt, or at another suitable time, the transport computer <NUM> may forward the authorization request message to the central server computer <NUM>. The central server computer <NUM> may determine that the encrypted value is present in the authorization request message. The central server computer <NUM> may retrieve a stored UDK and/or derive the UDK utilizing the master derivation key and a portion of the obfuscated identifier (also included in the authorization message). The UDK may be utilized by the central server computer <NUM> to decrypt the encrypted value to obtain the entire unencrypted PAN. In some embodiments, the central server computer <NUM> may modify the authorization request message to include the unencrypted PAN and transmit the modified authorization request message to the authorizing entity computer <NUM> for further processing.

In other embodiments, the central server computer <NUM> and/or the authorizing entity computer <NUM> may utilize at least a portion of the obfuscated identifier (e.g., the first <NUM> digits corresponding to the BIN) to forward an unaltered authorization request message to the authorizing entity computer <NUM>. The authorizing entity computer <NUM> may retrieve a stored UDK and/or derive the UDK utilizing the master derivation key and a portion of the obfuscated identifier or the SAN (also included in the authorization message). The UDK may be utilized by the authorizing entity computer <NUM> to decrypt the encrypted identifier to obtain the entire unencrypted PAN. The central server computer <NUM> and/or the authorizing entity may utilize the SAN to consult a mapping indicating known PAN/SAN associations in order to retrieve an associated PAN. The associated PAN may be compared to the unencrypted PAN to validate the authorization request message.

The authorizing entity computer <NUM> may process the authorization request message and transmit an authorization response message back to the central server computer <NUM>. In some embodiments, the authorization response message may include the obfuscated identifier and the encrypted value and exclude the unencrypted identifier.

The central server computer <NUM> may forward the authorization response message back to the resource provider computer <NUM> via the transport computer <NUM>. After the resource provider computer <NUM> receives the authorization response message, the access device <NUM> at the resource provider computer <NUM> may then provide the authorization response message for the user <NUM>. The response message may be displayed by the access device <NUM>, or may be printed out on a receipt.

At the end of the day, a normal clearing and settlement process can be conducted by the system <NUM>.

By utilizing the techniques described herein, a more secure manner for communicating sensitive data (e.g., a PAN) is enabled. For transactions in which a static identifier is needed (e.g., to confirm or deny access based on a block list), a SAN may be utilized to perform the transaction. By utilizing the SAN and ensuring that the SAN may only be utilized in transactions of a particular type(s) (e.g., transit transactions, fare transactions, etc.) the SAN is protected from fraudsters. Even if a fraudster was able to eavesdrop to gain access to the SAN, the system would ensure that the SAN could only be utilized for certain types of transactions and no others. For other transactions (e.g., non-transit transactions), the PAN is encrypted and provided in a non-traditional data field, and the traditional data field which would normally include the PAN, instead includes an obfuscated value from which the PAN is unlikely to be determined. The obfuscated value may still include the original BIN ensuring that traditional routing techniques for the authorization request/response messages remain unchanged. The techniques described herein make it difficult, if not impossible, to identify the PAN from the authorization request/response messages. Additionally, in some embodiments, the PAN is encrypted using a dynamic value that is ever changing. Accordingly, the encrypted value and obfuscated value can change for each authorization request making it difficult, if not impossible, to track transactions for a particular user over time. Thus, utilizing the techniques discussed herein, privacy protection and security for transmitting sensitive data is improved.

<FIG> depicts a method <NUM> for generating and storing data at a user device (e.g., the user device <NUM> of <FIG>), according to some embodiments. The method <NUM> may begin at <NUM>, where an authorizing entity computer (e.g., authorizing entity computer <NUM>) may obtain a master derivation key. In some embodiments, a master derivation key (MDK) may be utilized to derive one or more unique derivation keys. The authorizing entity computer <NUM> may ensure that the MDK for one user device is unique to that user device. Accordingly, the authorizing entity computer <NUM> may manage many master derivation keys that may correspond to various user devices (e.g., the user device <NUM>).

At <NUM>, the authorizing entity computer <NUM> may obtain a personal account number (PAN) corresponding to a user for which the user device is to be personalized. In at least one embodiment, the PAN may be associated with the user's financial account managed by the authorizing entity on behalf of the user.

At <NUM>, the authorizing entity computer <NUM> may obtain and/or generate a secondary account number (SAN). As discussed throughout, the SAN may be restricted by the authorizing entity computer <NUM> such that the SAN may only be utilized in one or more particular types of transactions. By way of example, it may be the case that in transit systems, or fare checking systems, etc., a user must be authenticated quickly (e.g., in real-time or near real-time). Given the context of the system, it may not be possible to perform online authentication of the user quickly enough to enable access to a resource (e.g., a transit resource) in nearly real-time. Accordingly, some authentication systems perform an offline authentication at the access device and follow up later with an authorization request message to conduct a related transaction. This SAN may be generated to be utilized in such offline authentication scenarios.

At <NUM>, the authorizing entity computer <NUM> may maintain an account number mapping indicating relationships between PANs and SANs. The authorizing entity computer <NUM> may be configured to utilize the mapping for validation purposes as discussed in more detail with respect to <FIG>.

At <NUM>, the authorizing entity computer <NUM> may transmit data to the user device <NUM>. By way of example, the authorizing entity computer <NUM> may transmit the MDK, the PAN, and the SAN to the user device <NUM>. In some embodiments, the authorizing entity computer <NUM> may transmit the data to an intermediary device that may then transfer the data to the user device <NUM>.

At <NUM>, the data may be stored at the user device <NUM> within CRM <NUM>. At <NUM>, the user device <NUM> may generate one or more unique derivation keys using the MDK. By way of example, a unique derivation key (UDK) may be generated according to the process described in more detail in connection with <FIG>. It should be appreciated that one or more UDKs may be generated and that each UDK may be utilized for a particular purpose. For example, a UDK may be generated for macing, another for encryption, another for cryptogram generation, and another UDK may be generated according to the process of <FIG>. It should be appreciated that the user device <NUM> may generate at suitable number of UDKs, or such UDKs may instead be generated by the authorizing entity computer <NUM> at <NUM> or at any suitable time.

At <NUM>, the user device <NUM> may be activated by the authorizing entity computer <NUM>. Upon activation, the user device <NUM> may be utilized at an access device or online for performing a variety of transactions.

<FIG> depicts a method for generating a unique derived key from data residing on a user device (e.g., a smart card), according to some embodiments. The method may be performed by the user device <NUM> of <FIG> utilizing one or more processors of the user device <NUM>.

In at least one embodiment, the master derivation key (MDK) <NUM> and identifier <NUM> are stored at the user device <NUM> during performance of a personalization process (e.g., the method <NUM> of <FIG>). In some embodiments, the identifier <NUM> may be an example of a personal account number. The UDK <NUM> may be derived from such data existing on the user device <NUM>.

By way of example, the user device <NUM> may be configured to identify a portion of the identifier <NUM>. In some embodiments, the portion of the identifier <NUM> may include less than the entire identifier <NUM>. For example, the portion of the identifier <NUM> may include a left-most <NUM> digits of the identifier <NUM>. In some embodiments, the left-most <NUM> digits of the identifier <NUM> may correspond to a bank identification number (BIN) that may be used for routing purposes within a payment processing network (e.g., system <NUM>).

In some embodiments, the portion of the identifier <NUM> may be concatenated with a number of padded bits (e.g., padding <NUM>) to create a string of predetermined fixed length. In some examples, the concatenated value may be <NUM> bits in length where the padding comprises <NUM> bits and the portion of the identifier <NUM> comprises another <NUM> bits (<NUM> digits comprising <NUM> bits each), although the concatenated value is not limited to being this length. The concatenated value may be provided, along with the MDK <NUM> as input into a data encryption algorithm <NUM>.

The data encryption algorithm <NUM> may include any suitable encryption methodology. For example, the data encryption algorithm <NUM> may utilize a triple-DES encryption algorithm. In some embodiments, the value resulting from the encryption conducted by the data encryption algorithm <NUM> is the UDK <NUM>.

<FIG> depicts a method <NUM> for performing offline authentication, according to some embodiments. The method may begin at <NUM>, where a discovery process may be executed by the access device <NUM>. For example, the reader <NUM> of <FIG> may poll for the presence of contactless cards that may have entered the reader's RF field.

At <NUM>, the access device <NUM> may initiate an application selection process with the user device <NUM>. The application selection process may be performed immediately after activation of the user device <NUM> and is the process of determining which application of the applications that are supported by both the user device <NUM> and the access device <NUM> (or the reader <NUM>) will be used to conduct the transaction. By way of example, the access device <NUM> (e.g., the reader <NUM> of the access device <NUM>) may build a candidate list of mutually supported application. A single application from the candidate list may be identified and selected to process the transaction.

At <NUM>, application processing may be initiated. For example, the access device <NUM> (or the reader <NUM>) may signal to the user device <NUM> that transaction processing is beginning. In some embodiments, the beginning of transaction processing may be signaled by sending a GET PROCESSING OPTIONS command from the access device <NUM> (the reader <NUM>) to the user device <NUM>. When issuing this command, the access device <NUM> may provide any suitable data elements. In some embodiments, the contactless path(s) that are mutually supported by the user device <NUM> and the access device <NUM> (the reader <NUM>) may be determined and a contactless path chosen to process the transaction. Subsequent transaction processing may be performed in accordance with the contactless path chosen.

At <NUM>, the user device <NUM> may provide application data back to the access device <NUM> (the reader <NUM>). In some embodiments, the user device <NUM> may first receive the GET PROCESSING OPTIONS. In response to the command, the user device <NUM> may generate any suitable application data. By way of example, a counter stored at the user device <NUM> may be modified (e.g., incremented, decremented, etc.). The user device <NUM> may utilize the counter along with a stored PAN to generate an encrypted PAN that may also be stored at the user device <NUM>. If the GET PROCESSING OPTIONS command indicates that the access device <NUM> is a particular terminal type (e.g., a non-transit terminal type, or a terminal type of a first set of terminal types stored at the user device, etc.) the user device <NUM> may generate an obfuscated PAN from a portion of the stored PAN and a portion of the encrypted identifier. The obfuscated PAN and the encrypted identifier may be provided as application data in this use case. However, if the GET PROCESSING OPTIONS command indicates that the access device <NUM> is another particular terminal type (e.g., a transit terminal type, or a terminal type of a second set of terminal types stored at the user device, etc.) the user device <NUM> may provide the stored SAN and the encrypted identifier as application data.

At <NUM>, when the access device <NUM> (the reader <NUM>) has read the application data necessary in order to process the transaction, the read of the application data may be considered complete. During read time, the access device <NUM> may determine whether all mandatory data elements for the transaction were returned by the card. The access device <NUM> (the reader <NUM>) may terminate the transaction if all mandatory data elements were not returned or if a redundant data was returned (e.g., more than one occurrence of a data element was returned).

At <NUM>, the access device <NUM> (the reader <NUM>) may process retrictions. By way of example, the access device <NUM> (the reader <NUM>) may check the application expiration date, application usage, and/or may whether the SAN is on the Terminal Exception File (TEF). The TEF may be considered a black list in which SANs that are not to be allowed access to a resource are stored. If a SAN appears in the Terminal Exception File, the access device <NUM> (the reader <NUM>) may be configured to deny the user device <NUM> access (e.g., to a turnstile managed by the access device <NUM>) and no further processing may take place.

If however, the SAN is not included in the TEF, the method <NUM> may proceed to <NUM>, where offline data authentication may be executed. Offline Data Authentication may be implemented for the access devices (readers) supporting offline transactions, and may be performed for user devices requested offline transactions. During Offline Data Authentication, the access device <NUM> (the reader <NUM>) may verify the dynamic signature returned by the user device <NUM> and may authenticate the data from the user device <NUM>.

In some embodiments, the access device <NUM> (the reader <NUM>) may support online transactions. In these embodiments, the access device <NUM> (the reader <NUM>) may send an authorization request message to the authorizing entity computer <NUM> (e.g., via the transport computer <NUM> and/or the central server computer <NUM> of <FIG>) at <NUM>. The authorization request message may include the SAN and the encrypted identifier stored at the user device <NUM>.

Upon receipt of the authorization request message at <NUM>, or at any suitable time, the authorizing entity computer <NUM> reviews and authorizes or declines the transaction using predetermined host-based risk management parameters. In some embodiments, the authorizing entity computer <NUM> may be configured to determine that the transaction includes a SAN. In some embodiments, the value of an account identifier field of the authorization request message may be retrieved and compared to a mapping including all known SANs which are mapped to corresponding PANs. If the value of the account identifier field is equal to a known SAN, the transaction may be determined to be utilizing a SAN. In some embodiments, the authorizing entity computer <NUM> may be configured to allow a SAN to be utilized only in transactions in which the access device initiating the transaction (e.g., the access device <NUM>) is of a particular type, or the merchant associated with the access device is a particular merchant type, or a transaction type of the authorization request message indicates an allowable transaction type. As a non-limiting example, the authorizing entity computer <NUM> may be configured to reject online processing utilizing a SAN in transactions that involve an access device that is associated with a non-transit terminal type (e.g., access devices operated by non-transit merchants) while allowing online processing utilizing a SAN for transactions that involve an access device that is associated with a transit terminal type (e.g., access device <NUM> operated by a transit merchant).

In some embodiments, the SAN included in the authorization request message may be associated with a PAN corresponding to the encrypted identifier. The authorizing entity computer <NUM> may be configured to retrieve the <NUM> left-most digits of the SAN corresponding to a bank identification number (BIN). The authorizing entity computer <NUM> may derive a UDK utilizing the BIN and a PAN associated with the SAN as stored in a mapping maintained by the authorizing entity computer <NUM>. Using the derived UDK, the authorizing entity computer <NUM> may decrypt the encrypted identifier of the authorization message to determine a decrypted PAN. The decrypted PAN may be compared to the PAN stored in the mapping and associated with the SAN of the message. If the decrypted PAN matches the stored PAN, the message may be considered valid, and invalid if otherwise. The authorizing entity computer <NUM> may further perform traditional online fraud and credit checks, perform online card authentication utilizing a card-generated cryptogram, or the like.

<FIG> shows a flowchart for a method <NUM> for securely communicating sensitive data, according to some embodiments. The method <NUM> may be performed by a computing device (e.g., the user device <NUM> of <FIG>, a smart card). The computing device may comprise one or more processors and one or more memories storing computer-executable instructions, wherein executing the computer-executable instructions by the one or more processors, causes the computing device to perform the method <NUM>. The steps shown in <FIG> and described below can be used in conjunction with the description of the transaction processing in <FIG> and its corresponding description. Those descriptions are herein incorporated by reference. The computing device may store one or more UDKs, a first identifier (e.g., a secondary account number (SAN)) a second identifier (e.g., a primary account number (PAN)), a dynamic value, or any suitable data within memory of the computing device.

An encrypted identifier may be generated (e.g., by the computing device) at any suitable type (e.g., after receiving the GET PROCESSING OPTIONS command from an access device as discussed above in connection with <FIG>). The computing device may generate encrypted identifier by encrypting the second identifier (e.g., the PAN) and a dynamic value (e.g., a counter, a date, a time, etc.) using a unique derivation key (e.g., the UDK <NUM>). In some embodiments, the second identifier and the dynamic value may be concatenated together and/or with additional padding values prior to being encrypted. In some embodiments, the encrypted identifier may be stored at the computing device (e.g., as part of Track <NUM> and/or Track <NUM> data such as Tag 9F7C (Customer Exclusive Data Tag) and/or Tag 9F10 (Issuer Application Data), in Tag 9F1F (Discretionary Data tag), or in any portion of the Track <NUM> and/or Track <NUM> data, or any suitable combination of the above. Additionally, or alternatively, the encrypted identifier may be provided as part of a data field reserved for future use potentially available in any of the Tags described above or another suitable portion of the Track <NUM> and/or Track <NUM> data.

The method <NUM> may begin at block <NUM>, where a request message may be received by the computing device (e.g., a smart card) from an access device (e.g., a turnstile). In some embodiments, the request message may correspond to a GET PROCESSING OPTIONS command as described above in <FIG>. The access device may be any suitable device configured to request data from a user device.

At <NUM>, the computing device may determine a type indicator for a requesting access device based at least in part on the request message. By way of example, the request message may include a type indicator that indicates the request was initiated by a particular type of terminal/access device. As a non-limiting example, the request message may indicate that the requesting device is a turnstile within a transit system such as a subway system. The computing device may determine whether or not the type indicator belongs to a first type set (e.g., the first type set including a transit type).

At <NUM>, if the type indicator was determined to be included in a first type set or it is determined that the request message was initiated by a particular type of terminal/access device, the computing device may transmit a second message (e.g., to the access device) that comprises at least the first identifier (e.g., the SAN) and the encrypted identifier generated/derived from the PAN. According to some embodiments, the message may be provided to an access device, which causes the user of the computing device to be allowed or denied access to a resource. As a non-limiting example, an access device, such as a turnstile in a transit station, may allow or deny access to the user based on the first identifier (e.g., the SAN). As described above in connection with <FIG>, in some embodiments, the access device (or an associated resource provider computer) may subsequently generate an authorization request message. The authorization request message may comprise, among other things, a first data field comprising the first identifier (the SAN) and a second data field comprising the encrypted identifier. In some embodiments, the authorization request message is transmitted a central server computer (e.g., the central server computer <NUM> of <FIG>) for further authorization processing.

At <NUM>, if the type indicator was determined not to be included in the first type set or is determined not to be the particular type of terminal/access device, an obfuscated identifier may be generated (e.g., by the user device <NUM>). In some embodiments, the obfuscated identifier may include the first <NUM> digits of the second identifier (the PAN), <NUM> zeros, and a Luhn checksum value. In other embodiments, the obfuscated identifier may be generated based at least in part on the portion of the second identifier (e.g., the PAN) and a portion of the encrypted identifier. By way of example, the obfuscated identifier may be generated to include a first <NUM> digits of the identifier and the last <NUM> digits of the encrypted identifier (or any suitable number of zeros). This is merely an example, more or fewer digits of the identifier and more or fewer digits of the encrypted identifier may be utilized. Similarly, the obfuscated may include <NUM> digits or any suitable number of digits. In some embodiments, a Luhn checksum value may be computed from the obfuscated identifier and included as part of the obfuscated identifier (e.g., the last digit, digit <NUM> in the ongoing example).

At <NUM>, a second message (e.g., a Track <NUM> message) may be provided (e.g., by the user device <NUM>). In some embodiments, the message may comprise at least the obfuscated identifier and the encrypted identifier. According to some embodiments, the message may be provided to an access device (e.g., the access device <NUM>), which causes an authorization request message to be generated (e.g., by the access device <NUM> and/or the resource provider computer <NUM> of <FIG>). The authorization request message may comprise, among other things, a first data field comprising the obfuscated identifier and a second data field comprising the encrypted identifier. In some embodiments, the authorization request message is transmitted a central server computer (e.g., the central server computer <NUM> of <FIG>) for further authorization processing.

<FIG> depicts an exemplary record format <NUM> for use in some embodiments. For example, the record format <NUM> may include track <NUM> data (e.g., authentication data) including a SAN and an encrypted identifier. The record format <NUM> may be an example of the second message described in connection with <NUM> of <FIG>. In one non-limiting example, the PAN <NUM> may be associated with a user and stored on the user's device (e.g., a smartcard). In some embodiments, a SAN <NUM> may be associated with the user and stored on the user's device. As illustrated in <FIG>, the PAN <NUM> and the SAN <NUM> may each include <NUM> digits. In some embodiments, the PAN <NUM> is stored at Tag <NUM> of the Track <NUM> data as defined by the Track <NUM> data. In some embodiments, the SAN <NUM> is stored at Tag 5A of the Track <NUM> data as defined by the Track <NUM> data.

The first <NUM> digits (e.g., a identifier data field <NUM>) of the record format <NUM> (e.g., digits <NUM>-<NUM>) may traditionally be reserved for the SAN <NUM>. Next, a separator data field <NUM> provides a buffer between the account identifier and the expiration date data field <NUM>. A service code data field <NUM> may follow the expiration date data field <NUM>. A personal identification number verification indicator (PVKI) data field <NUM> and a PIN verification information data field <NUM> follow. Next, a dCVV data field <NUM>, a transaction counter data field <NUM>, and a contactless indicator data field <NUM> are included. Finally, a discretionary data field <NUM> follows. The discretionary data field may include an encrypted value data field <NUM> and a cryptogram version number data field <NUM>. The encrypted value data field <NUM> and a cryptogram version number data field <NUM> may include any suitable number of digits, not necessary the number depicted in <FIG>.

According to some embodiments, the PAN <NUM> may first be utilized to generate an encrypted value (e.g., an encrypted identifier). By way of example, the user device <NUM> of <FIG> may be configured to retrieve the PAN <NUM> and the UDK <NUM> of <FIG> from storage. In some embodiments, a transaction counter (or other dynamic value) may also be retrieved. The PAN and the transaction counter (or other dynamic value) may be utilized together with the UDK <NUM> as input into an encryption algorithm to generate an encrypted value. In some embodiments, the PAN and the transaction counter (or other dynamic value) may be concatenated prior to input. The resultant encrypted value may be stored with the record format <NUM>. By way of example, the resultant encrypted value may be stored as depicted within the encrypted value data field <NUM> of the discretionary data field <NUM>. In some embodiments, discretionary data field <NUM> corresponds to a particular tag defined by the Track <NUM> standard (e.g., in Tag 9F1F (Discretionary Data tag), Tag 9F7C (Customer Exclusive Data Tag), in Tag 9F10 (Issuer Application Data), in any suitable portion of the Track <NUM> data, or any suitable combination of the above).

In some embodiments, the cryptogram version number data field <NUM> may store a number indicating that the discretionary data field <NUM> includes the encrypted value within the encrypted value data field <NUM>.

According to some embodiments, the user device <NUM> may be configured to provide the SAN <NUM> in the identifier data field <NUM>. Digit <NUM> of the identifier data field <NUM> may include a checksum value (e.g., a Luhn checksum/value) that may be utilized (e.g., on receipt) for verifying that the identifier data field <NUM> has not been altered. In some embodiments, the SAN <NUM> may be provided within the identifier data field <NUM> when the user device <NUM> has determined that a requestor of Track <NUM> data is associated with a particular terminal type (e.g., a transit terminal type, a terminal type associated with offline authentication, etc.).

Once a transaction has been initiated, the SAN <NUM> contained within the identifier data field <NUM> and the encrypted value within discretionary data field <NUM> (e.g., at encrypted value data field <NUM>) may be provided (e.g., to an access device as described above). In some embodiments, the transaction counter can be incremented (or decremented) and/or a new dynamic value may be generated and stored in transaction counter data field <NUM>. Should another transaction be initiated by the user device <NUM>, the process discussed herein may be repeated utilizing the new transaction counter/dynamic value and the PAN <NUM> to generate a new encrypted value and a new obfuscated identifier which may then be provided in the subsequent transaction.

<FIG> depicts another exemplary record format <NUM> for use in some embodiments. For example, the record format <NUM> may include track <NUM> data (e.g., payment data) including an obfuscated identifier and an encrypted identifier. The record format <NUM> may be an example of the second message described in connection with <NUM> of <FIG>. In one non-limiting example, the PAN <NUM> may be associated with a user and stored on the user's device (e.g., a smartcard). In some embodiments, a SAN <NUM> may also be associated with the user and stored on the user's device. As illustrated in <FIG>, the PAN <NUM> and the SAN <NUM> may each include <NUM> digits. In some embodiments, the PAN <NUM> is stored at Tag <NUM> of the Track <NUM> data as defined by the Track <NUM> data. In some embodiments, the SAN <NUM> may be stored at Tag 5A of the Track <NUM> data as defined by the Track <NUM> data.

The first <NUM> digits (e.g., a identifier data field <NUM>) of the record format <NUM> (e.g., digits <NUM>-<NUM>) may be reserved for an obfuscated version of the account identifier (e.g., obfuscated PAN <NUM>, an obfuscated version of the PAN <NUM>). Next, a separator data field <NUM> provides a buffer between the account identifier and the expiration date data field <NUM>. A service code data field <NUM> may follow the expiration date data field <NUM>. A personal identification number verification indicator (PVKI) data field <NUM> and a PIN verification information data field <NUM> follow. Next, a dCVV data field <NUM>, a transaction counter data field <NUM>, and a contactless indicator data field <NUM> may be included. Finally, a discretionary data field <NUM> may follow. The discretionary data field may include an encrypted value data field <NUM> and a cryptogram version number data field <NUM>. The encrypted value data field <NUM> and a cryptogram version number data field <NUM> may include any suitable number of digits, not necessary the number depicted in <FIG>.

According to some embodiments, the PAN <NUM> may first be utilized to generate an encrypted value (e.g., an encrypted identifier). By way of example, the user device <NUM> of <FIG> may be configured to retrieve the PAN <NUM> and the UDK <NUM> of <FIG> from storage. In some embodiments, a transaction counter (or other dynamic value) may also be retrieved. The PAN <NUM> and the transaction counter (or other dynamic value) may be utilized together with the UDK <NUM> as input into an encryption algorithm to generate an encrypted value. In some embodiments, the PAN <NUM> and the transaction counter (or other dynamic value) may be concatenated prior to input. The resultant encrypted value may be stored with the record format <NUM>. By way of example, the resultant encrypted value may be stored as depicted within the encrypted value data field <NUM> of the discretionary data field <NUM>. In some embodiments, discretionary data field <NUM> corresponds to a particular tag defined by the Track <NUM> standard (e.g., in Tag 9F1F (Discretionary Data tag), Tag 9F7C (Customer Exclusive Data Tag), in Tag 9F10 (Issuer Application Data), in any suitable portion of the Track <NUM> data, or any suitable combination of the above).

According to some embodiments, the user device <NUM> may be configured to generate the obfuscated PAN <NUM>. By way of example, the user device <NUM> may obtain the first <NUM> digits of the PAN <NUM> and store this information in digits <NUM>-<NUM> of the identifier data field <NUM>. In some embodiments, digits <NUM>-<NUM> of the identifier data field <NUM> may include padding values such as zeros. Alternatively, the user device <NUM> may be configured to obtain some portion of the encrypted value and store the portion within the record format <NUM>. For example, the last <NUM> digits of the encrypted value may be obtained and stored as digits <NUM>-<NUM> of the identifier data field <NUM>. Digit <NUM> of the identifier data field <NUM> may include a checksum value (e.g., a Luhn checksum/value) that may be utilized (e.g., on receipt) for verifying that the identifier data field <NUM> has not been altered.

Once a transaction has been initiated, the obfuscated PAN <NUM> and the encrypted value within discretionary data field <NUM> (e.g., at encrypted value data field <NUM>) may be provided (e.g., to an access device as described above). The transaction counter can be incremented (or decremented) and/or a new dynamic value may be generated and stored in transaction counter data field <NUM>. Should another transaction be initiated by the user device <NUM>, the process discussed herein may be repeated utilizing the new transaction counter/dynamic value and the PAN <NUM> to generate a new encrypted value and a new obfuscated identifier which may then be provided in the subsequent transaction.

<FIG> shows a flowchart for a method for performing data verification, according to some embodiments. The method <NUM> may be performed by a computing device (e.g., the central server computer <NUM> and/or the authorizing entity computer <NUM> of <FIG>). The computing device may comprise one or more processors and one or more memories storing computer-executable instructions, wherein executing the computer-executable instructions by the one or more processors, causes the computing device to perform the method <NUM>.

The method <NUM> may begin at block <NUM>, where a message (e.g., an authorization request message) may be received. In some embodiments, the message may comprise a first identifier (e.g., a SAN) and an encrypted identifier. The steps shown in <FIG> and described below can be used in conjunction with the description of the transaction processing in <FIG> and its corresponding description. Those descriptions are herein incorporated by reference.

At block <NUM>, the computing device may verify a type associated with the requesting device that initiated the authorization request message. In some embodiments, the computing device may compare a value contained in the authorization request message (e.g., a merchant name, an address, a type indicator, a terminal type, etc.) to data stored at, or accessible to, the computing device (e.g., values for which utilization of a SAN is allowed). If the value contained in the authorization request message is contained in the stored data, the computing device may allow the authorization request message to be processed further. If the value is not contained in the authorization request message, the computing device may decline the authorization request message and transmit an authorization response message to the requestor indicating the same.

At <NUM>, the first identifier (e.g., the SAN) may be utilized to obtain an expected identifier (e.g., a primary PAN). In some embodiments, the computing device may consult a mapping that indicates known associations between PANs and SANs.

At <NUM>, the computing device may generate a decrypted identifier utilizing the encrypted identifier and a unique derivation key. In some embodiments, the computing device may derive the unique derivation key (UDK) from a portion of the first identifier (e.g., the SAN). In some embodiments, the UDK may be previously derived and retrieved from storage. By way of example, the computing device may retrieve a left-most <NUM> digits of the first identifier and use those digits as input into a predetermined encryption algorithm to generate the UDK. The left-most <NUM> digits may correspond to a bank identification number (BIN). Once the UDK has been generated, it may be utilized to decrypt the encrypted identifier.

At <NUM>, the computing device may be configured to verify that the decrypted identifier matches the expected identifier <NUM>. That is, that the decrypted identifier corresponds to a primary PAN associated with the first identifier (e.g., a SAN) as defined within the mapping maintained by the computing device.

At <NUM>, the message may be processed by the computing device utilizing the decrypted identifier. By way of example, the computing device may be a central server computer (e.g., the central server computer <NUM> of <FIG>). In this scenario, processing the message (e.g., an authorization request message) may include modifying the message to include the decrypted identifier and transmitting the message to an authorizing entity computer (e.g., the authorizing entity computer <NUM>) for further processing. In some embodiments, the computing device may be the authorizing entity computer <NUM>. In this scenario, processing the message may include authorizing the transaction with the message data including the decrypted identifier. The processing may further include generating an authorization response message indicating that the transaction was approved or declined. The authorization response message may include the encrypted identifier and transmitted, for example, to the central server computer <NUM> according to the process described above in connection with <FIG>.

<FIG> shows a flowchart for another method for performing data verification, according to some embodiments. The method <NUM> may be performed by a computing device (e.g., the central server computer <NUM> and/or the authorizing entity computer <NUM> of <FIG>). The computing device may comprise one or more processors and one or more memories storing computer-executable instructions, wherein executing the computer-executable instructions by the one or more processors, causes the computing device to perform the method <NUM>.

The method <NUM> may begin at block <NUM>, where a message (e.g., an authorization request message) may be received. In some embodiments, the message may comprise an obfuscated identifier and an encrypted identifier. The steps shown in <FIG> and described below can be used in conjunction with the description of the transaction processing in <FIG> and its corresponding description. Those descriptions are herein incorporated by reference.

At block <NUM>, the computing device may identify that the message comprises the encrypted identified. In some embodiments, identifying that the message comprises the encrypted identifier may include checking a particular data field (e.g., the discretionary data field <NUM> of <FIG>) for a non-zero value. If the data field contains a non-zero value, the computing device may conclude that the encrypted value is present in the message. In some embodiments, identifying that the message comprises the encrypted identifier may include checking a particular data field (e.g., the cryptogram version number data field <NUM> of <FIG>) for a non-zero value (or a particular value).

At block <NUM>, the computing device may generate a decrypted identifier utilizing the encrypted identifier and a unique derivation key. In some embodiments, the computing device may derive the unique derivation key (UDK) from a portion of the obfuscated identifier. In some embodiments, the UDK may be previously derived and retrieved from storage. By way of example, the computing device may retrieve a left-most <NUM> digits of the obfuscated identifier and use those digits as input into a predetermined encryption algorithm to generate the UDK. Once the UDK has been generated, it may be utilized to decrypt the encrypted identifier.

At block <NUM>, the message may be processed by the computing device utilizing the decrypted identifier. By way of example, the computing device may be a central server computer (e.g., the central server computer <NUM> of <FIG>). In this scenario, processing the message (e.g., an authorization request message) may include modifying the message to include the decrypted identifier and transmitting the message to an authorizing entity computer (e.g., the authorizing entity computer <NUM>) for further processing. In some embodiments, the computing device may be the authorizing entity computer <NUM>. In this scenario, processing the message may include authorizing the transaction with the message data including the decrypted identifier. The processing may further include generating an authorization response message indicating that the transaction was approved or declined. The authorization response message may include the encrypted identifier and transmitted, for example, to the central server computer <NUM> according to the process described above in connection with <FIG>.

By utilizing the techniques described herein, a more secure manner for communicating sensitive data (e.g., a PAN) is enabled. Not only is the PAN encrypted and provided in a non-traditional data field, but the traditional data field which would normally include the PAN, instead includes an obfuscated value from which the PAN is unlikely to be determined. The obfuscated value still may include the original BIN ensuring that traditional routing techniques for the authorization request/response messages remain unchanged. The techniques described herein make it difficult, if not impossible, to identify the PAN from the authorization request/response messages. Additionally, in some embodiments, the PAN is encrypted using a dynamic value that is ever changing. Accordingly, the encrypted value can change for each authorization request making it difficult, if not impossible, to track transactions for a particular user over time. Accordingly, these methods provide improvements regarding personal data privacy by ensuring that a particular user and/or account cannot be identified from the authorization request/response message.

Any of the computing devices described herein may be an example of a computer system that may be used to implement any of the entities or components described above. The subsystems of such a computer system may be are interconnected via a system bus. Additional subsystems include a printer, keyboard, storage device, and monitor, which is coupled to display adapter. Peripherals and input/output (I/O) devices, which couple to I/O controller, can be connected to the computer system by any number of means known in the art, such as a serial port. For example, I/O port or external interface can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus may allow the central processor to communicate with each subsystem and to control the execution of instructions from system memory or the storage device, as well as the exchange of information between subsystems. The system memory and/or the storage device may embody a computer-readable medium.

As described, the inventive service may involve implementing one or more functions, processes, operations or method steps. In some embodiments, the functions, processes, operations or method steps may be implemented as a result of the execution of a set of instructions or software code by a suitably-programmed computing device, microprocessor, data processor, or the like. The set of instructions or software code may be stored in a memory or other form of data storage element which is accessed by the computing device, microprocessor, etc. In other embodiments, the functions, processes, operations or method steps may be implemented by firmware or a dedicated processor, integrated circuit, etc..

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++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer readable medium, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.

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.

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.

Claim 1:
A computer-implemented method (<NUM>), comprising:
receiving (<NUM>), by a user device (<NUM>) from an access device (<NUM>), a first message comprising a terminal type indicator;
in response to the terminal type indicator indicating a terminal type associated with offline authentication:
transmitting (<NUM>), from the user device to the access device, a second message comprising a first identifier and an encrypted identifier; and
in response to the terminal type indicator indicating a terminal type associated with online authentication:
generating (<NUM>), by the user device, an obfuscated identifier based at least in part on a first portion of a second identifier and a second portion of the encrypted identifier; and
transmitting (<NUM>), from the user device to the access device, a third message comprising the obfuscated identifier and the encrypted identifier.