Technology for processing contactless card functions in a multi-banking system environment

Abstract

Systems and techniques for performing functions within a multi-banking system environment using switchboard routing. In one aspect, a method executed by a computer includes receiving, by a node within the system, a request from a client device to establish a session for performing a function, where at least a portion of the function is performed using a contactless card; generating, by the node, session information corresponding to the session for performing the function, where the session information includes a nonce and a signed session token; sending, by the node, the session information to the client device; receiving, by the node, a message from the contactless card via the client device; extracting, by the node, an issuer identifier from the message, where the issuer identifier is associated with an issuer of the contactless card; identifying, by the node, a device associated with the issuer identifier; and communicating with the device and securely performing the function by the node.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims priority to U.S. Patent Application No. 18 / 207,831, filed on June 9, 2023, which is a continuation - in - part of U.S. Patent Application No. 18 / 207,831, which claims priority to U.S. Provisional Patent Application No. 63 / 405,749, filed on September 12, 2022, the disclosure of which is hereby incorporated by reference in its entirety. This application claims priority to U.S. Provisional Patent Application No. 63 / 388,859, filed on July 13, 2022, the disclosure of which is hereby incorporated by reference in its entirety.

[0002] Field of the Disclosure The present disclosure generally relates to techniques for processing contactless card functions in a multi - banking system.

Background Art

[0003] Contactless card products are very widely known and ubiquitous, and have fundamentally changed the way financial transactions and purchases are considered and conducted in today's society. Contactless card products are most commonly represented by plastic or metallic card - like members provided to customers via credit card issuers (such as banks and other financial institutions). Using the card, authorized customers or cardholders can purchase services and / or goods without the immediate direct exchange of cash. Data security and transaction integrity are extremely important for the businesses and customers facilitating these transactions. This need continues to grow as electronic transactions conducted using contactless cards constitute an ever - larger proportion of commercial activity. Therefore, there is a need to provide businesses and users with suitable solutions to overcome current drawbacks in order to provide data security, authentication, and verification for contactless cards.

Summary of the Invention

[0004] In one aspect, a method executed by a computer includes receiving, by a node in a system, a request asking to establish a session for executing a function from a client device, where the function is at least partially performed using a contactless card, generating, by the node, session information corresponding to the session for executing the function, where the session information includes a nonce and a signed session token, sending, by the node, the session information to the client device, receiving, by the node, a message from the contactless card via the client device, extracting, by the node, an issuer identifier associated with the issuer of the contactless card from the message, identifying, by the node, a device associated with the issuer identifier, and communicating, by the node, with the device to securely perform the function.

[0005] In one aspect, a computing device includes a processor. The computing device also includes a memory storing instructions that, when executed by the processor, cause the processor to receive a request asking to establish a session for executing a function from a client device, where the function is at least partially performed using a contactless card, generate session information corresponding to the session for executing the function, where the session information includes a nonce and a signed session token, send the session information to the client device, receive a message from the contactless card via the client device, extract an issuer identifier associated with the issuer of the contactless card from the message, identify a device associated with the issuer identifier, and communicate with the device to securely perform the function.

[0006] In one aspect, a non-transitory computer-readable storage medium, when executed by a computer, causes the computer to receive a request for establishing a session to execute a function from a client device, the function being performed at least partially using a contactless card, generate session information corresponding to the session for executing the function, the session information including a nonce and a signed session token, send the session information to the client device, receive a message from the contactless card via the client device, extract an issuer identifier associated with the issuer of the contactless card from the message, identify a device associated with the issuer identifier, and communicate with the device to securely perform the function, the non-transitory computer-readable storage medium including instructions.

[0007] In one aspect, a method executed by a computer includes reading, by a computing device, a contactless card after the contactless card enters a communication range, selecting, by the computing device based on the reading of the contactless card, an applet stored in a memory of the contactless card, sending, by the computing device, a first command to the contactless card, and sending, by the computing device, a second command to the contactless card.

[0008] In one aspect, a computing system includes a computing device including a processor and a memory. The memory of the computing device, when executed by the processor, causes the processor to read a contactless card after the contactless card enters a communication range, select, based on the reading of the contactless card, an applet stored in a memory of the contactless card, send a first command to the contactless card, and send a second command to the contactless card, the memory storing instructions.

[0009] In one aspect, there is a non-transitory computer-readable storage medium that stores instructions which, when executed by a computing device, cause the computing device to perform procedures. The procedures include reading a contactless card after the contactless card enters the communication range, selecting an applet stored in the memory of the contactless card based on the reading of the contactless card, sending a first command to the contactless card, and sending a second command to the contactless card.

Brief Description of the Drawings

[0010] To easily identify the description of any particular element or operation, the most significant digit of the reference number refers to the figure number in which the element is first introduced.

Figure 1

Figure 2

Figure 3

Figure 4A

Figure 4B

Figure 4C

Figure 5

Figure 6

Figure 7

Figure 8A

Figure 8B

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13A

Figure 13B

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

[0011] Next, to illustrate the various features of the present invention, exemplary embodiments of the present invention will be described. The embodiments described herein are not intended to limit the scope of the present invention; rather, they are intended to provide examples of the components, uses, and operations of the present invention.

[0012] Furthermore, the features, advantages, and characteristics of the description of the exemplary embodiments may be combined in any suitable manner. Those skilled in the art will recognize that embodiments may be practiced without one or more of the specific features or advantages of an embodiment. In some cases, additional features and advantages that may not be present in all embodiments may be recognized in a particular embodiment. Those skilled in the art will understand that the features, advantages, and characteristics of the description of any embodiment may be combined interchangeably with the features, advantages, and characteristics of any other embodiment.

[0013] Embodiments may generally be directed to enabling contactless card functionality in a multi-issuer computing environment. These functions may include tap-based functions where a user can tap their contactless card on a device such as a mobile device to execute a function. For example, a user may use their contactless card to verify their identity, make a payment, launch an application, log in to an application, automatically enter a form or field, navigate to a specified web location or application on the device, unlock a door, initiate a contactless card, and so on.

[0014] The systems described in this specification may enable a user to perform these functions in a multi-issuer environment. Further, the systems described in this specification enable a card issuer, such as a bank, to issue a contactless card with tap functions to customers while maintaining a high level of security. The systems described are different from previous solutions in that they provide a single platform for multiple issuers or banks to provide tap functions. Conventionally, each issuer or bank had to set up and maintain its own system to provide contactless card functionality. This included maintaining its own hardware, software, database, security protocol, etc., which could be extremely costly for the issuer or bank to maintain. However, the described embodiments enable an issuer or bank to delegate most of the processing, storage, and security functions to a neutral or central system. As will be described in more detail, the central system is configured to provide contactless card functionality to multiple issuers while maintaining a high level of security and data integrity. The functions and data of each issuer can be separately managed and protected so that another issuer or bank cannot access the data or functions of another issuer. As will be described in more detail, these functions can be provided by a switchboard system configured to process and perform each contactless card function in a secure manner. Further benefits for the issuer may include providing highly secure authentication options to the mobile web, which typically lacks the robust authentication options available in native applications.

[0015] Furthermore, the embodiments described herein support a mobile web experience by tap operation on both major mobile platforms (iOS (registered trademark), Android (registered trademark)) by leveraging App Clips (registered trademark) and JavaScript (registered trademark) SDK using WebNFC (registered trademark). In the case of iOS (registered trademark), the embodiment includes providing a software development kit for tap operation that includes functions and services for performing the operations described herein on the iOS (registered trademark) platform. The SDK may be installed in a host application, such as a native app or a web browser app, and includes App Clip (registered trademark) support. The SDK provides functional support for near-field wireless communication between the mobile device and the contactless card, installation of native apps via App Clips (registered trademark), and a function to obscure parts of the data and / or display. In one example, the SDK may be configured to download and install an app from an app store such as the Apple (registered trademark) App Store.

[0016] In an Android (registered trademark) operating system environment, embodiments include utilizing a JavaScript SDK and a native Android SDK. The JavaScript SDK may be installed on a website, for example, via the source code of the website or an app. The JavaScript SDK also includes functionality to support NFC communication between mobile device contactless cards via WebNFC (registered trademark). The JavaScript SDK may also include customizable user interface (UI) functionality and functionality to provide obfuscation. In embodiments, the JavaScript SDK supports websites that utilize Hypertext Transfer Protocol Secure (HTTPS) and supports the React (registered trademark) library. Embodiments are not so limited and a UI library may be supported. Embodiments further include utilizing a native Android SDK that may be implemented in an application on a device, such as a mobile device. The Android SDK may assist an application and / or website via a web browser using wireless communication with a device such as a contactless card. The Android SDK also enables an application or web browser to communicate with and utilize other basic Android services, such as the operating system and low-level services. Embodiments are not limited to these examples.

[0017] The systems and methods described herein provide contactless card data security, authentication, and verification and provide numerous advantages. For example, the systems and methods described herein enable card tap requests to be routed to many different card validators by adding issuer identification to the data payload communicated between a card and various other devices (e.g., client devices and / or servers).

[0018] As another example, card personalization can be decoupled from card validity verification, which advantageously enables multiple entities to perform validity verification securely, consistently, and without unnecessary exchange of sensitive data. In some examples described herein, decoupling card personalization from validity verification can be achieved by adding key identifiers to data payloads communicated between the card and various other devices (e.g., client devices and / or servers). In other examples described herein, decoupling card personalization from validity verification can be achieved by deriving a shared secret from a master key. In yet other examples described herein, decoupling card personalization from validity verification can be achieved by avoiding the use of the permanent account number (PAN) sequence number (PSN) for key derivation.

[0019] As another example, challenges may be incorporated to advantageously avoid or reduce the risk of pre-play attacks and / or replay attacks. In some examples, a challenge can be generated, linked to a session, and then written to the card. The challenge can be used when generating encrypted data such as ciphertext, and session validity verification can be added to the validity verification logic.

[0020] As a further example, further improvements to data security, authentication, and validity verification can be made. For example, NFC specifications, dormant applets, signed hashes of card product customer identifiers, centralized validators, and general-purpose cryptography may be advantageously used.

[0021] All of the foregoing examples provide many advantages with respect to data security, authentication, and verification of contactless cards. It is understood that these and further advantages can be achieved by one or a combination of one or more of the foregoing examples.

[0022] In connection with the notations and nomenclatures generally used herein, one or more portions of the following detailed description may be presented with respect to program procedures executed on a computer or a network of computers. The description and representation of these procedures are used by those skilled in the art to most effectively convey the substance of their work to other skilled persons. A procedure is here also generally considered to be a self-consistent sequence of operations leading to a desired result. These operations are those requiring physical manipulation of physical quantities. Usually, though not necessarily always, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It will be appreciated that, mainly for reasons of common usage, it is sometimes convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc. However, it should be noted that all of these and similar terms are to be associated with appropriate physical quantities and are merely convenient labels applied to those quantities.

[0023] Furthermore, these operations are often referred to in terms such as addition or comparison, which are generally associated with intellectual operations performed by a human operator. However, in any of the operations described herein that form part of one or more embodiments, such capabilities of a human operator are neither necessary nor, in most cases, desirable. Rather, these operations are machine operations. Useful machines for performing the operations of the various embodiments include digital computers selectively activated or configured by a stored computer program written in accordance with the teachings herein, and / or apparatus or digital computers specially constructed for the required purposes. The various embodiments also relate to apparatus or systems for performing these operations. These apparatus may be specially constructed for the required purposes. The required structures of these various machines will become apparent from the given description.

[0024] Next, referring to the drawings, like reference numerals are used throughout to refer to like elements. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding. It will be apparent, however, that the novel embodiments may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form in order to facilitate the description. The intention is to cover all modifications, equivalents, and alternatives within the scope of the claims.

[0025] FIG. 1 shows an example of a multi-issuer system 100 configured to operate in accordance with the embodiments described herein. System 100 may include a non-contact card 102 and a computing system configured to enable functions to be performed using the non-contact card, such as the cryptographic techniques described herein. These functions may include performing transactions, as well as other functions such as user authentication and functions by tap operations. Functions by tap operations may include automatically entering a field on a mobile device by a tap operation, launching an application on a mobile device by a tap operation, opening a door by a tap operation, activating a card by a tap operation, generating and issuing a virtual card number (VCN) by a tap operation, and other tap operations.

[0026] System 100 shows a high-level configuration that enables multiple users to use non-contact cards issued by one or more issuers to perform operations including transactions with merchant systems. In the illustrated example, system 100 includes several banking systems 106a, retail systems 106b, other financial systems 106c, and government systems 106d. These transaction systems may be configured to perform transactions for a user to purchase goods and services with a non-contact card. Additionally, these systems may be configured to provide authentication services to a customer via the customer's non-contact card. The embodiments are not so limited.

[0027] System 100 can be configured to perform various operations for customers, issuing banks, merchants, etc. These operations can be initiated by a customer using the contactless card 102 and can cause an exchange of information between the contactless card 102 and other systems of the system 100. For example, depending on which operation is being performed, such as launching an application by a tap operation, automatically entering text by a tap operation, authenticating by a tap operation, conducting a transaction by a tap operation, providing (automatically entering) a VCN by a tap operation, data can be routed and transmitted to various systems of the system 100 to perform their respective operations.

[0028] For example, the contactless card 102 can be further configured to communicate with one of the other systems, such as a mobile device 104, and when tapped on another device, it may initiate a transaction with one of the merchant systems. These services can include a verification service and a commercial transaction service. However, the embodiments are not limited in this way. Other services can be configured to perform operations so that a customer can execute functions by performing any number of tap operations.

[0029] As will be described in more detail, the mobile device 104 can communicate data to one or more other systems, such as one or more of the services 110 configured to provide transaction services and other operations, from the contactless card 102. As described herein, the data can be routed to a specific service 110 by the switchboard system 108 in a secure and encrypted manner. In an embodiment, the data can be provided in ciphertext.

[0030] To provide services in a multi-issuer environment, system 100 includes a switchboard system 108 or a hub system configured to communicate data between systems (such as banks, retailers, other financial institutions, governments, etc.) and the back-end processing services of participating banks. The switchboard system 108 enables any number of banks and different financial institutions to issue contactless cards with transaction functions, verification functions, etc., and to operate seamlessly while maintaining a high level of security with confidential data. As will be described in more detail, the switchboard system 108 enables a mobile device and a merchant system, which is the central system of communication, to communicate with the data of many issuing banks to execute transactions and other functions.

[0031] For example, a customer may wish to conduct a transaction for goods or services (retailer system 106b). The customer may initiate the transaction through an interaction with their mobile device or a point-of-sale (POS) terminal. The device or terminal may send a message for the transaction to the switchboard system 108, and the switchboard system may further process the message to determine how to complete the transaction. The message may include an encrypted portion and an unencrypted portion. The encrypted portion may include confidential data that can be used by the issuing banking system function to process the transaction, and the unencrypted portion may include data that can be used by the switchboard system 108 to route the message and data to the correct issuing banking system function through services such as application programming interfaces and commercial transaction services. The switchboard system 108 may communicate with the mobile device 104 and then with the merchant back-end system (106) to first verify the contactless card and the user, establish a commercial transaction session between the mobile device, the commercial transaction service, and the merchant system, and enable the transaction to be conducted in a secure manner.

[0032] In an embodiment, the switchboard system 108 may also include a management service that can be used to onboard card issuers, validators, and merchants onto the system to provide contactless card services. In one example, the switchboard system can onboard an issuer / validator by generating a unique identifier that identifies the issuer / validator and storing the mapping between the unique identifier and the issuer / validator in a data store such as a validation HSM. The unique identifier may also be provided to the issuer system so that the issuer can provide a unique identifier on each contactless card for use during transactions and other operations.

[0033] Any number of banks or financial institutions may provide some services 110 or functions that can be used by customers, merchants, and banks to provide services 110 including transaction processing and verification of customers and their contactless cards. These services may include a validation service and a commercial transaction service. These services may be hosted on a central platform such as a cloud-based system, and each bank may have its own set of services. Additionally, the services 110 of each bank may be hosted by the same central platform, and the switchboard system 108 may determine which bank's services 110 to call via an API based on the information in the message.

[0034] In an embodiment, system 100 may also perform an onboarding operation to onboard merchants and merchant systems for operating in the switchboard system 108 environment. In an embodiment, onboarding a merchant may include generating a unique identifier associated with the merchant and providing the merchant with the unique identifier, such as by issuing a merchant certificate. System 100 may also exchange data, such as a key pair, to enable the merchant and the issuer to operate securely without confidential data being revealed to the switchboard system 108. System 100 may also enable a merchant to configure and set one or more configurations, such as configuring data fields to support the merchant's use case.

[0035] System 100 may also perform an onboarding operation for a card issuer. For example, system 100 may enable a bank or card issuer to generate a unique identifier, such as an issuer ID, that can be used to uniquely identify the issuer when performing validity checks and other functions. System 100 may also enable a bank or issuer to generate and / or distribute a key pair with merchants and other service providers. These and other details will be described in the following explanation.

[0036] FIG. 2 shows an example of a system 200 according to an embodiment described herein. System 200 includes additional devices and systems configured to enable a contactless card issuer to perform card services by a tap operation. Specifically, system 200 enables any number of issuer systems to provide card services to their clients in a secure and safe manner via a switching fabric, i.e., the switchboard system 108.

[0037] In an embodiment, the switchboard system 108 includes one or more nodes 204 configured to perform routing operations. Each switchboard node 204 may include a session and nonce generator 206, a message router 208, 210, an operation data 212 store, and a metric store 214. Further, each of the nodes may be similarly configured and share a configuration, but each switchboard node 204 can independently process messages and requests and route them to appropriate systems such as a merchant system and an issuer system. Each of the nodes 204 is configured to function as an intermediary of trust, for example, between an issuer system, a merchant system 222, and / or a validity confirmation system 224. Each switchboard node 204 is configured to route each message to the correct issuer system while maintaining data security. For example, the switchboard node 204 may route messages between the issuer system and the merchant system while the node cannot obtain access rights to the private data in the message.

[0038] The switchboard system 108 can be configured as a server system that includes a set of hardware, software, and network components that cooperate to provide services to clients. The hardware components can include one or more server computers, storage devices, and network adapters. The server computers are configured to execute server applications such as those executable at each of the nodes 204. In some cases, each of the server computers may be configured to operate one or more nodes, for example, in a virtual environment. The storage device is configured to store data accessed by the application, and the network adapter is used to connect the server computer to the network.

[0039] Each of the server computers can be configured to execute software including an operating system, applications, and security software. The network components of the server system include network switches, routers, and firewalls. The network switch is used to connect the server computer to other devices on the network. The router is used to route traffic between different networks. The firewall is used to protect the server system from unauthorized access and attacks.

[0040] In some embodiments, node 204 may operate in a cloud-based computing environment, e.g., a collection of hardware, software, and network components that enable the delivery of cloud computing services. The switchboard node 204 and computing services are delivered over the Internet and can be accessed from anywhere in the world using an Internet connection. In an embodiment, client 236 may access switchboard node 204 via domain name system 202 or domain name system (DNS). DNS 202 is a hierarchical and distributed naming system for computers, services, and other resources connected to the Internet or other networks. DNS 202 associates various information with domain names assigned to each registered participant. In one example, DNS 202 may convert a name known to software running on client 236 and route data to one or more of the switchboard nodes 204 of switchboard system 108. In an embodiment, DNS 202 may generate an Internet Protocol (IP) address, an address record (A record), or another host name (C name record), etc. FIG. 3 shows one exemplary sequence 300 for a client to identify and resolve an identifier of one of the nodes 204 of switchboard system 108. At a high level, domain name system 202 converts a known domain name into a numerical Internet Protocol (IP) address necessary for locating and identifying computer services and devices having underlying network protocols. The client uses the global DNS system to select the best node to use, as described in sequence 300.

[0041] In an embodiment, the client sdk 236 communicates with the switchboard system 108 to perform one or more of the partner services 232, such as conducting transactions with merchants, validating customers, and other tap operation-based functions. When the client sdk 236 identifies the switchboard node 204 and resolves the address for communicating with the switchboard node 204, the client sdk 236 may send one or more messages to the switchboard node 204 for authenticated operation. The switchboard node 204 includes an authentication 210 function configured to authenticate the client sdk 236. In an embodiment, the client sdk 236 sends a message or permission request having the following header set to the switchboard node 204. ●X-Sb-Api-Key: <CLIENT API KEY> ●X-Sb-Dvc-Fngrprnt: Device-specific device fingerprint

[0042] CLIENT API KEY may have the following exemplary structure: 65535-GReyx5BuEAaE72bWbFZJfHRL8Dbt1Uum, and Table 1 below describes the value, name, and meaning.

[0043]

Table 1

[0044] The switchboard node 204 may permit or authenticate the client sdk 236 or the user, and the switchboard node 204 may operate using additional components such as a session and nonce generator 206 and a message router 208, as described in FIGS. 4A-4C. Note that the validator validity confirmation system 224 never interacts with the merchant system 222, and vice versa. The node 204 mediates all communications.

[0045] In an embodiment, the switchboard system 108 may utilize the Hyperledger Fabric 220 to manage the synchronization of shared operation data 212 and member management across the network. The Hyperledger Fabric 220 is a distributed ledger framework with a permissioned network model where only authorized participants can join the network and access the data stored in the ledger.

[0046] In an embodiment, the Hyperledger Fabric 220 may be generated by creating one or more sets of peers, orderer services, and channels. Once the network is created, the system 200 deploys chaincode to a network or node 204 permitted to access the fabric. The chaincode is code that operates on the blockchain and executes the logical code for network control 226 and operation data 212. Once the chaincode is deployed, each of the switchboard nodes 204 is configured to call transactions on the blockchain to add data, such as operation data, to the blockchain. The switchboard node 204 or another device can query the ledger to retrieve data. The ledger is a distributed database that stores all the data added to the blockchain.

[0047] All nodes 204 maintain independently verifiable logs of their actions, which can be sent to a centralized aggregator to build a true picture of the overall network usage. At the central level, the system 200 can manage network operation data and management and have a centralized view of network usage that is aggregated and abstracted at an appropriate level.

[0048] Figure 3 shows an exemplary sequence 300 for a client to resolve and communicate with one or more nodes of a switchboard system using DNS. The illustrated sequence 300 includes a client 236, DNS 202, and a switchboard node 204. At 302, sequence 302 includes the client 236 sending a request to a default DNS server for a text record switchboard.{domain}.{tld}. The text record may be preconfigured in the client application and / or client sdk. At 304, DNS 202 returns one or more records. The DNS record structure may include the following. ● Root record: 〇 Name: switchboard.{domain}.{tld} 〇 Type: TXT 〇 Resolution: · {nodename_1}.{operator_a}.{region_i}.switchboard.{domain}.{tld}, · {nodename_2}.{operator_a}.{region_i}.switchboard.{domain}.{tld}, · {nodename_1}.{operator_b}.{region_ii}.switchboard.{domain}.{tld}, · {nodename_2}.{operator_b}.{region_ii}.switchboard.{domain}.{tld}, · * etc. 〇 Used to determine where the active nodes are ● Node record: 〇 Name: {nodename}.{operator}.{region}.switchboard.{domain}.{tld} 〇 Type: A / AAAA or CNAME 〇 Resolution: actual node host name or IP 〇 Used to communicate with the node

[0049] In an embodiment, the client 236 may determine the current time zone at 306. For example, the client app or SDK may utilize a current time zone acquisition function such as JavaScript:Intl.DateTimeFormat().resolvedOptions().timeZone). The embodiments are not limited in this way, and the app or SDK may determine the time zone via another / different function call. At 308, the client 236 is configured to map the time zone to a region or a shortened version identifier of the region. One example includes America / New York -> na-e. This region may be based on, for example, a DNS name. Table 2 shows some examples of time zone mappings to regions.

[0050]

Table 2

[0051] The embodiments are not limited to these examples, and other time zone-to-region mappings may be utilized. Further, in an embodiment, the region can also be represented as a bidirectional graph structure where the edges represent geographically adjacent regions. For example, na-e <-> na-w and sa <-> na-w and sa <-> na-e. This representation is useful for node selection.

[0052] At 310, the client may identify or select the DNS record options returned at 304 that are within the region. If there are multiple matches, the client may randomly select one. If there are no available nodes within the region, the client may, at 312, determine the data graph of the adjacent region and use it to select a node in the nearest region where a node is available. For example, sa has no nodes, but since it is connected to na-e where nodes exist, na-e is selected. In some embodiments,

[0053] At 314, the client may resolve the host name of the selected node. In an embodiment, the client 236 may automatically resolve the host name using the client's HTTP request default resolver. At 316, the domain name system 202 may return the result. And at 318, the client 236 may communicate with the switchboard node 204 and initiate the process of interacting with the switchboard.

[0054] Figures 4A - 4C illustrate an exemplary sequence 400 of operations between a contactless card and services provided by a card issuer and / or merchant. The illustrated sequence 400 includes actions and communications performed by a contactless card 102, a client sdk 236 including a client app and client sdk, a domain name system 202, a switchboard system 108, a partner service 232 including a merchant and / or validator, and a control service 234 including a client server or system.

[0055] In an embodiment, at 402, the client sdk 236 including the client app may send a request and establish a session with a client server 484 such that the result can be associated with the correct client device or user. The request establishes a relationship between the client device and the client server, which may be an issuer server. At 404, the client server 484 generates a session and CLIENT SESSION INFORMATION. At 406, the client server 484 returns the session information, such as CLIENT SESSION INFORMATION. In an embodiment, the CLIENT SESSION INFORMATION may be user session identification information specific to the client implementation.

[0056] At 408, the client sdk236 may initiate a contactless card authentication process with the client sdk236. For example, the client sdk236 may call a function and / or pass information to the client sdk236 to initiate authentication via a contactless card. At 410 - 414, the client may use DNS to identify a node and establish communication with the node. Specifically, at 410, the client sdk236 may send a request to obtain a switchboard host name, and at 412, the DNS486 may return information including one or more host names. At 414, the client sdk236 may determine the switchboard node to communicate with. FIG. 3 shows an example of a more detailed sequence of the process of establishing communication with a switchboard node.

[0057] At 416, the client sdk236 may send a request to the switchboard system 108 to obtain a session. In an embodiment, the request to obtain a session may be for a function request in the format of <FUNCTION REQUEST>. In an embodiment, the FUNCTION REQUEST may be the data / function that the client desires to request after the contactless card has been verified for validity. This function can be for any service described herein, such as authenticating a user, conducting a transaction, requesting auto - input data, etc. At 418, the switchboard system 108 may generate a nonce and a signed session token. The signed session token may be a JSON Web Token (JWT). When generating a JWT, the following elements need to be set.

[0058] ·iss: The unique ID of the current node,

[0059] ·nonce: A randomly generated nonce of eight hexadecimal characters,

[0060] ·exp: An expiration timestamp (+5 minutes),

[0061] · client_id: The client ID of the requesting original client,

[0062] · sub: The device fingerprint of the requesting original client,

[0063] · sid: Any session information sent from the client,

[0064] · scope: The function requested to be performed.

[0065] The nonce may be a unique random byte generated to guarantee the impossibility of repeating messages using contactless cards. The nonce is important for the security and operation of the switchboard system. The validity of the nonce is tracked by associating the nonce with a session that can be verified for validity by any member of the platform. As described above, the session is a JSON Web Token signed using a node-specific private key issued by the network. These JWTs are verifiable by a system with the corresponding public key, and the public key can also be verified by confirming that it was issued by us or an authorized agent. The signed session token is a JWT generation token that establishes the validity and expiration of the nonce and associates a tap of the contactless card with the current client session. For example, the signed session token is signed with <NODE PRIVATE KEY> <nonce>It includes <CLIENT SESSION INFO> and <FUNCTION REQUEST>, and the NODE PRIVATE KEY is the private key of the switchboard system 108. The switchboard system 108 may include the NODE PUBLIC / PRIVATE KEY, which is a key pair used to sign and verify the JWT.

[0066] In an embodiment, the switchboard system 108 can use nonces as challenges to avoid or reduce the risk of pre-play attacks and / or replay attacks. For example, the contactless card 102 may transmit data communication, e.g., by NFC, and such communication may be intercepted by other readers, e.g., NFC readers, and may be replayed later to avoid security requirements. This can be countered by binding the transmission by the contactless card, e.g., the ciphertext, to the session time (e.g., time and / or device).

[0067] At 420, the switchboard system 108 may return session information to the client sdk 236. The session information includes a signed session token (<SIGNED SESSION TOKEN>), NONCE <nonce>may include the Function Service Terms of Use <FUNCTION TOS> and the Terms of Service Version <TOS VERSION>. The FUNCTION TOS may be the terms of service that a user must agree to in order to enable the execution of the requested function by the client, and the TOS VERSION may be the version of the terms of service. In 422, the client sdk236 may determine and / or receive user consent to the terms of service. In one example, the client sdk236 incorporates and records the user's consent to the <FUNCTION TOS> as of the <CONSENT DATE> of <TOS VERSION>. The CONSENT DATE may be a timestamp regarding the user's consent to the TOS.

[0068] In 424, the client sdk236 exchanges one or more messages with a contactless card. In one example, the exchange may be based on a contactless card tapped on the client device. In an embodiment, the client sdk236 may provide data to the contactless card 102 for use during a session in which a function is performed. The data may be provided to the contactless card 102 in an NDEF message. In one example, the data is written to the card in NDEF format using a binary update command. The data may include a NONCE that provides a security level such that the message received from the card is part of the same session. Additionally, the data may include additional information such as one or more control bits that control the format generated by the contactless card. Table 3 below shows an example of the NDEF message format.

[0069] [Table 3]

[0070] In an embodiment, the updated MAC can be calculated to protect the control indicator. Specifically, the MAC M is determined by calculating the MAC over 10 bytes of updated data U using the following updated MAC card key (MCK).

[0071] U = [control indicator (2 bytes) || update date and time (8 bytes) || ’80’ || ’00 00 00 00 00’]

[0072] Consider U as two blocks of 8 - byte data: U = U1||U2 ● Calculate B = DES(MCKL)[U1] ● Calculate B = [B XOR U2] ● Calculate B = DES(MCKL)[B] ● B = DES -1 (MCKR)[B] is calculated

[0073] Finally, MAC M = DES(MCKL)[B]

[0074] In 424, the contactless card can generate a message and provide it to a client device including the client sdk236. The data within the message can be utilized to perform functions required by the systems described herein. An example of a message is shown and described in message 600 of FIG. 5.

[0075] At 426, a client including the client sdk 236 may send messages and information to the switchboard system 108. The message may be a message received from the contactless card 102, such as message 600. Additionally, the client sdk 236 may send the consent date, the TOS version, and the signed session token to the switchboard system 108. The switchboard system 108 may use the information to ensure that the session is valid. At 428, the switchboard system 108 verifies that the signed session token is valid, e.g., is a previously provided signed session token, includes a previously generated nonce, and is within the message.

[0076] In some embodiments, the switchboard system 108 is configured to determine which issuer system or client server to route the message to for processing. At 430, the switchboard system 108 may determine the issuer ID by extracting the issuer ID from the message received from the contactless card 102 via the client sdk 236. As described above, the issuer ID identifies the issuer of the contactless card 102.

[0077] In an embodiment, the switchboard system 108 is configured to generate and communicate secure communications with an issuer system, such as client server 484 and validator 488. At 432, the switchboard system 108 sends a request for a key to the client server 484. The key may be used to conduct secure communications. In one example, it may be an Elliptic Curve Diffie-Hellman (EDCH) key request. The embodiments are not so limited, and alternative key protocols, such as Supersingular Isogeny Diffie-Hellman key exchange (SIDH or SIKE), Secret / Public key pairing (RSA), etc. may be used.

[0078] At 434, the client server 484 generates a portion of the key. Optionally, the client server 484 may generate half of the EDCH key for encryption / decryption of PII. Specifically, the client server 484 may generate <CLIENT EC PUBLIC KEY> and <CLIENT EC PRIVATE KEY> using the elliptic curve P256. CLIENT EC PUBLIC KEY and CLIENT EC PRIVATE KEY are the first half of the EDCH key negotiation.

[0079] At 436, the client server 484 stores the generated portion of the key in storage. Specifically, the client server 484 may store <CLIENT EC PUBLIC KEY> and <CLIENT EC PRIVATE KEY> together with <KEY ID>, and KEY ID is used by the client server to later complete the EDCH key, for example, to identify the EDCH key portion and generate the entire EDCH key, or to cache its short-lived EC public / secret keys. In one example, the key may be stored in a secure memory location and used when PII is received for a session.

[0080] In an embodiment, at 438, the client server 484 may return the public key portion to the switchboard system 108 together with the KEY ID. The switchboard system 108 may store the public key portion together with the KEY ID for later use, for example, for the generation of the EDCH key. At 440, the switchboard system 108 may request that a validity check be performed by the validator 488. In one example, the switchboard system 108 requests a validity check <message>、<SIGNED SESSION TOKEN>, <CLIENT EC PUBLIC KEY>, <CONSENT DATE>, and <TOS VERSION> can be sent. At 442, the validator 488 can return an out-of-band request for a public key to the switchboard system 108 to verify the session. At 444, the switchboard system 108 can provide the public key of the node, i.e., <NODE PUBLIC KEY>. Further, at 446, 488 can verify the secure session token using the public key of the node.

[0081] In an embodiment, the validator 488 can validate the message at 448. In an embodiment, the validator 488 can perform several validations, including ensuring that the nonce in the message is correct, along with additional information such as the unique identifier of the card (pUID) and the counter value (pATC). FIGS. 13A and 13B illustrate additional details of the validation process that can be performed.

[0082] At 450, the validator 488 can store information associated with the session. For example, the validator 488 can store <CONSENT DATE> with <TOS VERSION> and <puid>It can be remembered together with. The validator 488 may also generate another part of a key, such as an EDCH key. For example, 488 may generate <ISSUER EC PUBLIC KEY> and <ISSUER EC PRIVATE KEY> using the elliptic curve P256. ISSUER EC PUBLIC KEY and ISSUER EC PRIVATE KEY may be the latter part of the EDCH key negotiation.

[0083] In 454, the validator 488 may generate a complete EDCH key. For example, the validator 488 generates <EDCH KEY> from <ISSUER EC PRIVATE KEY> and <CLIENT EC PUBLIC KEY>. EDCH KEY is the last key generated using EDCH key negotiation.

[0084] The validator 488 may encrypt data for a function using the EDCH KEY. For example, in some cases, when the validator 488 validates a message, the validator 488 may, in 456, execute a function request to create a function result and encrypt the result with the EDCH key. For example, the validator 488 may execute <FUNCTION REQUEST> to create <FUNCTION RESULT> and encrypt it with <EDCH KEY>. The function result may be any result based on the requested function, such as card verification.

[0085] In 458, the validator 488 may return the function result to the switchboard system 108. In some cases, the function result is encrypted and returned. For example, the validator 488 may return <ENCRYPTED FUNCTION RESULT> and <ISSUER EC PUBLIC KEY>.

[0086] In an embodiment, the switchboard system 108 sends function results to the client server 484 to process the results. In one example, the switchboard system 108 may send <ENCRYPTED FUNCTION RESULT>, <KEY ID>, <ISSUER EC PUBLIC KEY>, and <SIGNED SESSION TOKEN>. At 462 and 464, the client server 484 may request a public key from the switchboard system 108 and receive the public key from the switchboard system 108. Optionally, the exchange may occur over an out-of-band communication channel. The public key of the node may be <NODE PUBLIC KEY>. The public key may be used to verify, among other things, the sender of the function result. At 466, 484 may verify the signed session key with the node's public key <NODE PUBLIC KEY> to verify the sender of the information. At 468, the client server 484 may extract client information from the signed session token. For example, the client server 484 may extract <CLIENT SESSION INFO> from <SIGNED SESSION TOKEN>, i.e., extract user session identification information specific to the client implementation.

[0087] Furthermore, at 470, the client server 484 may retrieve the client private key having the KEY ID. Specifically, the client server 484 may use <KEY ID> to retrieve <CLIENT PRIVATE KEY> from the cache and may delete it. At 472, the client server 484 may generate or calculate the EDCH key. For example, the client server 484 may calculate <EDCH KEY> using <CLIENT PRIVATE KEY> + <ISSUER EC PUBLIC KEY>. At 474, the client server 484 may decrypt the function result using the calculated key. Specifically, the client server 484 may decrypt <ENCRYPTED FUNCTION RESULT> with <EDCH KEY> to determine <FUNCTION RESULT>. At 476, the client server 484 associates the function result with the session.

[0088] In an embodiment, the switchboard system 108 may return to the client sdk 492 at 478 whether the function result has been successfully completed. Further, at 480, the client sdk 492 may notify the client app 490 of the result. At 482, the client app 490 may utilize the function. For example, at 482, the client app 490 may continue to communicate with the client server 484 to fetch the edited <FUNCTION RESULT> using <CLIENT SESSION INFO>.

[0089] In an embodiment, the switchboard system 108 may generate a nonce for use as a challenge and link this challenge to the session. The challenge can be written to the contactless card 102 (e.g., to an applet included in the memory of the contactless card) and can be used by the contactless card in the generation and / or calculation of ciphertext as described herein. Additionally, session validity verification may be added to the validity verification logic as part of the validity verification described herein.

[0090] The use of challenges can provide many advantages, including significantly improving security and reducing the rejection of false positives based on problems that occur with the counter value (pATC). In embodiments, writing a challenge can be implemented by changing the configuration of the contactless card. For example, a contactless card (e.g., an applet included in the memory of the contactless card) may be provided with a new internal record containing a new configuration file. The contactless card may be configured to support optional WRITE BINARY and / or UPDATE BINARY to facilitate sending challenges to the card. The contactless card may be configured to support processes with challenges and processes without challenges. Additionally, the cryptographic techniques utilized by the contactless card may be configured to support processes with challenges and processes without challenges.

[0091] In embodiments, writing a challenge can be implemented by changing the configuration of one or more SDKs used by the systems and methods described herein, including by the contactless card, client device, server, and other network-enabled computers. For example, the SDK may be updated to implement NDEF reading at the application protocol data unit (APDU) level. The SDK may be updated to determine the process flow by querying the applet function file. Additionally, the SDK may be updated to request a challenge from the validator.

[0092] In an embodiment, writing a challenge can be implemented by changing the configuration of a validator. For example, the validator may be updated to support the generation and provisioning of challenges. The validator may be updated to support the generation and provisioning of sessions. Additionally, the validator may be updated to support a validation policy based on a version number, including but not limited to, applet and / or software version numbers.

[0093] FIG. 5 shows an example of routine 500 according to an embodiment described herein. For example, routine 500 can be performed by the devices and systems described herein, including but not limited to, mobile device 104, client app 490, issuer system 802, personalization system 804, contactless card 102, client device, software development kit (SDK), POS terminal, and personal computer.

[0094] In block 502, NDEF reading of contactless card 102 can be performed. NDEF reading can be performed after contactless card 102 enters the NFC field of a device such as mobile device 104.

[0095] In block 504, an applet of contactless card 102 can be selected. Contactless card 102 can store multiple applets in its memory, and the multiple applets can include a payment applet (e.g., an applet configured to perform payment transactions such as EMV transactions) and an authentication applet (e.g., an applet configured to perform authentication operations such as the authentication operations described herein).

[0096] In block 506, it is possible to read the function containers associated with the selected applet and collect information related to the containers and applets. The information to be collected can include, but is not limited to, the container size, the number of files stored in the container, the file sizes of the files stored in the container, the file names of the files stored in the container, and the read state and write state of the files stored in the container.

[0097] In block 508, custom commands can be executed. For example, a custom command can be sent to the contactless card 102 and can include data and one or more instructions. A custom command can be used to update one or more of the selected applet, function container, and files within the container. For example, a custom command can update a file to include nonces. As another example, a custom command can be a WRITE BINARY command. As a further example, a custom command can be a command that changes the state of an applet on the contactless card 102 (e.g., changes from a dormant state to an active state, from a locked state to an unlocked state, from a deactivated state to an activated state, from a first version to a second version), a command that changes the format of a message stored on the contactless card 102 or generated by the contactless card 102, a command that changes one or more parameters used in calculations performed by the contactless card, a command that changes the form of the authentication operation used by the contactless card 102 (e.g., an encrypted MAC operation, a signed message with a public key certificate), and / or a command that sends one or more certificates (e.g., digital certificates such as public key certificates, code signing certificates, client certificates, user certificates, etc.). The custom command can be other commands and instructions, and it is understood that the custom command is not limited to these examples.

[0098] In block 510, a second command can be given, and a ciphertext can be calculated in response to the second command. The ciphertext can be calculated according to the embodiments described herein, and the nonce can be used for calculating the ciphertext. In an embodiment, the second command can be a READ BINARY command. In an embodiment, the second command can instruct that the nonce be used for calculating the ciphertext.

[0099] FIG. 6 shows an example of a message 600 that can be communicated by the contactless card 102 to execute the functions described herein. One or more of the fields within the message 600 can also be utilized to route the message 600 via a switchboard system and to perform authentication / validation techniques.

[0100] In an embodiment, the message 600 includes an applet version 602 field, an issuer discretionary indicator 604 field, an issuer identifier 606 field, a pKey ID 608 field, a pUID 610 field, a pATC 612 field, a nonce 614 field, and an encrypted ciphertext 616.

[0101] In an embodiment, the fields can be in plaintext or encrypted. For example, the applet version 602 field may include the applet version in plaintext. The applet version indicating which applet version is installed on the contactless card 102 can be used by other systems to determine how to process the message 600 when communicated. For example, different applet versions require different validation logics. For example, old messages can be routed via the issuer system to perform various operations for validation, while new messages can be routed via the switchboard system to perform various operations including validation. As another example, different applet versions require different personalization logics.

[0102] In an embodiment, message 600 includes issuer data and includes an issuer discretionary indicator 604 field that can be set during personalization. Additionally, message 600 includes an issuer identifier 606 field that may include a unique ID assigned to the entity that issues the card, e.g., the issuer, or other entity associated with the contactless card. For example, each issuer may be assigned a unique identifier during the onboarding operation when joining the system. The issuer ID can be used by the switchboard system 108 to route messages and their content to the appropriate services associated with that particular issuer.

[0103] In an embodiment, message 600 includes a pKey ID 608 field. In some cases, the pKey ID 608 field may include data that identifies a set of master keys for the card issuer. The set of issuer master keys may utilize each card set of derived master keys or unique derived keys (UDKs). Further, a unique set of master keys (UDKs) for each card can be generated during card personalization. The UDK of the card can be utilized to generate a session key that is used to generate an application ciphertext. The session key generated by the card can be regenerated by the system, e.g., the validator system, using the pKeyID to identify the issuer's master key and regenerating the session key by the system for validation.

[0104] In an embodiment, each contactless card 102 is given a unique 16 - digit decimal identification information (pUID) during personalization. The derivation of the unique key for the card applet using the pUID is performed off - card. The resulting application key is introduced during card personalization. In an embodiment, the application key of the card is the same as the derived master key or UDK of the card. The process for deriving the application key (UDK) is as follows. 1. Create several issuer master key sets and assign each a unique 3-byte pKey ID (6-digit hexadecimal). 2. For each card application: 1. Associate one of the issuer's pKey IDs with the card's pUID. 2. Use the pKey ID to identify the issuer master key for application key generation (UDK) and subsequent ciphertext calculation and data encryption. 3. For each application key (UDK), create diversification data as follows. 1. Create a 16-digit quantity X from the 16 digits of the pUID. 2. Each application key (UDK) is formed by the following steps. 1. Calculate ZL by encrypting X using the appropriate issuer master key identifier (pKey ID). 2. Calculate ZR by taking the exclusive logical sum (XOR) of X and FFFFFFFFFFFFFFFFFF and then encrypting the result using the issuer master key. 3. Concatenate ZL and ZR to form the application key (UDK key).

[0105] In embodiments, the key derivation process can avoid or stop using the PSN. In these embodiments, there is no need to look up the PSN from the database to generate the UDK. As a result, dependence on the database is avoided and information is not retrieved from the database. Thus, device personalization and validation (e.g., card personalization and validation) can be performed independently.

[0106] In embodiments where a derived key can be derived from a 16 - digit pUID instead of being derived from 14 - digits from the pUID and PSN, the entropy does not decrease, and further, this change can have a beneficial impact on personalization, applets, or other software, and authentication. For example, an encrypted master key may be used with the 16 - digit from the pUID to derive an encrypted UDK. As another example, an authentication master key may be used with the 16 - digit from the pUID to derive an authentication UDK.

[0107] Message 600 may include a pUID610 field that contains a unique identifier of the card assigned to the contactless card during personalization. The pUID610 field data is used to uniquely identify each card and may be an alphanumeric combination associated with the user. In embodiments, the pUID610 field may include data related to the user associated with the contactless card and / or the account associated with the user.

[0108] In embodiments, including the pUID610 field enables a namespace unique to each individual entity. That is, the pUID610 field can include a namespace for the issuing entity or the validator entity to further separate personalization and authentication.

[0109] In embodiments, message 600 includes a pATC612 field configured to hold a counter value. The counter value holds the count of reads (taps) performed on the contactless card, in hexadecimal format in one example. Further, the counter value can be used to generate a session key and encrypt at least a portion of the message.

[0110] In an embodiment, each time a message 600 is created, a new session key is derived and used to generate one or more parts of the message 600. Specifically, the session key is used to calculate an encrypted MAC (application ciphertext).

[0111] The card applet supports a modified variation of the session key derivation option according to EMV 4.3, Book 2, Annex A1.3.1 to generate a unique encrypted session key ASK as follows. ● Calculate SKL by encrypting [ATC[2]||ATC[3]||’F0’||’00’||[ATC[0]||[ATC[1]||[ATC[2]||[ATC[3]] using the application key ● Calculate SKR by encrypting [ATC[2]||ATC[3]||’0F’||’00’||[ATC[0]||[ATC[1]||[ATC[2]||[ATC[3]] using the application key ● Concatenate SKL and SKR to form an authentication session key.

[0112] The authentication session key is used to encrypt the encrypted MAC.

[0113] The card applet also supports a modified variation of the session key derivation option according to EMV 4.3, Book 2, Annex A1.3.1 to generate a unique encryption session key DESK as follows. ● Calculate SKL by encrypting [ATC[2]||ATC[3]||’F0’||’00’||’00’||’00’||’00’||’00’] using the data encryption key ● Calculate SKR by encrypting [ATC[2]||ATC[3]||’0F’||’00’||’00’||’00’||’00’||’00’] using the data encryption key ● Concatenate SKL and SKR to form a data encryption session key.

[0114] The ciphertext C is determined by calculating the MAC over 32 bytes of transaction data T using the authentication session key (ASK) as follows.

[0115] T = [pVersion (2 bytes) || pIssuerID (3 bytes) || pKeyID (3 bytes) || pUID (8 bytes) || pATC (4 bytes) || nonce (4 bytes) || pSHSEC (4 bytes) || ’80’ || ’00 00 00’]

[0116] Consider T as four blocks of 8 - byte data: T = T1 || T2 || T3 || T4 ● Calculate B = DES(ASKL)[T1] ● Calculate B = [B XOR T2] ● Calculate B = DES(ASKL)[B] ● Calculate B = [B XOR T3] ● Calculate B = DES(ASKL)[B] ● Calculate B = [B XOR T4] ● Calculate B = DES(ASKL)[B] ● B = DES -1 Calculate (ASKR)[B]

[0117] Finally, the ciphertext C = DES(ASKL)[B]

[0118] The encryption of the ciphertext is performed by encrypting in cipher block chaining (CBC) mode using the data encryption session key (DESK) as follows. ● Generate an 8 - byte random number [RND] ● Calculate E1 = DES3(DESK)[RND] ● Calculate B = [E1] XOR [C] ● Calculate E2 = DES3(DESK)[B] ● Finally, the 16 - byte encrypted payload E = [E1] || [E2]

[0119] For restoration using the decryption mode: ●RND = DES3 -1 (DESK)[E1] ●B = DES3 -1 (DESK)[E2] ●C = [E1] XOR [B]

[0120] In an embodiment, a portion of the data provided in message 600 is static and is set on the card during card personalization, and other data is dynamic and can be generated by the card during an operation, such as when a read operation is being performed. In some cases, the static information may be updatable, but the customer and the card may be required to go through a secure update process that can be controlled by the issuer.

[0121] In an embodiment, the contactless card 102 can communicate messages between devices, such as a mobile device, during a read operation. For example, in response to the contactless card 102 being tapped on the surface of a device or being brought within a wireless communication range, a read operation may be performed on the contactless card 102, and the contactless card 102 may generate a message and provide the message to the device. For example, when within range, the contactless card 102 and the device may perform one or more exchanges for the contactless card 102 to send a message to the device. Step 424 in FIG. 4A shows an example of an exchange.

[0122] The wireless communication may follow a wireless protocol such as Near Field Communication (NFC), Bluetooth, WiFi, etc. In some cases, the message may be communicated between the contactless card 102 and the device via a wired means, such as via the contact pad 904, in accordance with the EMV protocol.

[0123] Message 600 provides several benefits. For example, Message 600 provides the benefits of data communication, data security, card authentication, and the validity confirmation described herein. As another example, including the issuer identifier 606 field enables Message 600 to be routed to the appropriate issuing entity (or, if different from the issuing entity, the appropriate validator entity) for validity confirmation. This allows the issuing entity or the entity that personalized the transmitting device (e.g., if the transmitting device is a contactless card, the issuing entity of the contactless card) to be separated from the validator entity. Thus, not only can the issuing entity or the entity that personalized the transmitting device be identified by the issuer identifier 606 field, but also any validator entity permitted to perform validation. In addition, this routing is scalable across many messages, many issuing entities, and many validator entities.

[0124] As another example, including the pKey ID 608 can replace the requirement for a database lookup upon receipt of the data payload. This supports the separation of validity confirmation from the database and the requirement for access to the database to perform validity confirmation.

[0125] FIG. 7 shows an example of a routine 700 according to an embodiment described herein. In block 702, the routine 700 is to receive, by a node in the system, a request to establish a session for executing a function from a client device, where the function is performed at least in part using a contactless card. Optionally, the node may be one of a plurality of nodes of a switchboard system. The node may have been previously selected by the transmitting device via a performed DNS operation.

[0126] In block 704, routine 700 involves the node generating session information corresponding to a session for executing a function, where the session information includes a nonce and a signed session token. The nonce and / or signed session token are used by the system to ensure that the node routing data is authenticated and the message from the contactless card is authenticated while executing the functions described herein, and can be utilized to track the session for the function.

[0127] In block 706, routine 700 involves the node sending the session information to the client device. The client device can communicate with the contactless card, authenticate, and receive data from the card to execute the function. Optionally, the client device may send a nonce from the node to the contactless card. The contactless card may utilize the nonce when generating the message to be finally returned to the node, for example, incorporated into the encrypted portion of the message (see Figure 6).

[0128] In block 708, routine 700 involves the node receiving a message from the contactless card via the client device. The message can be generated by the contactless card. Figure 6 shows an example of message 600.

[0129] In block 710, routine 700 involves the node extracting the issuer identifier associated with the issuer of the contactless card from the message. Optionally, the issuer identifier may be in plain text format.

[0130] In block 712, routine 700 involves the node identifying the device associated with the issuer identifier. For example, the node may perform a lookup to determine the server associated with the issuer identifier and the function to be performed.

[0131] In block 714, routine 700 communicates with the device for the node to perform functions securely.

[0132] Figures 8A and 8B illustrate an example of a system 800 configured in accordance with the embodiments described herein. In some cases, system 800 may be a more detailed view of system 100 and its components. The illustrated system 800 includes one or more systems for processing transactions, performing a validity confirmation function, and supporting other functions involving contactless cards issued in a multi-issuer environment. In an embodiment, system 800 includes one or more issuer systems 202, a personalization system 804, one or more merchant systems 806, and a switchboard system 830. The switchboard system 830 may include additional systems for providing functions to multiple issuer systems, and these systems may include switchboard nodes configured to route messages and communicate with other systems.

[0133] These systems may be composed of hardware and software components to perform the functions described herein. For example, each system may be composed of one or more servers, processors, memories, storages, network hardware, input / output devices, etc. to process instructions in accordance with the embodiments. Additionally, each system may support and implement several application programming interfaces (APIs) configured to enable interoperability between systems while maintaining a high level of security.

[0134] In an embodiment, system 800 includes at least one issuer system 802. The issuer system 802 has several components and may provide functions such as issuing a contactless card to a customer, authenticating the customer, conducting transactions, and enabling operations by tapping other contactless cards. In one example, the issuer system 802 includes functions for issuing a card, including processing network contactless card requests, maintaining a recording system (SoR), and providing a provisioning service.

[0135] In one example, to issue a card, the issuer system 802 may generate a unique identifier (pUID) for the card, and each identifier may be associated with a cardholder and a contactless card when issued. The pUID may be used as part of a validation process, and the issuer system 802 may store the pUID in a database associated with, for example, the cardholder. The pUID may be written to the SoR and provided to the personalization system 804 to physically generate and issue the contactless card. In some cases, the pUID may be communicated to the personalization system 804 in batches or batch files. For example, the issuer system 802 may include a process for generating a batch of pUIDs and a function for communicating the batch, such as an emboss file batch, to the personalization system 804. As described in more detail below, the personalization system 804 may configure, physically generate, and issue the contactless card.

[0136] In some embodiments, the issuer system 802 may provide additional features. In some cases, the issuer system 802 may maintain at least a portion of the functionality to perform customer validation operations after a contactless card has been issued. For example, the issuer system 802 may include functionality and APIs that a device, such as a mobile device executing the issuer mobile app 810, may use to validate information received initially from a contactless card. The device may communicate data from the contactless card to the issuer system 802 via one or more APIs, such as those provided by the MFA service 814, and the issuer system 802 may validate the information based on information stored in a database. The issuer system 802 may return the result to the device.

[0137] In some cases, the issuer network 802 may include one or more commerce APIs configured to provide commerce services, such as providing PII during a transaction, providing PII for auto-populating a form, providing a VCN for conducting a transaction or auto-populating a form. In some cases, these commerce APIs may be hosted outside of the issuer network 802 by a third-party service, such as under the service 834.

[0138] In some cases, the issuer system 802 may delegate the validation operation to the service 834. In these cases, the issuer system 802 may still receive data from the contactless card via an API by a device, such as a mobile device. In that case, the issuer system 802 may be configured to send the data to the service 834, and the service 834 may perform the validation operation. In either case, the issuer system 802 may return the result of the validation to the device. A device, such as a mobile device, may use the result, for example, as part of a validation request to access a mobile app, as part of a multi-factor authentication operation, or to enable the execution of another function.

[0139] In an embodiment, system 800 includes a personalization system 804 for performing operations on contactless cards to issue contactless cards to customers. For example, the personalization system 804 may obtain and / or generate data that can be copied to each contactless card for each customer. The data may be unique to each customer and may include information such as an account number, the customer's name, an expiration date, a card verification value (CVV), etc. In an embodiment, the personalization system 804 may store the data in a secure memory such as a hardware security module (HSM) of the contactless card. The data may also be provided to the issuer system 802 and / or service 834 so that they can perform contactless card operations, such as validity confirmation, authentication, tap operations, etc.

[0140] The personalization system 804 may also generate a key unique to each contactless card. Each contactless card may have a unique key pair that can be further used to generate a derived key for performing encryption operations for the card to communicate data in a secure manner. Each of the unique keys of the card may be based on and / or associated with the issuer bank. Additionally, the issuer system 802 and / or the switchboard system 830 may have a unique key set for each card that they can use to perform validity confirmation operations by being able to generate the same derived key to decrypt data received from the contactless card during validity confirmation or transaction processes.

[0141] The personalization system 804 may also install one or more applets on the card. The applets can be used to perform various functions including performing encryption operations, generating messages and ciphertexts containing data for card verification and transactions. In some cases, the personalization system 804 may install an applet that performs functions and includes an applet version number. System versioning may be required so that other systems can operate accordingly. The system version determines the applet version to be embedded in the card by the personalization system 804 and the validation logic. For example, a first-party system may operate under version 0100, and the use of a central system may operate under a different version, e.g., version 0200, to simplify implementation and enable the use of an authentication network. The JavaCard and MultOS implementations of the applet may share the same version number.

[0142] The personalization system 804 may also include additional applets for performing additional functions. For example, each card may include an applet configured to communicate with other devices, either wired and / or wirelessly. In some cases, the communication may be based on the Europay, Mastercard, Visa, (EMV) standards, the ISO / IEC 7816 standard for contact cards, and the ISO / IEC 14443 standard for contactless cards.

[0143] System 800 further includes a switchboard system 830 and a service system 834 to enable multiple banks or issuers to provide execution functions such as validity confirmation, transactions, etc. by tapping an NFC card while maintaining a high level of data security and separation between the data of each issuer. For example, the switchboard system 830 and the service system 834 provide a set of functions and APIs configured to provide services to multiple issuers to perform validity confirmation operations, transaction operations, and other NFC card operations. In some cases, the switchboard system 830 may be maintained and provided by a central system owned and operated by an entity separate from any of the card issuers.

[0144] In an embodiment, the switchboard system 830 may include several components and systems including a routing service, a workflow service, an administration service, an authentication service, a usage service, an analysis service, and an administration service 818.

[0145] In an embodiment, the switchboard system 830 and the service are configured to enable multiple issuers to operate together. For example, the switchboard system 830 is configured to route messages and data from devices and NFC cards to the corresponding services of the card issuers, such as service 834. For example, Bank A may issue an NFC card and provide Service A, and the switchboard system 830 is configured to process messages and data from the NFC card issued by Bank A for Service A. In an embodiment, the switchboard system 830 may utilize the information within the messages and data to determine where to send them.

[0146] The switchboard system 830 and services also enable the merchant system 806 to process transactions of multiple different issuers. For example, the switchboard system 830 may include an API that can be used to obtain PII associated with a cardholder by a merchant backend for conducting transactions. The switchboard system 830 may also include an API configured to initiate a session, such as a transaction session, and provide a validity confirmation token to a merchant app on a mobile device based on a contactless card used on the mobile device.

[0147] The switchboard system 830 also includes a validity confirmation function and a validity confirmation API, such as the validity confirmation service 820, for performing validity confirmation operations. The switchboard system 830 may also be coupled with a message validity confirmation service 824 configured to communicate with the validity confirmation function / API to provide a ciphertext validity confirmation service 826. The ciphertext validity confirmation service 826 includes a tap algorithm and is coupled with a validity confirmation HSM 828 for performing validity confirmation operations. Each API will be described in more detail in the following description.

[0148] In an embodiment, system 800 includes several systems for providing functions and services using contactless cards. At least some of these services may be performed using another device such as a contactless card and a mobile device. As will be described in more detail, the mobile device may execute one or more apps configured to operate with the functions and APIs provided by system 800. In one example, one or more apps may be developed using a software development kit that includes instructions and functions for operating with the functions and APIs. The mobile apps may include an issuer mobile app 810 such as a banking app, and a merchant mobile app 812. However, the embodiments are not so limited, and other applications such as a web browser, a mini app or a micro app (e.g., app clip), and an operating system may be configured to operate and utilize the functions provided by system 800.

[0149] System 800 provides many benefits. For example, under certain exemplary applets or application versions, validity verification may require access to a database, and a new contactless card can be added to the database during personalization. This dependency between personalization and validity verification may be undesirable in some cases, such as when the personalization function and the validity verification function are performed by different parties and / or entities. Using system 800, under other exemplary applets or application versions, validity verification does not require access to a database and instead uses only data from the data payload and / or another message. In these embodiments, personalization and validity verification may be decoupled, and the above dependency may be eliminated.

[0150] In embodiments of system 800, the shared secret is not transmitted between devices and is not recorded in a database. In these embodiments, instead of being stored in and retrieved from a database, the shared secret can be modified to be derived from a master key. In some embodiments, modifying the shared secret is not a change to an applet or other software application.

[0151] Deriving the shared secret from the master key can provide several advantages, including eliminating the need to store the card-level secret in a database. This can further remove the need to transmit the shared secret between devices (e.g., between a contactless card and a client device). Additionally, this can protect the secrets within the request data communicated between devices (e.g., contactless card request data).

[0152] In an embodiment, the shared secret can be derived from a third key. The third key may be a key that has been previously used to perform operations related to the contactless card and / or client device, or the third key may be a key that has not been previously used. In some examples, the shared secret may be personalized to the applet or other software application as appropriate, such that the need to modify the applet or other software application can be avoided. The shared secret can be encrypted before including the contactless card to minimize traces for potential attacks.

[0153] Thus, embodiments of system 800 have the benefit that personalization and authentication operate independently.

[0154] FIG. 9 shows an exemplary configuration of a contactless card 102 according to the embodiments described herein. The contactless card 102 may include a payment card such as a contactless card, credit card, debit card, or gift card issued by a service provider or issuer displayed as a service provider mark 902 on the front or back of the contactless card 102. In some examples, the contactless card 102 is not related to a payment card and is not limited thereto, and may include, for example, an identification card, a membership card, and a hotel key card. In some examples, the transaction card may include a dual interface contactless payment card, a point card, and the like. The contactless card 102 may include a substrate 908 that may include a single layer or one or more laminations composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 102 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7816 standard, and the transaction card may not, and may conform to the ISO / IEC 14443 standard. However, it is understood that the contactless card 102 according to the present disclosure may have different characteristics, and the present disclosure does not require that the transaction card be implemented in a payment card.

[0155] The contactless card 102 may also include identification information 906 displayed on the front and / or back of the card, as well as contact pads 904. The contact pads 904 may include one or more pads and may be configured to establish contact with another client device such as an ATM, a user device, a smartphone, a laptop, a desktop, a mobile device, or a tablet computer via a transaction card. The contact pads may be designed according to one or more standards such as the ISO / IEC 7816 standard and may enable communication according to the EMV protocol. The contactless card 102 may also include a processing circuit, an antenna, and other components, as further described in FIG. 10. These components may be located behind the contact pads 904 or elsewhere on the substrate 908, such as in a different layer of the substrate 908, and may be electrically and physically coupled to the contact pads 904. The contactless card 102 may also include a magnetic stripe or tape, which may be located on the back of the card (not shown in FIG. 8). The contactless card 102 may also include a near field communication (NFC) device coupled to an antenna capable of communicating via the NFC protocol. Embodiments are not so limited.

[0156] As shown in FIG. 8, the contact pads 904 of the contactless card 102 may include a processing circuit 1016 for storing, processing, and communicating information, including a processor 1002, a memory 1004, and one or more interfaces 1006. It is understood that the processing circuit 1016 may include additional components as necessary to perform the functions described herein, including a processor, a memory, a hardware security module (HSM), an error and parity / CRC checker, a data encoder, a collision prevention algorithm, a controller, a command decoder, security primitives, and anti-tampering hardware.

[0157] Memory 1004 may be a read-only memory, a write-once / read-multiple memory, or a read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 102 may include one or more of these memories. The read-only memory may be programmable at the factory as read-only or one-time programmable. The one-time programmable provides the opportunity to read multiple times after being written once. The write-once / read-multiple memory can be programmed at a point after the memory chip leaves the factory, for example, in the personalization system 804. Once the memory is programmed, it cannot be rewritten but can be read multiple times. The read / write memory can be programmed and reprogrammed multiple times after leaving the factory. The read / write memory can also be read multiple times after leaving the factory. In some cases, the memory 1004 may be an encrypted memory that utilizes an encryption algorithm executed by the processor 1002 for encrypted data. In some embodiments, at least a portion of the memory can be implemented as part of an HSM to store secret data such as the master key of the card.

[0158] Memory 1004 can be configured to store one or more applets 1008, one or more counters 1010, a customer identifier 1014, and an account number 1012, which can be a virtual account number. In some cases, the customer identifier 1014 may be a unique identifier of the card, such as a pUID. Memory 1004 can be configured to store additional information such as a version identifier for identifying the applet version, an issuer identifier for identifying the issuer or bank, and one or more key identifiers.

[0159] One or more applets 1008 may include one or more software applications configured to execute on one or more contactless cards, such as Java (registered trademark) Card applets. However, it is understood that the applets 1008 are not limited to Java Card applets, and instead may be any software application operable on a contactless card or other device having limited memory. One or more counters 1010 may include numeric counters sufficient to store integers. The customer identifier 1014 may include a unique alphanumeric identifier assigned to a user of the contactless card 102, and the identifier may distinguish the user of the contactless card from other contactless card users and / or one contactless card from another contactless card. In some examples, the customer identifier 1014 may identify both the customer and the account assigned to that customer, and may further identify the contactless card 102 associated with the customer's account.

[0160] As described above, the account number 1012 may include thousands of one-time virtual account numbers associated with the contactless card 102. The applet 1008 of the contactless card 102 may be configured to manage the account number 1012 (e.g., select the account number 1012, mark the selected account number 1012 as used, and transmit the account number 1012 to a mobile device for automatic entry by an automatic entry service).

[0161] Although the processor 1002 and memory elements of the foregoing exemplary embodiments have been described with reference to the contact pads 904, the present disclosure is not limited thereto. It is understood that these elements may be implemented as additional elements in addition to the processor 1002 and memory 1004 elements disposed outside the contact pads 904, or completely separated from the contact pads 904, or within the contact pads 904.

[0162] In some examples, the contactless card 102 may include one or more antennas 1018. The one or more antennas 1018 may be disposed around the processing circuit 1016 of the contact pad 904 within the contactless card 102. For example, the one or more antennas 1018 may be integral with the processing circuit 1016, or the one or more antennas 1018 may be used with an external booster coil. As another example, the one or more antennas 1018 may be external to the contact pad 904 and the processing circuit 1016.

[0163] In one embodiment, the coil of the contactless card 102 may function as the secondary of an air-core transformer. The terminal may communicate with the contactless card 102 by means of chopped power or amplitude modulation. The contactless card 102 may infer data transmitted from the terminal using the gap in the power connection of the contactless card that is functionally maintained via one or more capacitors. The contactless card 102 may reply by switching the load or load modulation of the coil of the contactless card. The load modulation may be detected in the coil of the terminal by interference. More generally, using the antenna 1018, the processor 1002, and / or the memory 1004, the contactless card 101 provides a communication interface for communicating via NFC, Bluetooth, and / or Wi-Fi communications.

[0164] As described above, the contactless card 102 may be built on a software platform that can operate on other devices with limited memory, such as a smart card or JavaCard, and one or more or multiple applications or applets can be securely executed. To provide one-time passwords (OTPs) for multi-factor authentication (MFA) in various mobile application-based use cases, an applet 1008 can be added to the contactless card. The applet 1008 can be configured to respond to one or more requests, such as a short-range wireless data exchange request from a reader, such as a mobile NFC reader (e.g., of a mobile device or a point-of-sale terminal), and generate an NDEF message containing an encrypted and secure OTP encoded as an NDEF text tag. FIG. 6 shows an example of a message that can be generated by the contactless card 102 and communicated for validity verification operations and transaction operations.

[0165] An example of an NDEF OTP is an NDEF short record layout (SR = 1). In such an example, one or more applets 1008 can be configured to encode the OTP as a well-known type of text tag of NDEF type 4. In some examples, the NDEF message can include one or more records. The applet 1008 can be configured to add one or more static tag records in addition to the OTP record.

[0166] In some examples, one or more applets 1008 can be configured to emulate an RFID tag. The RFID tag can include one or more polymorphic tags. In some examples, each time the tag is read, different cryptographic data can be presented that can indicate the authenticity of the contactless card. Based on one or more applets 1008, the NFC reading of the tag can be processed, the data can be sent to a server, such as a server of a banking system, and the data can be verified for validity at the server.

[0167] In some examples, the contactless card 102 and the issuer system 802 and / or the switchboard system 830 may contain specific data so that the card can be properly identified. The contactless card 102 may include one or more unique identifiers (not shown). Each time a read operation is performed, the counter 1010 may be configured to increment. In some examples, each time data from the contactless card 102 is read (e.g., by a mobile device), the counter 1010 is sent to a validation service for validation, and it is determined whether the counter 1010 is equal to the counter of the issuer system 802 and / or the switchboard system 830 (as part of the validation).

[0168] One or more counters 1010 may be configured to prevent replay attacks. For example, if a ciphertext is obtained and replayed, the ciphertext will be immediately rejected if the counter 1010 has been read, used, or otherwise passed. If the counter 1010 has not been used, the ciphertext may be replayed. In some examples, the counter incremented on the card is different from the counter incremented for a transaction. Since there is no communication between the applets 1008 on the contactless card 102, the application transaction counter 1010 cannot be determined.

[0169] In some examples, the counter 1010 may become unsynchronized. In some examples, the counter 1010 may increment to account for accidental reads that start a transaction, such as a read at a certain angle, but the application does not process the counter 1010. In some examples, when the mobile device 10 is powered on, NFC is made available and the device 110 may be configured to read available tags, but no action is taken in response to the read.

[0170] To synchronize counter 1010, an application such as a background application may be executed that is configured to synchronize with an issuer system 802 and / or a switchboard system 830 that detects when the mobile device 110 is started and then indicates a reading generated by the detection to move counter 104 forward. In other examples, a hashed one-time password may be utilized so that a window of mis-synchronization can be accepted. For example, if within a threshold of 10, counter 1010 may be configured to move forward. However, if within a different number of thresholds, e.g., within 10 or within 1000, a request for re-synchronization may be processed that requests the user to tap, gesture, or otherwise indicate one or more times via the user's device through one or more applications. If counter 1010 increases in an appropriate sequence, it is possible for the user to know that.

[0171] The key diversification techniques described herein with respect to counter 1010, the master key, and the derived key are an example of the encryption and / or decryption of key diversification techniques. This exemplary key diversification technique should not be considered as limiting the present disclosure as the present disclosure is equally applicable to other types of key diversification techniques.

[0172] During the creation process of the contactless card 102, two cryptographic keys can be uniquely assigned for each card. The cryptographic keys can include symmetric keys that can be used for both encryption and decryption of data. The Triple DES (3DES) algorithm may be used by EMV and implemented by the hardware within the contactless card 102. By using a key diversification process, one or more keys can be derived from one or more master keys based on uniquely identifiable information for each entity that requires a key. In some cases, the one or more master keys may be based on an issuer identifier such as the issuer's BIN.

[0173] In some examples, to overcome the drawbacks of the 3DES algorithm that may be susceptible to vulnerabilities, a session key (such as a unique key per session) can be derived, but instead of using a master key, a unique card-derived key and a counter can be used as diversification data. For example, each time the contactless card 102 is in operation, different keys may be used to create a message authentication code (MAC) and for encryption. This results in three layers of cryptography. The session key can be generated by one or more applets and can be derived by using an application transaction counter with one or more algorithms.

[0174] Furthermore, the increment for each card may be unique, may be assigned by personalization, or may be algorithmically assigned by some identification information. For example, odd-numbered cards may increment by 2 each time, and even-numbered cards may increment by 5 each time. In some examples, the increment may also vary in successive reads such that one card can increment successively by 1, 3, 5, 2, 2,... A specific sequence or algorithm sequence can be defined at the time of personalization or from one or more processes derived from a unique identifier. This can make it more difficult for a replay attacker to generalize from a small number of card instances.

[0175] The authentication message can be delivered as the content of a text NDEF record in hexadecimal ASCII format. In another example, the NDEF record can be encoded in hexadecimal format.

[0176] FIG. 11 is a timing diagram showing an exemplary sequence for providing data between a contactless card and a client device according to one or more embodiments of the present disclosure. Sequence flow 1100 may include communication between contactless card 102 and client device 1102. Client device 1102 may include application 1104 and processor 1106. In an embodiment, application 1104 may be a banking application or an issuer application. Other examples of applications include merchant applications, web browsers, game applications, and the like. In an embodiment, client device 1102 may include any number of applications, and the embodiments are not so limited. In an embodiment, client device 1102 may be a mobile device, a point-of-sale terminal, a personal computer, or the like. Further, client device 1102 may include additional components such as additional applications, memory for storing instructions for processing by processor 1106, an interface, and the like.

[0177] At line 1108, application 1104 communicates with contactless card 102 (e.g., after being brought close to contactless card 102). In one example, the customer may be instructed to tap contactless card 102 on the surface of the device to ensure that the card enters the wireless communication range of the card. Communication between application 1104 and contactless card 102 may involve contactless card 102 being close enough to a card reader (not shown) of client device 1102 to enable NFC data transfer between application 1104 and contactless card 102. In some cases, communication between application 1104 and contactless card 102 may be performed via an operating system that supports wireless protocols such as NFC, Bluetooth, WiFi, and utilizes a wireless interface.

[0178] At line 1110, after communication is established between the client device 1102 and the contactless card 102, the contactless card 102 generates a message authentication code (MAC) ciphertext such as message 600. In some examples, this can be done when the contactless card 102 is read by the client device. In particular, this can be done upon reading, such as NFC reading of a Near Field Data Exchange (NDEF) tag that can be created according to the NFC data exchange format. For example, a reader application such as application 1104 may send a message such as an applet selection message having the applet ID of the NDEF generation applet. Upon confirmation of the selection, a sequence of a file selection message followed by a file read message may be sent. For example, the sequence may include "select function file", "read function file", and "select NDEF file". At this point, the counter value maintained by the contactless card 102 may be updated or incremented, and then "read NDEF file" may follow. At this point, a message such as message 600 that may include a header and a shared secret may be generated. Then, a session key may be generated. The MAC ciphertext may be created for a message that may include a header and a shared secret. The MAC ciphertext may then be concatenated with one or more blocks of random data, and the MAC ciphertext and random number (RND) may be encrypted with the session key. Thereafter, the ciphertext and the header are concatenated, encoded as ASCII hex, and may be returned in the NDEF message format (in response to the "read NDEF file" message). In some cases, the message communicated to the client device 1102 may include an encrypted portion and an unencrypted portion, as described herein.

[0179] In some examples, the MAC ciphertext may be sent as an NDEF tag, and in other examples, the MAC ciphertext may be included (e.g., as a formatted string) with a link or uniform resource indicator. In some examples, the application 1104 may be configured to send a request including instructions to generate a MAC ciphertext to the contactless card 102. In some examples, the MAC ciphertext may be included with additional data such as an applet version, an issuer identifier, a unique identifier of the card, and a key identifier, as shown in FIG. 6. In an embodiment, at least the applet version and the issuer identifier may not be encrypted in the unencrypted portion of the message. The applet version and / or the issuer identifier may be used by the switchboard system 118 to determine where to route the message.

[0180] At line 1112, the contactless card 102 sends a message including the MAC ciphertext to the application 1104. In some examples, the transmission of the MAC ciphertext is performed via NFC, but the present disclosure is not limited thereto. In other examples, this communication may be performed via Bluetooth, Wi-Fi, or other means of wireless data communication. At line 1114, the application 1104 communicates the message including the MAC ciphertext to the processor 1106.

[0181] In the illustrated sequence, at line 1116, client device 1102 including processor 1106 may verify a message containing content such as a MAC ciphertext according to instructions from application 1104. For example, the MAC ciphertext may be verified by being processed, for example, via switchboard system 118 and a verification service as described below. In some examples, verifying the MAC ciphertext may be performed by client device 1102 or another device such as a server of a banking system, issuer system 802, or switchboard system 118 that communicates with client device 1102. For example, processor 1106 may output a message containing a MAC ciphertext for transmission to a server of issuer system or switchboard system 118 that may verify the data in the message including the MAC ciphertext, shared secret, and counter. In some examples, the MAC ciphertext may function as a digital signature for verification. Other digital signature algorithms such as public key asymmetric algorithms, for example, digital signature algorithm or RSA algorithm, or zero knowledge protocols may be used to perform this verification.

[0182] In an embodiment, the exchange between the contactless card 102 and the client device 1102 can be performed to execute any number of functions described herein. As described, embodiments utilize a contactless card 102 and include tapping the card on a device to perform a validation operation, such as MFA. In another example, the contactless card 102 can be used to conduct a transaction for an item or service. There are also other functions performed by tapping, including automatically entering one or more fields by a tap operation, launching an application by a tap operation, initializing a contactless card by a tap operation, installing an application by a tap operation, opening a door by a tap operation, starting / entering a vehicle by a tap operation, unlocking a device by a tap operation, etc. Embodiments are not limited to these examples. One or more operations described with respect to the sequence flow 1100 can be performed as part of the functional operation by a tap operation.

[0183] As described above, the systems described herein are configured to support any number of tap operation functions using a contactless card, such as authentication / validation, conducting a transaction, automatically entering a field, etc. FIG. 12 shows an example of a routine 1200 that can be performed by the systems herein to perform authentication or validation using a contactless card. In the illustrated example, the system can receive contactless card information from a contactless card via a device such as a mobile device or a POS terminal. The system can process the information to determine whether it is authentic and generate a result. If the card is authenticated, the result can include a generated validation token indicating that the card has been successfully validated. In some cases, as described in more detail with respect to FIG. 14 and routine 1400, the validation token may be used to perform additional functions such as conducting a transaction. Other functions include opening a door, obtaining information, automatically entering a field, launching an application, providing multi-factor authentication, etc.

[0184] In block 1202, routine 1200 includes receiving, by the system, a request that includes a message associated with performing a validity check. In an embodiment, the request can be sent to the switchboard system 1808 via a post to an API. Specifically, the switchboard system 1808 can include a set of APIs configured to receive the request and provide a response for authenticating the user. In this example, the request can be a validity check or an authentication and can include a message having an encrypted portion and an unencrypted portion. In some embodiments, the request can also include a session token and extensions. The following is an example of the format of the request.

[0185] POST / Validity Check

[0186] { ’’tapMessage’’:’’encrypted_portion / decrypted_portion’’,

[0187] ’’sessionToken’’:’’abcdefg...’’ / / Token from session initialization

[0188] ’’extensions’’:{...}}

[0189] Note that the embodiments are not limited to this example. In an embodiment, the encrypted portion of the message can be used by the switchboard system 1808 for authentication, and the decrypted or unencrypted portion can be used by the switchboard system 1808 to route the message to an appropriate process for performing authentication. FIG. 6 shows an example of a message 600. In an embodiment, the unencrypted portion can be utilized by the system to determine at least where to route the message for performing a validity check.

[0190] In some cases, it may be necessary to first establish a client session between the device and the system in order to obtain a validity confirmation token. In these cases, the device may send a request or post to a session initialization API that may include usage information for the validity confirmation token. For example, the validity confirmation token may be utilized as part of a transaction, and session initialization may be established by posting information such as client information including one or more of a merchant identifier, a reader identifier, and an Internet Protocol (IP) address, geographical location information, a device identifier, a user agent, and a host name to the API. The post to establish a session for conducting a transaction may have the following format, but is not limited to this method.

[0191] POST / session{

[0192] ’’merchantId’’:’’3fa85f64-5717-4562-b3fc-2c963f66afa6’’,

[0193] ’’readerId’’:’’3fa85f64-5717-4562-b3fc-2c963f66afa6’’,

[0194] ’’clientInformation’’:{ ’’ipAddress’’:’’198.xx.xxx.xx’’,’’geolocation’’:{},’’device’’:{},’’userAgent’’:’’string’’,’’hostname’’:’’example.com’’}}

[0195] In an embodiment, the switchboard system 1808 may perform one or more operations to process the post and determine a risk factor based on a determination of whether to issue client information and a session token. In response, the system may return a session token in the form of a JavaScript Object Notation (JSON) Web Token (JWT).

[0196] {"sessionToken":" <jwt>’’

[0197] ’’valid’’: true,

[0198] ’’validUntil’’: ’’2022-02-04T19:15:39.693Z’’}

[0199] Furthermore, the session token JWT signed by the session API may contain the following embedded details.

[0200] {iss: ’’, / / Identifies the issuer of the JWT, same for all JWTs

[0201] sub: ’ <uuid>’, / / A randomly generated UUID representing the session ID

[0202] exp: 1648217401, / / An epoch timestamp representing the time when this JWT expires

[0203] merchantId: <merchantiduuid>, / / Merchant ID from the request payload

[0204] readerId: <readeriduuid>, / / Reader ID from the request payload

[0205] creationTime: 1648217401, / / An epoch timestamp representing the point in time when the session was created}

[0206] As described above, the session token may also be included in a request for a validity token. In some cases, the session token may be included in a first request for a validity token but may not be required for future requests. In embodiments, the post and response for establishing a session may include different usage information based on what the session is being established for. For example, if the session is for performing validity verification or authentication, the post may include information about the requesting party. For example, assume that the session is established as part of an auto-fill process. In that case, the session is established as part of the auto-fill process, and the post may include usage information such as the website that receives the data. The requested data session is established as part of the auto-fill process, and the post may include usage information such as the website that receives the data, the data being requested, etc. Embodiments are not limited in this way.

[0207] In block 1204, routine 1200 includes determining, by the system, a validity verification service associated with the contactless card issuer based on information in the unencrypted portion of the message. For example, the switchboard system 1808 may determine the contactless card issuer based on the issuer identifier included in the message. The (one or more) validity verification services may include some processes and / or functions that may be executed to verify information in the encrypted portion of the message.

[0208] In block 1206, routine 1200 includes sending at least the encrypted portion of the message to the validity confirmation service. Since the validity confirmation service is associated with the contactless card issuer, it is possible to access the secure data associated with that particular issuer, but not the data associated with other issuers. Thus, the information of each issuing bank can be siloed to enhance data security.

[0209] In an embodiment, the validity confirmation service is configured to confirm the validity of information within the message, such as the MAC ciphertext, counter value, etc. The validity confirmation service may send the message or at least a portion of the message (e.g., the encrypted portion) to the message validity confirmation service 824 and the ciphertext validity confirmation service 826 to perform the validity confirmation as illustrated and described in FIGS. 13A and 13B.

[0210] In an embodiment, the validity confirmation service may determine the result of the validity confirmation operation performed by the message validity confirmation service 824 and the ciphertext validity confirmation service 826 and return the result. In some cases, the request may include an indication of whether the validity confirmation was successful. Additionally, the validity confirmation may determine and / or generate a validity confirmation token that can be returned to the system for return to the device.

[0211] In block 1208, routine 1200 includes generating a validity confirmation token based on the validity confirmation service's successful confirmation of the validity of the information in the encrypted portion of the message. The validity confirmation token may be in the JWT format as follows.

[0212] { iss:’’DistributionPartner’’, / / Unique identifier of the validity confirmation API implementer

[0213] exp:’’2022-02-04T16:57:19Z’’, / / Time when the validity token should expire (recommended 15-minute TTL)

[0214] puid:0123456789101112, / / Unique identifier of the tapped card

[0215] clientId: ’’3fa85f64-5717-4562-b3fc-2c963f66afa6’’, / / Unique identifier of the client

[0216] timeVerified: ’’2022-02-04T16:57:19Z’’ / / Time when the card was considered valid}

[0217] In block 1210, routine 1200 returns a validity confirmation token to the mobile device by the system. In an embodiment, the validity confirmation token may be a response to a post and may be in the following format.

[0218] { ’’requestId’’: ’’3fa85f64-5717-4562-b3fc-2c963f66afa6’’,

[0219] ’’valid’’: true,

[0220] ’’validityToken’’: ’’eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ...’’}

[0221] Note that if the (one or more) validity confirmation operations fail, routine 1100 may return a failure indication to the requesting device.

[0222] FIG. 12 includes routines performed by the switchboard system 1808 and a device such as a mobile device to verify the validity of contactless card information via the switchboard system 1808. However, in some cases, the device may directly send a request including a message to the issuer system 802, and the issuer system 802 may route the message through the validity verification service of the switchboard system 1808 to perform validity verification and receive a validity token. In still other cases, the issuer system 802 may perform validity verification itself and return an instruction regarding whether the contactless card is valid.

[0223] FIG. 13A shows a detailed view of a validity verification system 1304 that can perform one or more operations to verify the validity of information and can be part of the switchboard system 1808.

[0224] In some exemplary embodiments, the validity verification system 1304 includes a message validity verification service 824 configured to receive an incoming validity verification request, such as a message generated by a contactless card when performing a tap or NFC read, or at least an encrypted portion of the message. In one example, the request can be directed to the message validity verification service 824 based on processing performed by the switchboard system 1808 that processes the issuer identifier of the non-encrypted portion of the message, as described in FIGS. 4A-4C, for example, via a switchboard node. In some cases, the message can be received from another system such as the issuer system 802.

[0225] In an embodiment, the message validity confirmation service 824 may perform one or more services to perform an initial validity check of a message. For example, the message validity confirmation service 824 may analyze a message field to determine a unique identifier of the card, such as a pUID. The message validity confirmation service 824 may use the unique identifier as a key to retrieve associated card record data stored in a database such as the card database 1302, and perform a basic validity check using the record data. For example, the message validity confirmation service 824 may validate the information in the message against the information in the record, such as the app version, issuer ID, pKeyID, pUID, pATC, nonce, and / or pSHSEC. Additional information in the message may include account information, customer data, and / or card information, and the message validity confirmation service 824 may confirm that it matches the stored data of the card.

[0226] In an embodiment, the card database 1302 may store additional information such as personalization details of the card including the card platform and applet version (app version), and the message validity confirmation service 824 may also ensure that the card platform and / or applet version in the message match the stored information.

[0227] In some cases, the card database 1302 may also store an index or key identifier for retrieving the cryptographic key from the validity confirmation HSM 828, and an expected counter value. The cryptographic key may be used to decrypt the encrypted portion of the message. In some cases, the key identifier or index may be provided in a field of the message itself. The message validity confirmation service 824 may also check and confirm that the counter values are consecutive when the card record is found in the card database 1302.

[0228] In response to the initial validity confirmation being successful, the message validity confirmation service 824 records the validity confirmation request in the card database 1302 and requests the ciphertext validity confirmation service 826 to confirm the validity of the ciphertext and the information within the ciphertext.

[0229] In an embodiment, the message validity confirmation service 824 may also compare that the counter value within the message matches the counter value maintained in the card database 1302. In some cases, the counter value (pATC) on the card may become out of sync with the stored counter value, for example, an unregistered read. In these cases, the message validity confirmation service 824 may ensure that the card counter value is within an acceptable range of the stored counter value. In some cases, if the card counter value is outside the acceptable range of the stored counter value or less than the stored counter value, the message validity confirmation service 824 may determine that an irregularity has occurred.

[0230] In an embodiment, the basic validity check of the message validity check service 824 is successful, and the message validity check service 824 may record details of the transaction and validity check for auditability and communicate with the ciphertext validity check service 826 to check the validity of the ciphertext. To check the validity of the ciphertext, the ciphertext validity check service 826 may first generate one or more key pairs for decrypting the ciphertext. In some cases, the ciphertext validity check service 826 may use the key identifier of the unencrypted portion of the message to retrieve the master key associated with the issuer from the validity check HSM 828. The ciphertext validity check service 826 may use the master key to generate a derived key based on the card or unique identifier. The derived key may then generate a session key for a given session using a counter value maintained by the validity check system and / or provided in the message. The counter value needs to match or be within the range of the counter value of the contactless card. Note that in some embodiments, the ciphertext validity check service 826 may start with the derived key instead of the master key that may be stored in the validity check HSM 828 and then generate the session key. The embodiments are not limited in this way.

[0231] In an embodiment, the ciphertext validity check service 826 may decrypt the ciphertext with the decryption session key and compare the information from the ciphertext with the stored information, such as the information stored in the card database 1302. The information may include a shared secret. In some cases, the counter value may be in the encrypted portion of the message, and the ciphertext validity check service 826 may perform a validity check on the counter value.

[0232] In an embodiment, if additional information including a card identifier, an account number, a customer name, etc. is in the encrypted part, the ciphertext validity confirmation service 826 can also confirm their validity. If the ciphertext is successfully decrypted and the information matches, the ciphertext validity confirmation service 826 can confirm the validity of the message, and the validity confirmation service can return a successful validity confirmation result to the device. In some cases, the result may include a validity token that can be used to perform additional operations.

[0233] In some embodiments, the system 800 may utilize a validity confirmation HSM 828, which stores master keys used in cryptography and can be a payment-grade HSM that performs operations they are involved in, such as deriving other keys, encrypting, and decrypting. However, payment-grade HSMs are very restricted and require a proprietary library to interact with them. To avoid hardware dependencies and make the reference implementation easier, some embodiments use a Java key storage 1306 that follows the same steps but uses an open-source cryptographic library as shown in FIG. 13B. Embodiments are not limited in this way.

[0234] FIG. 14 shows an exemplary sequence diagram 1400 according to the embodiments described herein. The sequence diagram 1400 shows the high-level steps that can be taken to confirm the validity of a user and their contactless card with a switchboard system 1406. FIG. 14 shows one possible sequence, and embodiments are not limited to this sequence. In some cases, one or more steps may be performed before other steps and / or in parallel with each other.

[0235] At 1412, the client device 1404 receives a request asking to perform user authentication. For example, a mobile application such as a merchant application may generate a request asking to authenticate the user of the client device 1404 in order to conduct a transaction. In another example, the application may request to authenticate the user as part of a multi-factor authentication sequence. In a third example, the application may request to authenticate the user as part of a login sequence. The embodiments are not limited in this way. In some cases, the request may be generated by the user himself, for example via a user interface or by an external system such as a POS transaction system.

[0236] At 1414, the client device 1404 may generate a prompt to prompt the user to bring the contactless card 1402 within a specified range of the client device 1404. The prompt may be a visual prompt displayed on the display of the client device 1404 and / or an audio prompt played via a speaker. In some cases, the prompt may instruct the user to tap the card on the surface of the client device 1404.

[0237] At 1416, the client device 1404 can communicate and exchange with the contactless card 1402. For example, in response to the user bringing the contactless card 1402 within the distance of 1404, wireless communication and exchange can be performed between the client device 1404 and the contactless card 1402. The wireless exchange can follow wireless protocols such as Bluetooth, NFC, WiFi, etc. In some cases, the exchange may be a "wired" exchange based on the client device 1404 contacting the contact part of 1402. In an embodiment, the exchange can follow EMV with modifications to the message as described herein. In some cases, the client device 1404 may read and / or receive a message from the contactless card 1402. Additionally, the client device 1404 may also write and / or transmit data such as nonce to the card, which can be incorporated into the data read by the client device 1404.

[0238] In an embodiment, the client device 1404 can receive data from the contactless card 1402, such as in a message, as part of the exchange. The message can include, for example, an encrypted part such as a ciphertext and an unencrypted part. FIG. 6 shows an example of a message 600.

[0239] At 1418, the client device 1404 can send a request for validation to the switchboard system 1406. The request can include a message. As described in FIG. 11, the request may be a post to the API of the switchboard network 1408. At 1420, the switchboard network 1408 can determine where to route the request and which validation service will perform the validation. Specifically, the switchboard network 1408 can use the issuer identifier in the unencrypted part of the message to determine the issuer and its validation service.

[0240] At 1422, the hub network 1408 may send a message to the validation system 1410 to be validated. The validation system 1410 may process the message using services specifically assigned to the issuer and / or data associated with the issuer. At 1424, the validation system 1410 may perform one or more validations as described with respect to FIGS. 13A and 13B.

[0241] At 1426, the validation system 1410 may return the result of the validation to the switchboard network 1408, and the switchboard network 1408 may transfer the result to the client device 1404 at 1428. The result may include a validation token that can be used to validate the user. For example, the validation token may be used as a login for the user to log in to the application. In another example, the validation token may be provided to another system as part of an MFA sequence. In a third example, the validation token may be provided to an entry system to obtain access rights to a door or room. As described in more detail in FIG. 15, the validation token may be determined to conduct a transaction and then provided to the merchant system.

[0242] In an embodiment, the system 800 may be utilized to perform additional functions such as conducting transactions among a cardholder, an issuer, and a merchant. FIG. 15 shows an example of a routine 1500 that may be performed by a system 800 including a switchboard system 1808 to process merchant transactions. In some cases, the transaction may be initiated on a device such as a mobile device or a POS terminal.

[0243] In block 1502, routine 1500 includes receiving a request for non-contact cardholder information, which may include one or more indicators, a validity confirmation token, and encryption parameters. The request for information may be required to conduct a transaction. The one or more indicators may indicate what information is requested by the merchant system to conduct a transaction, e.g., fields. The information may include the customer's name (first, middle, last), date of birth, social security number, address, account number, non-contact card information (account number, cvv, expiration date), etc.

[0244] In an embodiment, the validity confirmation token may be a token provided by a system that can be used to perform a function, as described in FIGS. 12, 13A, 13B, and 14. The validity confirmation token indicates that the non-contact card is authenticated by the system. In some cases, the non-contact card may have been previously authenticated or may be authenticated as part of the transaction process.

[0245] The encryption parameters may include a merchant certificate that may have been previously provided to the merchant. For example, the system may provide a unique certificate to each merchant during the onboarding process. In addition to the merchant certificate, the encryption parameters may also include a public key and a public key signature. The public key signature can be used with the merchant to validate the public key.

[0246] In an embodiment, the request may be a POST to the API interface of the switchboard system 830. The following is an example of the format of an API POST according to an embodiment. Note that the embodiment is not limited in this way, and the request may be in other formats.

[0247] POST / cardholder-information

[0248] {"fields":["firstName","middleName","lastName","dob","ssn","address","card"], / / Fields returned from customer record

[0249] "validityToken":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ...",

[0250] "encryptionParameters":{"certificate":"-----BEGIN CERTIFICATE-----\nQWERT....",

[0251] "ephemeralPublicKey":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ...",

[0252] "publicKeySignature":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ... " / / Signature of the public key. It needs to be used together with the certificate to verify the validity of the public key

[0253] }}

[0254] In some cases, the customer may first have to consent before the information requested by the merchant is provided to the merchant. In one example, a merchant app on a device such as a mobile device or a POS device may confirm to the customer that they agree to provide information to the merchant. The merchant app may then send a consent message as an API post to System 800, for example, the switchboard system 830. The following is an example of the POST format.

[0255] POST / cardholder-information / consent

[0256] {"fields": ["firstName", "middleName", "lastName", "dob", "ssn", "address", "card"],

[0257] / / Fields returned from the customer record

[0258] "validityToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ...",

[0259] "sessionToken": "abc…" / / From session initialization

[0260] }

[0261] Consent may include instructions for information, validity tokens, and session tokens permitted to be provided to the merchant. In some cases, system 800 may send a confirmation request to the device, for example, via the issuer's mobile application. If consent is successfully given, system 800 may return a successful response to the consent for the sharing request. The following is an example of the response.

[0262] 700 OK

[0263] {"requestId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",

[0264] "success": true}

[0265] In block 1504, routine 1500 includes determining a commercial transaction service associated with the contactless card issuer. For example, the switchboard system 830 may perform a lookup to determine which issuer is associated with the contactless card based on the information within the cardholder information request. In a specific example, the switchboard system 830 may utilize a validity token to determine the issuer. As described, the validity token includes information such as the issuer and distribution partner, and the switchboard system 830 may utilize that information to determine the (one or more) associated commercial transaction services to further process the request.

[0266] In block 1506, routine 1500 includes sending at least a portion of the request to the commercial transaction service. The commercial transaction service may be part of the switchboard system 1808 such as, for example, a "merchant / commercial transaction api" and may perform one or more operations. Specifically, the commercial transaction service may verify the validity of the validity token and the information within the validity token. In an embodiment, the validity token may be encrypted via a public key obtained by the merchant and communicated to the (one or more) commercial transaction services. The (one or more) commercial transaction services may include an associated private key and may decrypt the information within the token before verifying its validity.

[0267] (One or more) commercial transaction services may also ensure that the cardholder has consented to the provision of the requested information. For example, the commercial transaction service may ensure that the customer has consented to the sharing of records on the service system 734.

[0268] In an embodiment, the (one or more) commerce services may be configured to obtain the requested data in response to validating a validity token and the customer agreeing to share. In some cases, the commerce service may obtain information from the issuer system 802 via an API. For example, the commerce service may send a request to the issuer system 802 that may include one or more indicators, a validity token, and encryption parameters. In an embodiment, the issuer system 802 may validate a merchant certificate based on information provided by the merchant during an onboarding process.

[0269] The issuer system 802 may also obtain the requested information from one or more data stores, such as a database. The information may then be encrypted by the issuer system 802 such that the switchboard system 830 cannot "see" or decrypt the information. Thus, the customer's information is securely maintained by the issuer system 802 and / or the switchboard system 830 is only visible to the merchant system conducting the transaction.

[0270] In one example, the issuer system 802 may generate an Elliptic Curve Diffie-Hellman (ECDH) secret and encrypt the requested cardholder data. The issuer system 802 may return the encrypted data and a contactless card issuer certificate to the commerce service and the switchboard system 830. Further, in block 908, routine 1500 includes receiving, for example, contactless cardholder information and a contactless card issuer certificate from the issuer system 802.

[0271] In block 1510, routine 1500 includes sending a response to a request for non-contact cardholder information to the merchant system. The response may include encrypted cardholder information. Thus, the information can be securely passed between the issuer system 802 and the merchant system 806. The response may include a request identifier that identifies the associated request (see block 1502), an indication as to whether the request was successful, and additional information such as encryption parameters. The encryption parameters may include a public key, an issuer certificate, and a public key signature for verifying the public key with the issuer certificate. The public key, the public key signature, or both may be encrypted with the merchant's public key so that only the merchant system 806 can decrypt the public key and signature. The unencrypted public key may be used to encrypt the information to be sent to the issuer system 802, and the issuer system 802 may decrypt the information with the issuer's private key.

[0272] The merchant system 806 may verify the validity of the issuer certificate based on the information exchanged between the merchant system 806 and the issuer system 802 during the onboarding process. The merchant system 806 may decrypt the public key and signature with the merchant's private key to obtain the key and signature. The signature by the certificate may be used to verify the issuer's public key. The following is an example of a response. Note that the embodiments are not limited to this method, and the response may take different formats.

[0273] {’’requestId’’:’’3fa85f64-5717-4562-b3fc-2c963f66afa6’’,

[0274] ’’success’’:true,

[0275] ’’cardholderInformation’’:’’eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ....’’, / / Encrypted cardholder information

[0276] "encryptionParameters": { "ephemeralPublicKey": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ...." / / Ephemeral key encrypted with the merchant's public key

[0277] "certificate": "-----BEGIN CERTIFICATE-----\nQWERT....",

[0278] "publicKeySignature": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ... " / / Signature of the public key. It needs to be used together with the certificate to verify the validity of the public key

[0279] }

[0280] In an embodiment, the merchant system 806 may receive encrypted cardholder information and decrypt it with the merchant's private key. In an embodiment, the merchant system 806 may use the information to conduct a transaction or perform another function such as saving the information in a secure data store for future use, e.g., filling in one or more fields of a checkout form.

[0281] FIG. 16 shows an example of a sequence diagram 1600 performed according to an embodiment. The sequence may occur between the systems described herein as part of a transaction process for a merchant to obtain information for conducting a transaction using a validity confirmation token.

[0282] At 1614, the client device 1602 may send a request to the merchant system 1604 to conduct a transaction. The transaction may be for the purchase of goods or services, and embodiments are not so limited. In an embodiment, the request may include information regarding the transaction, identifiers, item(s) for purchase, customer information, etc. In an embodiment, the request may also include a validity confirmation token that may be used by the merchant system 1604 to conduct transactions with backend banking systems such as, for example, the switchboard system 1606 and the issuer system 1612. The validity confirmation token may have been previously obtained according to the processing flow and sequence described above.

[0283] At 1616, the merchant system 1604 may send a request for information to conduct a transaction to the switchboard 1608 of the switchboard system 1606. The request may be an API POST and may include the requested information (fields), the validity confirmation token, and a list of encryption information that may be used to encrypt the requested information. FIG. 14 illustrates an exemplary API POST format according to an embodiment at block 1402.

[0284] At 1618, the switchboard system 1608 may utilize the information within the request to determine the issuer and / or merchant trading system associated with the transaction. For example, the switchboard system 1608 may utilize the validity confirmation token to determine the associated issuer bank and corresponding merchant trading system.

[0285] In 1620, the switchboard system 1608 may send a request to the determined commerce system 1610, asking the commerce system 1610 to process a request and determine information. Further, in 1622, the commerce system 1610 may send a request to the issuer system 1612, asking for the requested information. The request may include encryption information used to encrypt the information requested by the issuer system 1612 such that the data remains secure and unidentifiable until the merchant system 1604 receives and decrypts the information, as described in FIG. 14.

[0286] In 1624, the issuer system 1612 may determine information based on the request and encrypt the information. The encrypted information may be returned to the commerce system 1610 in 1626. The commerce system 1610 may send the encrypted information to the switchboard system 1808 in 1628. The encrypted information remains secure, and neither the switchboard system 1606 of the system has the ability to decrypt the information. Also, the information remains secure until it is decrypted by the merchant system 1604. In 1630, the switchboard system 1808 may send the encrypted information to the merchant system 1604. The merchant system 1604 may decrypt the information and use the information to complete the transaction in 1632.

[0287] FIG. 17 shows an example of a simplified processing flow 1700 that may be performed according to an embodiment. Specifically, the processing flow 1700 may be performed in an environment that uses the switchboard system 108 / 208 to provide processing and communication in a multi-bank issuing system environment. The processing flow 1700 is an example of a flow for performing a transaction between a merchant and a customer using a contactless card issued by one of a plurality of issuing banks and includes both obtaining a validity confirmation token (as described, for example, in FIGS. 7, 8A, and 8B) and obtaining transaction information (as described, for example, in FIGS. 10 and 11).

[0288] At line 1702, the user may tap their contactless card on the mobile device 104. In one example, the user may tap their contactless card on the device in response to a mobile app presenting a prompt that encourages the user to tap the card. The contactless card provides data to the mobile device 104, and the mobile device 104 may transfer the data to the switchboard system 1708. The data may include encrypted and unencrypted data in a message such as message 900b.

[0289] At line 1704, the switchboard system 1708 may utilize the data within the message to determine a card validator, such as a validity confirmation service. For example, the switchboard system 1708 may perform a lookup with unencrypted data, such as an issuer ID, to determine a validity confirmation service 820 for routing the message.

[0290] The switchboard system 1708 may send the message to a corresponding validity confirmation service 820 that includes a validity confirmation API configured to process messages that include an encrypted portion. Specifically, the corresponding validity confirmation service 820 may decrypt the encrypted portion and authenticate the data, as described, for example, in FIG. 13A or FIG. 13B.

[0291] At line 1706, the validity confirmation service 820 may return a validity token to the switchboard system 1708 and the mobile device 104. At line 1710, the merchant system 806 requests user / consumer information from the switchboard system 1708 in a request for cardholder information that includes the validity token and other data, as explained in FIG. 14. The switchboard system 1708 may perform a lookup with the corresponding card issuer based on the information received from the merchant system 806, such as the validity token.

[0292] Switchboard system 1808 communicates with the issuer network and the corresponding card issuer's commercial services on line 1714 and receives encrypted user / consumer information. The switchboard system 1808 may return the encrypted user / consumer to the merchant system 806, and the merchant system 806 decrypts the information to perform a transaction or another function.

[0293] FIG. 18 shows a simplified example of an encryption flow 1800 that can be performed in accordance with the embodiments described herein to ensure that data communicated between an issuer system and a destination system such as merchant system 1814 is secure. At 1802, merchant 1814 requests cardholder information from switchboard system 1816 in a request message, for example, via an API. At 1804, encryption flow 1800 includes the switchboard system 1816 performing a lookup to determine which card issuer and which commerce API 1818 will route the data. The data is communicated to the associated commerce API service. At 1806, the certification authority 1820 validates the merchant certificate and / or a result is returned. At 1808, the flow includes the service 1818 generating an EDCH secret (or public / private key pair) and encrypting the cardholder data. The cardholder data is communicated to merchant 1814 at 1808. At 1810, encryption flow 1800 includes the merchant system validating the certificate. Further, at 1812, encryption flow 1800 includes the merchant generating an EDCH secret and decrypting the cardholder data.

[0294] FIG. 19 shows a distributed network authentication system 1900 according to an exemplary embodiment. As will be further described below, system 1900 may include client node 1902, API 1904, network 1906, distributed ledger node 1910, mapping 1912, and client device 1914. Although FIG. 19 shows a single instance of the components, system 1900 can include any number of components.

[0295] System 1900 can include client node 1902, which can be a network-enabled computer as described herein. In some examples, client node 1902 can be a dedicated server computer, a server that can be a blade server, or a personal computer, laptop computer, notebook computer, palm-top computer, network computer, mobile device, wearable device, or any processor-controlled device that can support system 1900.

[0296] In some examples, client node 1902 can execute one or more applications, such as a software application that enables network communication with one or more components of system 1900, send and / or receive data, and perform the functions and processes described herein.

[0297] The client node can include API1904. For example, various different APIs can be provided to an application that can interact with a service (e.g., an application running on a computing device such as a network-enabled computer). For example, an application running on a device (e.g., a smartphone, smartwatch, tablet, laptop, or other device) can call API1904 to interact with a service, for example, by making a remote call to an API for interacting with a web-based service to call and interact with the web-based service.

[0298] API1904 can be provided in the form of a library that includes specifications of routines, data structures, object classes, and variables. In some cases, for example, in the case of a REST (representational state transfer) service, an API (e.g., a REST API or RESTful API, or an API that embodies some RESTful approaches) is a specification of remote calls exposed to API consumers (e.g., an application running on a client computing device can be a consumer of a REST API by making a remote call to the REST API). A REST service generally refers to a software architecture for coordinating components, connectors, and / or other elements within a distributed system (e.g., a distributed hypermedia system).

[0299] The client node 1902 can communicate with one or more other components of the system 1900 directly or via the network 1906. The network 1906 can include one or more of a wireless network, a wired network, or any combination of a wireless network and a wired network, and can be configured to connect to the components of the system 1900. FIG. 19 shows the communication between the components of the system 1900 via the network 1906, but it is understood that any component of the system 1900 can communicate directly with another component of the system 1900 without involving the network 1906, for example.

[0300] The system 1900 can include a validation node 1908 that can be a network-enabled computer as described herein. In some examples, the validation node 1908 can be a dedicated server computer, a server that can be a blade server, or a personal computer, a laptop computer, a notebook computer, a palm-top computer, a network computer, a mobile device, a wearable device, or any processor-controlled device that can support the system 1900.

[0301] In some examples, the validation node 1908 can execute one or more applications, such as a software application that enables network communication with one or more components of the system 1900, transmit and / or receive data, and perform the functions and processes described herein.

[0302] In some examples, each validation node can be associated with a routing number, which identifies an entity that controls the key of an authentication namespace. The authentication namespace can be associated with one or more of a specific entity, a specific set of cards, or a specific set of security keys (e.g., master keys, derived keys, session keys) associated with an entity, a set of cards, or a card type.

[0303] System 1900 can include a distributed ledger node 1910, which can be a network-enabled computer as described herein. In some examples, the distributed ledger node 1910 can be a dedicated server computer, a server that can be a blade server, or a personal computer, a laptop computer, a notebook computer, a palm-top computer, a network computer, a mobile device, a wearable device, or any processor-controlled device that can support System 1900.

[0304] In some examples, the distributed ledger node 1910 can execute one or more applications, such as a software application that enables network communication with one or more components of System 1900, send and / or receive data, and perform the functions and processes described herein.

[0305] The distributed ledger node 1910 can include a mapping 1912. In some examples, the mapping 1912 can be in the form of one or more databases. Exemplary databases include, but are not limited to, relational databases, non-relational databases, hierarchical databases, object-oriented databases, network databases, and any combination thereof. The one or more databases can be centralized or distributed. The one or more databases can be hosted internally by any component of the system 1900, or the one or more databases can be hosted externally to any component of the system 1900. In some examples, the one or more databases can be included in the distributed ledger node 1910, and in other examples, the one or more databases are stored external to the distributed edge node 1910 but can communicate with the distributed ledger node 1910. The one or more databases can be implemented in a database programming language. Exemplary database programming languages include, but are not limited to, Structured Query Language (SQL), MySQL®, Hypertext Markup Language, JavaScript, Hypertext Preprocessor language, Perl (Practical Extraction and Report Language), XML (Extensible Markup Language), and CGI (Common Gateway Interface). Queries made to the one or more databases can be implemented in the same database programming language used to implement the one or more databases. For example, if the one or more databases are SQL databases, queries made to the databases can be made in SQL (e.g., SELECT column1,column2 FROM table1,table2 WHERE column2='value';).One or more databases can be implemented in any database programming language, and it is understood that the programming implementation of a query can be adjusted as necessary for compatibility with one or more databases and to reflect the specific information to be queried.

[0306] In some examples, one or more databases can be included within the distributed ledger node 1910. In other examples, one or more databases are remote from the distributed ledger node 1910 but can communicate with the distributed ledger node 1910. Data communication between one or more databases and the distributed ledger node 1910 can be direct data communication or data communication via a network such as network 1906.

[0307] In some examples, the client node 1902 can communicate with the distributed ledger node 1910. The distributed ledger node 1910 can include a mapping 1912. The mapping 1914 can include, for example, a mapping between a validation node address and the validation node 1908, a mapping between a routing number and a validation node address, and / or a mapping between a routing number and the validation node 1908. In some examples, the mapping 1912 can include a digital signature associated with an entity having permission to validate a routing number. Based on one or more of these associations, the client node 1902 can call a validation node for validation and / or provide instructions to the client device to reach an appropriate validation node. This can be achieved by calling a validation API associated with the validation node 1908.

[0308] In some examples, the iteration of mappings described herein, such as mapping 1912, can also include the version number of the software or applet. The version number can be used to identify a validation node or validation node address, or to select from multiple validation addresses of one validation node.

[0309] In some examples, client node 1902 and distributed ledger node 1910 can be permitted (e.g., permitted to participate in the network) using certificates and / or cryptographic authentication mechanisms (e.g., non-fungible tokens). The certificates and / or cryptographic authentication mechanisms can be issued, for example, by a consortium organization or other governing entity associated with the distributed network. When appropriate permissions are granted, distributed ledger node 1910 can update mapping 1912 to reflect, for example, different associations between routing numbers, validation node addresses, and validation nodes. In some examples, the degree of permission can be issued. For example, if client node 1902 is to function to route data to validation node 1908 (or other validation node), a specific level of permission can be given to client node 1902. As another example, if distributed ledger node 1910 is to have the function of updating mapping 1912, distributed ledger node 1910 can have a different, higher level of permission.

[0310] System 1900 can include a client device 1914 that can be a network-enabled computer as described herein. In some examples, the distributed ledger node 1914 can also be a dedicated server computer, a server that can be a blade server, a personal computer, a laptop computer, a notebook computer, a palm-top computer, a network computer, a mobile device, a wearable device, or any processor-controlled device that can support System 1900. The client device 1914 can also be a mobile device. For example, the mobile device can be an iPhone (registered trademark), iPod (registered trademark), iPad (registered trademark) made by Apple, or any other mobile device that runs Apple's iOS (registered trademark) operating system, any device that runs Microsoft's Windows (registered trademark) Mobile operating system, any device that runs Google's Android (registered trademark) operating system, and / or any other smartphone, tablet, or similar wearable mobile device. In some examples, the client device 1914 can communicate data with another network-enabled computer, such as a smart card (e.g., a contactless card or a contact-based card), not shown in FIG. 19.

[0311] In some examples, the client device 1914 can execute one or more applications, such as a software application that enables network communication with one or more components of System 1900, send and / or receive data, and perform the functions and processes described herein.

[0312] In some examples, upon receiving an authentication request, client device 1914 can call client node 1902 (e.g., via an API). The call can include a routing number and / or an applet or software version number, and client node 1902 can query distributed ledger node 1910 and mapping 1912. When the query returns the identification of a validation node (e.g., validation node 1908) and / or its validation node address associated with its routing number and / or applet or software version, client node 1902 can respond to client device 1914. Next, client device 1914 can proceed with authentication with the validation node. Authentication can be performed by the systems and methods described herein, such as by generating, encrypting, transmitting, decrypting, and validating ciphertext as described herein.

[0313] In some examples, client node 1902 can coexist with validation node 1908. In these examples, client node 1902 can process authentication in a single call from client device 1914. In some examples, this can be allowed only if it is allowed to send a full authentication transmission (e.g., a ciphertext as described herein) to a client node not involved in the authentication.

[0314] In some examples, if client node 1902 receives from client device 1914 a routing number that is not processed based on its location, client node 1902 can return a code indicating that this routing number is not processed, along with the validation node address of the responsible validation node. Next, client device 1914 can use the received validation node address to send a full authentication transmission to validation node 1908.

[0315] In some examples, the client node 1902 can enter a distributed network with different permissions. For example, the client node 1902 can be a read-only router for data. As another example, the client node 1902 can have permission to send a message to the distributed ledger node 1910 to update one or more routing paths for one or more routing numbers. However, the client node 1902 is prevented from updating one or more routing paths for one or more routing numbers for other entities not associated with the client node 1902 or for other entities that have not been granted this permission. As another example, the distributed ledger node 1910 can include contracts and / or records that can authenticate the permission of a particular entity to modify a particular routing record based on its digital signature. As another example, a consortium agency or other management entity that controls the distributed network can have additional permissions, including but not limited to, adding new members (e.g., client nodes, distributed ledger nodes, validation nodes, and / or client devices), adding new signature credentials, adding new keys, adding new certificates, as well as the additional permission to revoke any of the foregoing. In some examples, the foregoing permissions can be delegated to the client node 1902, the distributed ledger node 1910, and / or the validation node 1908, but delegation is not required if security, legal, and / or financial conditions are met.

[0316] In some examples, one or more APIs can facilitate communication between components of system 1900 via network 1906. In other examples, one or more APIs are not necessary. Rather, components of system 1900 can communicate directly with, and / or be dedicated to, one or more specified entities in order to enable the specified entities to prevent data from being transferred to, from, or through an unspecified entity. This can further enhance data security and avoid detection of data traffic patterns by unspecified entities.

[0317] In some examples, an entity can establish a standard for nodes having an API based on the intended function of the node. For example, a first standard can be established for data routing nodes, and a second standard can be established for nodes performing mapping and / or authentication functions. As another example, routing APIs, mapping APIs, and validation APIs can be established where the same device or hardware configuration can perform these functions. However, use of keys, including private keys, by validation node 1908 for authentication can require storing the keys in one or more HSMs to enhance key security and ensure that the keys are not entered into memory.

[0318] FIG. 20 illustrates a method 2000 performed by a distributed network authentication system according to an exemplary embodiment. For example, the method can be performed by distributed network authentication system 1800 and / or by another distributed network authentication system.

[0319] In block 2002, the client device can send an authentication request to the client node. The authentication request can include, but is not limited to, a routing number, a software version number, and / or an applet version number. The request can be made via an API call or other communication between the client device and the client node.

[0320] In block 2004, after receiving the authentication request, the client node can send a query to the distributed ledger node (e.g., via an API call). The distributed ledger node includes a mapping, and the distributed ledger node can send the query to the mapping.

[0321] In block 2006, the query returns the identification of the validation node and / or the validation node address, and the distributed ledger node can send this identification to the client node.

[0322] In block 2008, the client node can send the identification to the client device. After receiving the identification, the client device can proceed with authentication by the identified validation node and / or validation node address in block 2010.

[0323] FIG. 21 shows a routine 2100 for card personalization according to an exemplary embodiment. For example, routine 2100 can be performed by the devices and systems described herein, including, but not limited to, the issuer system 802 and the personalization system 804.

[0324] In block 2102, the contactless card 102 can be first provisioned with one or more applets stored in the memory in at least one selected from the group of a dormant state, a deactivated state, a locked state, and a versioning state (e.g., a first versioning state or a second versioning state). The one or more applets can be configured to perform specific functions. For example, a first applet among the one or more applets can be configured to perform a payment transaction such as an EMV transaction. As another example, a second applet among the one or more applets can be configured to perform an authentication operation such as the authentication operation described herein. The one or more applets are provisioned in a dormant state prior to an agreement with the card-issuing entity to activate or otherwise initiate a transaction.

[0325] In block 2104, the contactless card 102 can be further provisioned with a unique identifier such as a pUID 610.

[0326] In block 2106, the identity of the user to be associated with the contactless card can be verified. In an embodiment, the identity of the user can be verified by the user with login credentials (e.g., a username and password), a one-time passcode, a text message, a pop-up notification, or a biometric input. The user can interact with a device such as a mobile device, a POS terminal, or a personal computer to verify the identity.

[0327] In block 2108, if the verification is successful, the first applet can be activated or otherwise have its state changed. When the first applet is activated or its state is changed, the first applet can no longer be in a dormant state, deactivated state, locked state, and / or the first version state. Instead, the first applet can be in a non-dormant state, activated state, unlocked state, and / or the second version state. Then, the first applet can perform a payment transaction.

[0328] In block 2110, if the verification is successful, the second applet can be activated or otherwise have its state changed. When the second applet is activated or its state is changed, the second applet can no longer be in a dormant state, deactivated state, locked state, and / or the first version state. Instead, when activated, the second applet can be in a non-dormant state, activated state, unlocked state, and / or the second version state. Then, the second applet can perform an authentication operation.

[0329] In an embodiment, routine 2100 can be performed at card activation and / or at the first use of the card. When activated, the first applet and the second applet can perform a payment transaction and an authentication operation respectively and communicate with each other. The first applet and the second applet can also communicate with the outside to identify the contactless card.

[0330] The systems and methods described herein can provide further improvements in data security, authentication, and validation. For example, by using a custom NFC specification, performance can be enhanced and the NFC protocol can be simplified. By using a signed hash of a card product customer identifier, policy decisions can be simplified, which may enable the verification of an instance owned by the appropriate customer without a mapping file that associates an identifier (e.g., a unique identification number) with a customer number. By using a centralized validator such as a key within a hub, a light-touch deployment model for an issuing entity (e.g., for a pilot) may be possible. Additionally, by using a general-purpose cryptography (e.g., a Root of Trust), deployment on a general-purpose Hardware Security Module (HSM) may be possible.

[0331] Figure 22 shows an embodiment of an exemplary computer architecture 2200 suitable for implementing various embodiments as described above. In one embodiment, the computer architecture 2200 may include or be implemented as part of one or more systems or devices described herein.

[0332] As used in this application, the terms "system" and "component" are intended to refer to any computer-related entity, be it hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing computing architecture 2200. For example, a component can be, but is not limited to, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and / or magnetic storage media), an object, an executable file, an execution thread, a program, and / or a computer. By way of example, both an application running on a server and the server can be components. One or more components can exist within a process and / or an execution thread, and a component can be localized on one computer and / or distributed between two or more computers. Further, components can be communicatively coupled to each other by various types of communication media for purposes of coordinating operations. The coordination can involve the exchange of information in a unidirectional or bidirectional manner. For example, components can communicate information in the form of signals communicated through the communication media. The information can be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, in further embodiments, alternatively, data messages can be used. Such data messages can be transmitted through various connections. Exemplary connections include parallel interface, serial interface, and bus interface.

[0333] The computing architecture 2200 includes various general computing elements such as one or more processors, multi-core processors, coprocessors, memory units, chip sets, controllers, peripheral devices, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, power supplies, etc. However, embodiments are not limited to implementation by the computing architecture 2200.

[0334] As shown in FIG. 22, the computing architecture 200 includes a processor 2212, a system memory 2204, and a system bus 2206. The processor 2212 can be any of a variety of commercially available processors.

[0335] The system bus 2206 provides an interface for system components including, but not limited to, the system memory 2204 to the processor 2212. The system bus 2206 can be any of several types of bus structures that can further interconnect (with or without a memory controller) to a memory bus, a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. The interface adapter can be connected to the system bus 608 via a slot architecture. Examples of slot architectures include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and the like.

[0336] Computing architecture 2200 may include or implement various manufactured products. The product may include a computer-readable storage medium for storing logic. Examples of computer-readable storage media include any tangible medium capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, and the like. Examples of logic include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like. Embodiments may also be at least partially implemented as instructions included in a non-transitory computer-readable medium or instructions on a non-transitory computer-readable medium that can be read and executed by one or more processors to enable the performance of the operations described herein.

[0337] The system memory 2204 can include various types of computer-readable storage media in the form of one or more high-speed memory units, such as read-only memory (ROM), random access memory (RAM), dynamic RAM (DRAM), double data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, arrays of devices such as RAID (Redundant Array of Independent Disks) drives, solid-state memory devices (e.g., USB memory, solid-state drive (SSD), and any other type of storage medium suitable for storing information). In the illustrated embodiment shown in FIG. 22, the system memory 2204 can include non-volatile 2208 and / or volatile 2210. The basic input / output system (BIOS) can be stored in the non-volatile memory 2208.

[0338] Computer 2202 may include various types of computer-readable storage media in the form of one or more low-speed memory units, including a built-in (or external) hard disk drive 2230, a magnetic disk drive 2216 that reads from and writes to a removable magnetic disk 2220, and an optical disk drive 2228 that reads from and writes to a removable optical disk 2232 (e.g., CD-ROM, DVD). The hard disk drive 2230, the magnetic disk drive 2216, and the optical disk drive 2228 can each be connected to the system bus 2206 by an HDD interface 2214, an FDD interface 2218, and an optical disk drive interface 2234, respectively. The HDD interface 2214 for external drive implementation can include at least one or both of Universal Serial Bus (USB) technology and IEEE 1394 interface technology.

[0339] The drives and associated computer-readable media provide volatile and / or non-volatile storage of data, data structures, computer-executable instructions, etc. For example, several program modules, including an operating system 2222, one or more applications 2242, other program modules 2224, and program data 2226, can be stored in the drive and non-volatile 2208, and volatile 2210. In one embodiment, one or more applications 2242, other program modules 2224, and program data 2226 can include, for example, various applications and / or components of the system described herein.

[0340] The user can input commands and information into computer 2202 via one or more wired / wireless input devices, such as pointing devices like keyboard 2250 and mouse 2252. Other input devices include microphones, infrared (IR) remote controls, radio frequency (RF) remote controls, game pads, stylus pens, card readers, dongles, fingerprint readers, gloves, graphic tablets, joysticks, keyboards, retina readers, touch screens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors, styluses, and the like. These and other input devices are often connected to processor 2212 via an input device interface 2236 coupled to system bus 2206, but can also be connected by other interfaces such as parallel ports, IEEE 1394 serial ports, game ports, USB ports, IR interfaces, and the like.

[0341] Monitor 2244 or other types of display devices are also connected to system bus 2206 via an interface such as video adapter 2246. Monitor 2244 can be either inside or outside computer 2202. In addition to monitor 2244, the computer typically includes other peripheral output devices such as speakers, printers, and the like.

[0342] Computer 2202 may operate in a network environment using logical connections through wired and / or wireless communications to one or more remote computers such as remote computer 2248. The (one or more) remote computers 2248 can be workstations, server computers, routers, personal computers, portable computers, microprocessor-based entertainment appliances, peer devices, or other common network nodes, and typically include many or all of the elements described in relation to computer 2202, but for simplicity, only memory and / or storage device 2258 is shown. The illustrated logical connections include wired / wireless connections to local area network 2256 and / or a larger network, such as wide area network 2254. Such LAN and WAN networking environments are common in offices and enterprises, facilitate enterprise-scale computer networks such as intranets, and all of which can be connected to a global communication network such as the Internet.

[0343] When used in the local area network 2256 network environment, computer 2202 is connected to local area network 2256 via a wired and / or wireless communication network interface or network adapter 2238. Network adapter 2238 can facilitate wired and / or wireless communications to local area network 2256, and the local area network may also include a wireless access point disposed thereon for communicating with the wireless capabilities of network adapter 2238.

[0344] When used in a wide area network 2254 network environment, computer 2202 can include a modem 2240, or be connected to a communication server on wide area network 2254, or have other means for establishing communication on wide area network 2254 via the Internet or the like. Modem 2240 can be internal or external, can be a wired and / or wireless device, and is connected to system bus 2206 via input device interface 2236. In a network environment, program modules illustrated in relation to computer 2202 or portions thereof can be stored in remote memory and / or storage device 2258. The network connections shown are exemplary, and it will be understood that other means of establishing a communication link between computers can also be used.

[0345] Computer 2202 is operable to communicate with wired and wireless devices or entities using standards of the IEEE 802 family, such as a wireless device operably arranged for wireless communication (e.g., IEEE 802.11 over-air modulation technology). This includes, among other things, at least Wi-Fi (i.e., Wireless Fidelity), WiMax, and Bluetooth (trademark) wireless technologies. Thus, communication can be in a pre-defined structure similar to a conventional network, or be merely ad-hoc communication between at least two devices. A Wi-Fi network uses a wireless technology called IEEE 802.11 (a, b, g, n, etc.) to provide a secure, reliable, and high-speed wireless connection. Using a Wi-Fi network, computers can be connected to each other, to the Internet, and to a wired network (using media and functions related to IEEE 802.3).

[0346] As described above in this specification, the various elements of the device may include various hardware elements, software elements, or a combination of both. Examples of hardware elements include devices, logical devices, components, processors, microprocessors, circuits, processors, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), memory units, logic gates, registers, semiconductor devices, chips, microchips, chip sets, etc. Examples of software elements include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (APIs), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. However, the determination of whether an embodiment is implemented using hardware elements and / or software elements can vary according to any number of factors such as the desired computing speed, power level, heat tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints desired for a given implementation form.

[0347] The components and features of the devices described above may be implemented using any combination of discrete circuits, application specific integrated circuits (ASICs), logic gates and / or single chip architectures. Further, the features of the devices may, where appropriate, be implemented using a microcontroller, programmable logic array and / or microprocessor, or any combination thereof. Note that hardware, firmware, and / or software elements may be referred to herein collectively or individually as “logic” or “circuitry”.

[0348] FIG. 23 is a block diagram showing an exemplary communication architecture 2300 suitable for implementing various embodiments as described above. The communication architecture 2300 includes various general communication elements such as a transmitter, a receiver, a transceiver, a radio, a network interface, a baseband processor, an antenna, an amplifier, a filter, a power supply, etc. However, embodiments are not limited to implementation by the communication architecture 2300 that may conform to the systems and devices described herein.

[0349] As shown in FIG. 23, the communication architecture 2300 includes one or more clients 2302 and a server 2304. The server 2304 may implement one or more of the functions and embodiments described herein. The clients 2302 and the server 2304 are operably connected to one or more respective client data stores 2306 and server data stores 2308 that can be used to store local information for each of the respective clients 2302 and the server 2304, such as cookies and / or associated context information.

[0350] Client 2302 and server 2304 can communicate information with each other using communication framework 2310. Communication framework 2310 may implement any well-known communication technology and protocol. Communication framework 2310 may be implemented as a packet-switching network (e.g., a public network such as the Internet, a private network such as a corporate intranet, etc.), a circuit-switching network (e.g., the public switched telephone network), or a combination of a packet-switching network and a circuit-switching network (with appropriate gateways and converters).

[0351] The communication framework 2310 may implement various network interfaces arranged to receive, communicate with, and connect to a communication network. The network interface may be regarded as a special form of an input / output (I / O) interface. The network interface may use connection protocols including, but not limited to, direct connection, Ethernet (e.g., thick, thin, twisted pair 10 / 100 / 1000 base-T, etc.), token ring, wireless network interface, cellular network interface, IEEE802.7a~x network interface, IEEE802.16 network interface, IEEE802.20 network interface, etc. Further, multiple network interfaces may be used to couple with various communication network types. For example, multiple network interfaces may be used to enable communication via broadcast, multicast, and unicast networks. A distributed network controller architecture may also be used to pool, distribute the load, and otherwise increase the communication bandwidth required by the client 2302 and the server 2304 when the processing requirements demand a greater amount of speed and capacity. The communication network may be any one and combination of wired and / or wireless networks including, but not limited to, direct interconnection, protected custom connection, private network (e.g., enterprise intranet), public network (e.g., Internet), personal area network (PAN), local area network (LAN), metropolitan area network (MAN), Operating Missions as Nodes on the Internet (OMNI), wide area network (WAN), wireless network, cellular network, and other communication networks.

[0352] In some aspects, the technology described herein relates to a computer-executed method that includes, after a contactless card enters a communication range, reading the contactless card by a computing device, selecting, by the computing device based on the reading of the contactless card, an applet stored in the memory of the contactless card, sending, by the computing device, a first command to the contactless card, and sending, by the computing device, a second command to the contactless card.

[0353] In some aspects, the technology described herein relates to a computer-executed method in which the first command includes a custom command.

[0354] In some aspects, the technology described herein relates to a computer-executed method in which the custom command includes a command to update a file stored by the contactless card to include nonce.

[0355] In some aspects, the technology described herein relates to a computer-executed method in which the custom command includes a command to change the state of an applet.

[0356] In some aspects, the technology described herein relates to a computer-executed method in which the custom command includes at least one selected from a group of commands to change the format of a message stored on the contactless card and commands to change the format of a message generated by the contactless card.

[0357] In some aspects, the technology described herein relates to a computer-executed method in which the custom command includes at least one selected from a group of commands to change parameters used in calculations performed by the contactless card and commands to send a certificate.

[0358] In some aspects, the technology described herein relates to a computer-executable method in which a custom command includes at least one selected from the group of commands that change the form of an authentication operation used by a contactless card.

[0359] In some aspects, the technology described herein relates to a computer-executable method in which the form of authentication includes at least one selected from the group of message authentication code (MAC) operations and signed messages with public key certificates.

[0360] In some aspects, the technology described herein relates to a computer-executable method in which a second command includes a command for a contactless card to calculate a ciphertext.

[0361] In some aspects, the technology described herein relates to a computer-executable method in which the calculation of the ciphertext utilizes nonces.

[0362] In some aspects, the technology described herein relates to a computing system including a computing device including a processor and a memory, where the memory stores instructions that, when executed by the processor, cause the processor to cause a contactless card to be read after the contactless card enters a communication range, select an applet stored in the memory of the contactless card based on the reading of the contactless card, send a first command to the contactless card, and send a second command to the contactless card.

[0363] In some aspects, the technology described herein relates to a computing system in which a first command includes a command to update a file stored by a contactless card to include a nonce.

[0364] In some aspects, the technology described herein relates to a computing system in which a second command includes a command for a contactless card to compute a ciphertext.

[0365] In some aspects, the technology described herein further relates to a computing system that includes a contactless card, where the contactless card computes a ciphertext using a nonce value.

[0366] In some aspects, the technology described herein relates to a computing system in which an instruction further causes a processor to read a functional container stored in the memory of a contactless card, and the functional container is associated with a selected applet.

[0367] In some aspects, the technology described herein relates to a computing system in which reading the functional container collects at least one piece of information selected from a group including the size of the functional container and the number of files stored in the functional container.

[0368] In some aspects, the technology described herein further relates to a computing system in which the information further includes at least one selected from a group including the file size of a file stored in the functional container, the file name of a file stored in the functional container, the read state of a file stored in the functional container, and the write state of a file stored in the functional container.

[0369] In some aspects, the technology described herein relates to a non-transitory computer-readable storage medium storing instructions that, when executed by a computing device, cause the computing device to perform a procedure including reading a contactless card, selecting an applet stored in the memory of the contactless card based on the reading of the contactless card, sending a first command to the contactless card, and sending a second command to the contactless card.

[0370] In some aspects, the technology described herein relates to a non-transitory computer-readable storage medium in which the first command includes a command to update a file stored by a contactless card to include a nonce.

[0371] In some aspects, the technology described herein relates to a non-transitory computer-readable storage medium in which the second command includes a command for a contactless card to compute a ciphertext using a nonce.

[0372] This disclosure is not limited to the specific embodiments described in this application, which are intended as examples of various aspects. Obviously, many modifications and variations can be made without departing from the spirit and scope thereof. In addition to those listed herein, functionally equivalent methods and apparatuses within the scope of this disclosure will be apparent from the foregoing representative description. The steps described herein need not be performed in the same order or with the same degree of separation as described. Similarly, various steps may be omitted, repeated, or combined as necessary to achieve the same or similar objectives. Such modifications and variations are intended to be within the scope of the appended representative claims. This disclosure should be limited only by the terms of the appended representative claims, together with the full scope of equivalents to which such representative claims are entitled. It should also be understood that the terms used herein are for the purpose of describing particular embodiments only and are not intended to be limiting.

[0373] In the foregoing specification, various preferred embodiments have been described with reference to the accompanying drawings. However, it will be apparent that various modifications and changes can be made, and additional embodiments can be implemented, without departing from the broader scope of the invention as set forth in the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a limiting sense.< / readeriduuid> < / merchantiduuid> < / uuid> < / jwt> < / puid> < / message> < / nonce> < / nonce>

Claims

1. After the contactless card enters the communication range, the computing device reads the contactless card, and Based on the reading of the contactless card, the computing device selects an applet stored in the memory of the contactless card, and The computing device sends a first command to the contactless card, and The computing device sends a second command to the contactless card A method executed by a computer, including.

2. The method executed by a computer according to claim 1, wherein the first command includes a custom command.

3. The method executed by a computer according to claim 2, wherein the custom command includes a command to update a file stored by the contactless card to include nonce.

4. The method executed by a computer according to claim 2, wherein the custom command includes a command to change the state of the applet.

5. The method executed by a computer according to claim 2, wherein the custom command includes at least one selected from the group of a command to change the format of a message stored on the contactless card and a command to change the format of a message generated by the contactless card.

6. The method executed by a computer according to claim 2, wherein the custom command includes at least one selected from the group of a command to change a parameter used for a calculation performed by the contactless card and a command to send a certificate.

7. The method executed by a computer according to claim 2, wherein the custom command includes at least one selected from the group of a command to change a form of an authentication operation used by the contactless card.

8. The method executed by a computer according to claim 7, wherein the form of the authentication includes at least one selected from the group of a cryptographic message authentication code (MAC) operation and a signed message with a public key certificate.

9. The method executed by a computer according to claim 2, wherein the second command includes a command for the contactless card to calculate a ciphertext.

10. The method according to claim 9, wherein the calculation of the ciphertext uses the nonce and is executed by the computer.

11. A computing system having a computing device including a processor and a memory, wherein when the memory is executed by the processor, the processor is caused to cause the non-contact card to be read after the non-contact card enters the communication range, cause an applet stored in the memory of the non-contact card to be selected based on the reading of the non-contact card, send a first command to the non-contact card, send a second command to the non-contact card is storing an instruction, computing system.

12. The computing system according to claim 11, wherein the first command includes a command to update a file stored by the non-contact card to include a nonce.

13. The computing system according to claim 11, wherein the second command includes a command for the non-contact card to calculate a ciphertext.

14. further comprising the non-contact card, wherein the non-contact card calculates the ciphertext using the nonce value, computing system according to claim 13.

15. The instruction further causes the processor to read a functional container stored in the memory of the non-contact card, wherein the functional container is associated with the selected applet, computing system according to claim 11.

16. The computing system according to claim 15, wherein the reading of the functional container collects at least one piece of information selected from a group including the size of the functional container and the number of files stored in the functional container.

17. The computing system according to claim 16, wherein the information further includes at least one selected from the group consisting of the file size of the file stored in the functional container, the file name of the file stored in the functional container, the read state of the file stored in the functional container, and the write state of the file stored in the functional container.

18. A non-transitory computer-readable storage medium, wherein when the computer-readable storage medium is executed by a computing device, the computing device is caused to reading the non-contact card; selecting an applet stored in the memory of the non-contact card based on the reading of the non-contact card; sending a first command to the non-contact card; sending a second command to the non-contact card A non-transitory computer-readable storage medium storing instructions for causing a procedure including the above to be performed.

19. The non-transitory computer-readable storage medium according to claim 18, wherein the first command includes a command for updating a file stored by the non-contact card to include nonce.

20. The non-transitory computer-readable storage medium according to claim 19, wherein the second command includes a command for the non-contact card to calculate a ciphertext using the nonce.

Images