Technology for Processing Contactless Card Functions in a Multi-Banking System Environment

Abstract

Systems and techniques for performing functions within multiple banking system environments using switchboard routing.

Description

Technical Field

[0001] [Cross - Reference to Related Applications] This application claims priority under 35 U.S.C. § 119(e) to U.S. Provisional Patent Application No. 63 / 350,699, filed on June 9, 2022, entitled "TECHNIQUES TO PROVIDE CONTACTLESS CARD TAP TO PERFORM FUNCTIONS IN A MULTIPLE BANKING SYSTEM ENVIRONMENT" by Casey Scott Barrett et al., U.S. Provisional Patent Application No. 63 / 351,652, filed on June 13, 2022, entitled "TECHNIQUES TO PERFORM TAP TO VERIFICATION WITH CONTACTLESS CARD" by Casey Scott Barrett et al., and U.S. Provisional Patent Application No. 63 / 405,749, filed on September 12, 2022, entitled "TECHNIQUES TO PROVIDE SECURE CRYPTOGRAPHIC AUTHENTICATION OF CONTACTLESS CARDS BY DISTRIBUTED ENTITIES" by Kevin Osborn et al. The disclosures of these provisional patent applications are incorporated herein by reference.

Background Art

[0002] Contactless card products have become so ubiquitous in today's society that they have fundamentally changed the way financial transactions and business are conducted. Contactless card products are offered to customers through credit card issuers (such as banks and other financial institutions), and the most common form is a plastic or metal card-like member provided by them. With the card, an approved customer or cardholder can purchase services and goods without directly exchanging cash immediately. Data security and transaction integrity are extremely important for both the companies facilitating such transactions and the customers. As electronic transactions using contactless cards increasingly account for a larger proportion of business activities, this need continues to grow. Therefore, it is necessary to provide companies and users with appropriate solutions to overcome current deficiencies in order to provide data security, authentication, and verification for contactless cards.

Summary of the Invention

[0003] In one aspect, a computer-implemented method includes receiving, by a node of the system, a request to establish a session for executing a function from a client device, wherein the function is executed at least partially using a contactless card; generating, by the node, session information corresponding to the session for executing the function, wherein the session information includes a session token unsigned by a nonce; transmitting, 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, wherein the issuer identifier is associated with the issuer of the contactless card; identifying, by the node, a device associated with the issuer identifier; The node communicates with the device to securely execute the function. including

[0004] In one aspect, a computing device includes a processor. When executed by the processor, the computing device causes the processor to receive a request from a client device to establish a session for executing a function, where the function is executed at least in part 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 from the message, where the issuer identifier is associated with the issuer of the contactless card; identify a device associated with the issuer identifier; communicate with the device to securely execute the function; and includes a memory storing instructions to cause the above to be executed.

[0005] In one aspect, a non-transitory computer-readable storage medium that, when executed by a computer, causes the computer to receive a request from a client device to establish a session for executing a function, where the function is executed at least in part 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; Sending the session information to a client device; Receiving a message from the contactless card via the client device; Extracting an issuer identifier from the message, where the issuer identifier is associated with the issuer of the contactless card; Identifying a device associated with the issuer identifier; Communicating with the device to securely execute a function; and causing the above to be executed.

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

Brief Description of the Drawings

[0007]

Figure 1

Figure 2

Figure 3

Figure 4A

Figure 4B

Figure 4C

Figure 5

Figure 6

Figure 7A

Figure 7B

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12A

Figure 12B

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

[0008] Embodiments may generally be directed to enabling contactless card functionality in a computing environment of multiple issuers. These functions may include a tap function that allows a user to tap a contactless card on a device such as a mobile device to execute a function. For example, a user may use a contactless card to perform identity verification, execute 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, activate a contactless card, and so on.

[0009] With the system described herein, a user may be able to execute these functions in multiple issuer environments. Further, with the system described herein, card issuers such as banks will be able to issue contactless cards with tap functionality to customers while maintaining a high level of security. The system described herein differs from previous solutions in that it provides a single platform for multiple issuers or banks to provide tap functionality. Conventionally, to provide contactless card functionality, each issuer or bank had to build and maintain its own system. This included maintaining its own hardware, software, database, security protocols, etc., which could be very costly for the issuer or bank. However, with the embodiments described herein, the issuer or bank will be able to offload many of the processing, storage, and security functions to a neutral or central system. As will be described in more detail later, the central system is configured to provide contactless card functionality to multiple issuers while maintaining a high level of security and data integrity. Since the functions and data of each issuer are managed and protected separately, another issuer or bank cannot access the data or functions of another issuer. As will be described in more detail later, these functions may be provided by a switchboard system configured to process and execute each contactless card function in a secure manner. Further benefits for the issuer may include being able to provide a very secure authentication option to the mobile web, where native applications typically lack robust authentication options.

[0010] Furthermore, the embodiments described herein utilize App Clips (U.S. registered trademark) and the Javascript (registered trademark) SDK together with WebNFC (registered trademark) to support a tap-based mobile web experience on both major mobile platforms (iOS (registered trademark), Android (registered trademark)). In the case of iOS (registered trademark), the embodiments include the provision of a tap-capable software development kit that includes functions and services for performing the operations described herein on the iOS (registered trademark) platform. The SDK can be installed in host applications such as native apps and web browser apps, and includes App Clip (U.S. registered trademark) support. The SDK provides functional support such as near-field wireless communication between the mobile device and the contactless card, installation of native apps via App Clips (U.S. registered trademark), and the ability to hide parts of the data and display. As an example, the SDK can be configured to download and install apps from an app store such as Apple's (registered trademark) App Store.

[0011] In an Android (registered trademark) operating system environment, embodiments include the use of a JavaScript SDK and a native Android SDK. The JavaScript SDK can be installed on a website via the website's source code, an app, etc. The JavaScript SDK also includes functionality to support NFC communication between contactless cards of a mobile device via WebNFC (registered trademark). The JavaScript SDK may also include customizable user interface (UI) functionality and functions that provide obfuscation. In an embodiment, 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 the use of a native Android SDK that can be implemented in an application on a device (e.g., a mobile device). The Android SDK can assist an application or website through wireless communication with a device such as a contactless card via a web browser. Using the Android SDK, an application or web browser can also communicate and utilize other basic Android services (such as the operating system and low-level services). Embodiments are not limited to these examples.

[0012] Referring generally to the notation and nomenclature used herein, one or more portions of the following detailed description may be presented from the perspective of program procedures executed on a computer or a network of computers. The descriptions and representations of these procedures are used by those skilled in the art to most effectively convey the substance of their work to other skilled persons. The procedures herein are generally considered to be a consistent series of operations leading to a desired result. These operations are operations that require physical manipulation of physical quantities. Usually, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated, but not necessarily so. Primarily for reasons of common usage, it may be convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc. However, it should be noted that all these terms and similar terms are associated with appropriate physical quantities and are merely convenient labels applied to those quantities.

[0013] Furthermore, these operations are often expressed in terms such as addition and comparison, which are usually associated with mental operations performed by a human operator. However, in any of the operations that make up some of the one or more embodiments described herein, such capabilities of a human operator are not required and are, in most cases, not 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 computer program stored therein, in accordance with the teachings herein, and / or devices or digital computers specially constructed for the required purposes. The various embodiments are also related to devices or systems for performing these operations. These devices may be specially constructed to suit the required purposes. The structures required for these various machines will become apparent from the description.

[0014] Referring now to the drawings, like reference numerals are used throughout the drawings to refer to like elements. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding. It is evident, however, that the novel embodiments can be practiced without these specific details. In other 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.

[0015] 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 computing system configured to use a contactless card, such as contactless card 102, to perform functions, and the encryption techniques described herein. These functions may include performing transactions, authenticating users, and other functions such as tap functions. Tap functions may include automatically entering fields on a mobile device, launching an application on a mobile device, opening and closing a door, activating a card, generating and issuing a virtual card number (VCN), and other tap operations.

[0016] System 100 shows a high-level configuration that enables multiple users to use contactless cards issued by one or more issuers to perform operations such as transactions with a merchant system. In the example shown, system 100 includes multiple bank systems 106a, retailer systems 106b, other financial systems 106c, and government systems 106d. These transaction systems may be configured to execute transactions in which a user purchases goods or services using a contactless card. Further, these systems may be configured to provide authentication services to customers via the contactless card. The embodiments are not limited to this method.

[0017] System 100 can be configured to perform various operations for customers, issuing banks, merchants, etc. These operations are initiated by a customer using the contactless card 102, and there may be an exchange of information between the contactless card 102 and other systems of the system 100. Depending on the operations being performed (e.g., tap to launch an application, tap to automatically enter text, tap to authenticate, tap to execute a transaction, tap to provide a VCN (automatically enter), etc.), data is routed and sent to various systems of the system 100 so that each operation can be executed.

[0018] For example, the contactless card 102 can initiate a transaction with one of the merchant systems when tapped by another device such as the mobile device 104, and the mobile device 104 can be further configured to communicate with one of the other systems such as a hosted service. These services can include verification services and commerce services. However, the embodiments are not limited thereto. Other services can be configured to perform operations so that a customer can execute functions with any number of taps.

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

[0020] To provide services in multiple issuer environments, 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 various financial institutions to issue contactless cards with transaction functions, verification functions, etc., and to perform operations seamlessly while maintaining a high level of security for confidential data. As will be described in detail later, the switchboard system 108 enables mobile devices, merchant systems, and central communication systems to communicate with the data of multiple issuing banks to execute transactions and other functions.

[0021] For example, a customer may want to execute a transaction for goods or services (retailer system 106b). The customer can initiate the transaction through an interaction with a mobile device or a POS (Point of Sale) terminal. The device or terminal sends a message regarding the transaction to the switchboard system 108, and the switchboard system 108 can further process the message to determine how to complete the transaction. The message may include encrypted and unencrypted parts. The encrypted part may contain confidential data used by the issuing bank system function to process the transaction, and the unencrypted part may contain data used by the switchboard system 108 to route the message and data to the correct issuing bank system function through services such as application programming interfaces and commerce services. The switchboard system 108 communicates 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 commerce session between the mobile device, commerce services, and the merchant system, and enable the transaction to be executed in a secure manner.

[0022] In an embodiment, the switchboard system 108 may also include management services that can be used to onboard card issuers, verifiers, and merchants to the system to provide contactless card services. In one example, the switchboard system may onboard an issuer / verifier by generating a unique identifier for identifying the issuer / verifier and storing the mapping between the unique identifier and the issuer / verifier in a data store such as a verification HSM. The unique identifier is provided to the issuer system, and the issuer may provide the unique identifier to each contactless card for use during transactions and other operations.

[0023] Any number of banks or financial institutions may provide a number of services 110 or functions that can be used by customers, merchants, and banks to provide service 110, such as processing transactions and verifying customers and their contactless cards. These services may include verification services and commerce services. 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. Further, the services 110 of each bank are 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.

[0024] In an embodiment, the system 100 may also perform an onboarding operation to onboard a merchant and a merchant system to operate 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 unique identifier to the merchant (e.g., issuing a merchant certificate). The system 100 may also enable the merchant and the issuer to exchange data such as a key pair and perform operations securely without the confidential data being disclosed to the switchboard system 108. In the system 100, the merchant may configure and set one or more configurations such as configuring data fields to support the merchant's use case.

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

[0026] FIG. 2 shows an example of a system 200 according to an embodiment described herein. The system 200 includes additional devices and systems configured to enable a contactless card issuer to utilize a card service with a tap function. Specifically, the system 200 enables any number of issuer systems to provide card services to a client in a secure and reliable manner via a switching fabric, i.e., the switchboard system 108.

[0027] In an embodiment, the switchboard system 108 includes one or more nodes 204 configured to perform routing operations. Each switchboard node 204 can include a session and nonce generator 206, message routers 208, 210, an operational data store 212, and a metrics store 214. Further, each node can be similarly configured and share the configuration, but each switchboard node 204 can independently process messages and requests and route them to appropriate systems such as merchant systems and issuer systems. Each node 204 is configured to function as a trust broker, for example, between an issuer system, a merchant system 222, and / or a verification 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 can route messages between an issuer system and a merchant system, but the node cannot access the private data within the message during that process.

[0028] The switchboard system 108 can be configured as a server system that includes an aggregation 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, for example, server applications executable on each node 204. In some cases, each of the server computers can be configured to operate one or more nodes, for example, in a virtual environment. The storage devices are configured to store data accessed by applications, and the network adapters are used to connect the server computers to the network.

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

[0030] In some embodiments, node 204 may operate in a cloud-based computing environment, e.g., an aggregation of hardware, software, and network components that enables the provision of cloud computing services. The switchboard node 204 and the computing services are provided via the Internet and can be accessed from anywhere in the world with 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 and other networks. It 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 switchboard nodes 204 of switchboard system 108. In an embodiment, DNS 202 may generate a number such as an Internet Protocol (IP) address, address record (A record), or another host name (CNAME record name). FIG. 3 shows one exemplary sequence 300 for a client to identify and resolve an identifier of one of nodes 204 of switchboard system 108. At a high level, domain name system 202 converts a known domain name into the numerical Internet Protocol (IP) address necessary to identify and locate computer services and devices in the underlying network protocol. The client selects the optimal node to use using the global DNS system as described in sequence 300.

[0031] 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 a transaction with a merchant, verifying a customer, or other tap functions. When the client SDK 236 identifies the switchboard node 204 and resolves an address for communicating with the switchboard node 204, the client SDK 236 can send one or more messages to the switchboard node 204 to authenticate and perform operations. 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 authorization request with the following header set to the switchboard node 204: ● X-Sb-Api-Key: <Client API key> ● X-Sb-Dvc-Fngrprnt: Device-specific device fingerprint

[0032] An example of the structure of the client API key is as follows. 65535-GReyx5BuEAaE72bWbFZJfHRL8Dbt1Uum Table 1 shows the values, names, and meanings.

[0033]

Table 1

[0034] The switchboard node 204 can approve or authenticate the client SDK 236 or the user, and the switchboard node 204 can perform operations using additional components such as the session and nonce generator 206 and the message router 208 as described in FIGS. 4A-4C. Note that the validator verification system 224 does not interact with the merchant system 222, and vice versa. The node 204 mediates all communications.

[0035] In an embodiment, the switchboard system 108 may manage the synchronization of shared operation data 212 and member management across the network using Hyperledger Fabric 220. 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.

[0036] In an embodiment, Hyperledger Fabric 220 may be generated by creating a set of one or more peers, an ordering service, and a channel. Once the network is created, the system 200 deploys chaincode to a network or node 204 that is permitted access to the fabric. Chaincode is code that runs on the blockchain and executes the logic code for network control 226 and operation data 212. Once the chaincode is deployed, each switchboard node 204 is configured to call a transaction on the blockchain to add data (such as operation data) to the blockchain. A switchboard node 204 or another device can query the ledger to obtain data. The ledger is a distributed database that stores all the data added to the blockchain.

[0037] All nodes 204 maintain independently verifiable action logs and can send them to a centralized aggregator to understand the usage status of the entire network. At the central level, the system 200 manages network operation data and management and can have a centralized view of network usage aggregated and abstracted to an appropriate level.

[0038] Figure 3 shows an example of 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 client 236, DNS 202, and switchboard node 204. At 302, sequence 302 includes the client 236 sending a request for the text record switchboard.{domain}.{tld}. to the default DNS server. The text record may be preconfigured in the client application or client SDK. At 304, DNS 202 returns one or more records. The DNS record structure includes 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} ○ Others ○ Purpose of use: Identification of active nodes ● Node record: ○ Name: {nodename}.{operator}.{region}.switchboard.{domain}.{tld} ○ Type: A / AAAA or CNAME ○ Resolution: Host name or IP address of the actual node ○ Purpose of use: Communication with the node

[0039] In an embodiment, the client 236 can determine the current time zone at 306. For example, a client application or SDK can utilize a function to obtain the current time zone in JavaScript or the like. Intl.DateTimeFormat().resolvedOptions().timeZone). Embodiments are not limited in this way, and the application or SDK may determine the time zone by another / different function call. At 308, the client 236 is configured to map the time zone to a region or a short version identifier of a region. As an example, there is America / New York → na-e. The region can be based on, for example, a DNS name. Table 2 shows some examples of the mapping of time zones to regions.

[0040]

Table 2

[0041] Embodiments are not limited to these examples, and other time zone-region mappings can also be utilized. Further, in an embodiment, the region can also be represented as a bidirectional graph structure having edges representing geographical neighbors. For example, na-e <-> na-w and sa <-> na-w and sa <-> na-e This representation is convenient for node selection.

[0042] At 310, the client can identify or select, among the DNS record options returned at 304, those within the region. If there are multiple matches, the client can randomly select one. If there are no available nodes in a certain region, the client can determine and use the data graph of neighboring regions to select the node of the nearest region where nodes are available at 312. For example, sa has no nodes, but since it is connected to na-e which has nodes, na-e is selected.

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

[0044] Figures 4A - 4C show a sequence example 400 for performing 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 a 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.

[0045] In an embodiment, at 402, the client SDK 236 including the client app can send a request and establish a session with the client server 484 so as to be able to associate the result with the correct client device or user. This request establishes the relationship between the client device and the client server (which may be the issuer server). At 404, the client server 484 generates a session and CLIENT SESSION INFORMATION. At 406, the client server 484 returns session information, such as CLIENT SESSION INFORMATION. In an embodiment, the CLIENT SESSION INFORMATION is client - implementation - specific user session identification information.

[0046] At 408, the client SDK 236 can initiate a contactless card authentication process with the client SDK 236. For example, the client SDK 236 can call a function or pass information to the client SDK 236 to initiate authentication via a contactless card. At 410 - 414, the client can use DNS to identify a node and establish communication with the node. Specifically, at 410, the client SDK 236 sends a request for the switchboard host name, and at 412, DNS 486 returns information including one or more host names. At 414, the client SDK 236 can determine the switchboard node to communicate with. FIG. 3 shows an example of a more detailed sequence of processing for establishing communication with a switchboard node.

[0047] At 416, the client SDK 236 can send a session request to the switchboard system 108. In an embodiment, the session request may be a function request in a format such as <FUNCTION REQUEST>. In an embodiment, FUNCTION REQUEST may be the data / function that the client desires after the contactless card has been verified. This function may be for any service discussed herein, such as user authentication, transaction execution, autofill data request, etc. At 418, the switchboard system 108 can generate an unsigned session token. The signed session token may be a JSON Web Token (JWT). When generating a JWT, the following elements need to be set.

[0048] · iss: The unique ID of the current node · nonce: A randomly generated 8 - digit hexadecimal nonce · exp: The expiration timestamp (+5 minutes) · client_id: The client ID of the client sending the request · sub: The device fingerprint of the client sending the request ·sid: Any session information sent from the client ·scope: The function to be executed

[0049] The nonce can be a unique random byte generated to guarantee the non-repeatability of messages by the contactless card. This nonce is extremely important for the security and operation of the switchboard system. The validity of the nonce is tracked by associating it with a session that can be verified by any member of the platform. As described above, the session is a JSON Web Token signed using the node-specific private key issued by the network. These JWTs are verifiable by a system with the corresponding public key and also by confirming that they were issued by the company or an authorized agent. The signed session token is a token generated by the JWT to establish the validity and expiration of the nonce and to associate the contactless card tap with the current client session. For example, the signed session token is <nonce>including <FUNCTION REQUEST> signed with [[ID=]], <CLIENT SESSION INFO>, and <NODE PRIVATE KEY>, where the NODE PRIVATE KEY is the private key of the switchboard system 108. The switchboard system 108 can include the NODE PUBLIC / PRIVATE KEY, which is a key pair used for JWT signing and verification.

[0050] At 420, the switchboard system 108 can return session information to the client SDK 236. The session information includes a signed session token (<SIGNED SESSION TOKEN>) and a NONCE <nonce>It includes the Function Terms of Service (FUNCTION TOS) and the Terms of Service Version (TOS VERSION). FUNCTION TOS may be the terms of service that the user must agree to in order for the client to execute the requested function, and TOS VERSION may be the version of the terms of service. At 422, the client SDK 236 can determine and / or receive the user's consent to the terms of service. In one example, the client SDK 236 captures and records the user's consent to the <FUNCTION TOS> as of <CONSENT DATE> along with <TOS VERSION>. CONSENT DATE is a timestamp indicating that the user has agreed to these terms of service.

[0051] At 424, the client SDK 236 exchanges one or more messages with the contactless card. In one example, the exchange occurs based on the contactless card being tapped on the client device. In an embodiment, the client SDK 236 can provide data used during a session to execute a function to the contactless card 102. 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 can include a NONCE to provide a security level indicating that the message received from the card is part of the same session. Additionally, the data can include additional information such as one or more control bits to control the format generated by the contactless card. Table 3 below shows an example of an NDEF message format.

[0052]

Table 3

[0053] In an embodiment, the updated MAC can be calculated to protect the control indicator. Specifically, the MAC M is determined as follows by performing a MAC calculation on 10 bytes of the update data U with the MCK (Update MAC Card Key).

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

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

[0056] Finally, calculate the MAC M = DES(MCKL) [B].

[0057] At 424, the contactless card can generate and provide a message to a client device including the client SDK 236. The data within the message can be utilized by the system discussed herein to perform the requested function. An example of a message is illustrated and described as message 500 in FIG. 5.

[0058] At 426, a client including the client SDK 236 can send messages and information to the switchboard system 108. The message may be a message received from the contactless card 102, such as message 500. Further, the client SDK 236 can send the consent date, TOS version, and signed session token to the switchboard system 108. The switchboard system 108 can utilize this information to confirm that the session is valid. At 428, the switchboard system 108 verifies that the signed session token is valid, e.g., it is a previously provided signed session token, includes a previously generated nonce, and is within the message.

[0059] 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 can 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.

[0060] In an embodiment, the switchboard system 108 is configured to generate and communicate secure communication with an issuer system, e.g., client - server 484 and validator 488. At 432, the switchboard system 108 sends a key request to the client - server 484. The key can be utilized for secure communication. As an example, the key request is an elliptical curve Diffie - Hellman (ECDH) key request. The embodiments are not limited in this way, and alternative key protocols, such as Supersingular isogeny Diffie - Hellman key exchange (SIDH or SIKE), private key / public key pairing (RSA), etc., may be utilized.

[0061] At 434, the client server 484 generates part of the key. In some cases, the client server 484 may generate half of the ECDH key for encryption / decryption of PII. Specifically, the client server 484 can 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 ECDH key negotiation.

[0062] At 436, the client server 484 stores the generated key part in storage. Specifically, the client server 484 can store <CLIENT EC PUBLIC KEY> and <CLIENT EC PRIVATE KEY> together with <KEY ID>. Here, KEY ID is used by the client server to cache its short-term EC public key / secret key for later ECDH key completion, for example, to identify the ECDH key part for generating the entire ECDH key. In one example, the key is stored in a secure memory location and may be used when PII is received for the session.

[0063] In an embodiment, the client server 484 can return the public key part to the switchboard system 108 together with the KEY ID at 438. The switchboard system 108 may store the public key part together with the KEY ID for later use, such as for generating an ECDH key. At 440, the switchboard system 108 can request verification to be performed by the validator 488. In one example, the switchboard system 108 requests verification for the request verification <message>, <SIGNED SESSION TOKEN>, <CLIENT EC PUBLIC KEY>, <CONSENT DATE>, and <TOS VERSION> can be sent. The validator 488 can return the out-of-band requirements of the public key to the switchboard system 108 to verify the session at 442. 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.

[0064] In an embodiment, the validator 488 can verify the message at 448. In an embodiment, the validator 488 can perform a number of validations, including verifying that the nonce in the message is correct, along with additional information such as the card unique identifier (pUID), the counter value (pATC), etc. FIGS. 12A and 12B discuss additional details of the validation process that may be implemented.

[0065] At 450, the validator 488 can save the information related to the session. For example, the validator 488 can save <TOS VERSION> and <puid>It can store <CONSENT DATE> along with it. The validator 488 can also generate another part of the key, for example, an ECDH key. For example, 488 uses the elliptic curve P256 to generate <ISSUER EC PUBLIC KEY> and <ISSUER EC PRIVATE KEY>. ISSUER EC PUBLIC KEY and ISSUER EC PRIVATE KEY are the latter part of the ECDH key negotiation.

[0066] At 454, the validator 488 generates a complete ECDH key. For example, the validator 488 generates <ECDH KEY> from <ISSUER EC PRIVATE KEY> and <CLIENT EC PUBLIC KEY>. ECDH KEY is the final key generated in the ECDH key negotiation.

[0067] The validator 488 can encrypt the function data using the ECDH KEY. For example, in some cases, when the validator 488 verifies a message, the validator 488 executes a function request to create a function result and encrypts the result with the ECDH KEY at 456. For example, the validator 488 executes <FUNCTION REQUEST> to generate <FUNCTION RESULT> and encrypts it with <ECDH KEY>. The function result can be any result based on the requested function (e.g., card verification).

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

[0069] In an embodiment, the switchboard system 108 sends functional results to the client server 484 to process the results. In one example, the switchboard system 108 can send <NCRYPTED FUNCTION RESULT>, <KEY ID>, <ISSUER EC PUBLIC KEY>, and <SIGNED SESSION TOKE>. At 462 and 464, the client server 484 can request and receive a public key from the switchboard system 108. In some cases, the exchange may occur over an out-of-band communication channel. The public key of the node is <NODE PUBLIC KEY>. The public key may be used, for example, to verify the sender of the function result. At 466, 484 verifies the signed session key with the public key <NODE PUBLIC KEY> of the node to verify the sender of the information. At 468, the client server 484 can extract client information from the signed session token. For example, the client server 484 may extract <CLIENT SESSION INFO> from <SIGNED SESSION TOKEN>, that is, extract user session identification information specific to the client implementation.

[0070] Further at 470, the client - server 484 searches for the client private key with the KEY ID. Specifically, the client - server 484 can obtain and delete the <CLIENT PRIVATE KEY> from the cache using the <KEY ID>. At 472, the client - server 484 generates or calculates an ECDH key. For example, the client - server 484 can calculate the <ECDH KEY> using <CLIENT PRIVATE KEY>+<ISSUER EC PUBLIC KEY>. The client - server 484 can decrypt the function result with the key calculated at 474. Specifically, the client - server 484 can decrypt the <ENCRYPTED FUNCTION RESULT> with the <ECDH KEY> to determine the <FUNCTION RESULT>. At 476, the client - server 484 associates the function result with the session.

[0071] In an embodiment, the switchboard system 108 can return to the client SDK 492 at 478 whether the result of the function has been successfully completed. Further, at 480, the client SDK 492 can notify the client application 490 of the result. At 482, the client application 490 can utilize the function. For example, at 482, the <CLIENT SESSION INFO> can be used to communicate with the client - server 484 to continue the function of fetching the re - edited <FUNCTION RESULT>.

[0072] FIG. 5 shows an example of a message 500 that can be communicated by the contactless card 102 to perform the functions described herein. One or more fields of the message 500 can also be used to route the message 500 through the switchboard system and to perform authentication / verification techniques.

[0073] In an embodiment, the message 500 includes an applet version 502 field, an issuer discretionary indicator 504 field, an issuer identifier 506 field, a pKey ID 508 field, a pUID 510 field, a pATC 512 field, a nonce 514 field, and an encrypted ciphertext 516.

[0074] In an embodiment, the message 500 includes issuer data and includes an issuer discretionary indicator 504 field that is set during personalization. Further, the message 500 includes an issuer identifier 506 field that includes a unique ID assigned to the entity (e.g., issuer) that issues the card. For example, each issuer is assigned a unique identifier during an onboarding operation when joining the system. The issuer ID can be used by the switchboard system 108 to route the message and its content to the appropriate service associated with that particular issuer.

[0075] In an embodiment, the message 500 includes a pKey ID 508 field. In some cases, the pKey ID 508 field may include data that identifies a set of master keys of the card issuer. The issuer's set of master keys can utilize a derived set of master keys or unique derived keys (UDKs) for each card. Further, the master key (UDK) for each card is generated during card personalization. The UDK of the card is used to generate a session key that is used to generate application cryptography. The session key generated by the card can be used by a system such as a validator system to identify the issuer's master key using the pKey ID and to regenerate the session key by a system that performs verification.

[0076] In an embodiment, each contactless card 102 is assigned a unique 16 - digit hexadecimal ID (pUID) during personalization. The derivation of the application - specific key for the card - applet using the pUID is performed outside the card. The resulting application key is injected during the personalization of the card. In an embodiment, the application key of the card is the same as the derived master key or UDK of the card. The process of deriving the application key (UDK) is as follows. 1. Create a plurality of issuer master key sets and assign a unique 3 - byte pKey ID (6 - digit hexadecimal) to each. 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 diversified 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 procedure. 1. Encrypt X using the appropriate issuer master key identifier (pKey ID) to calculate ZL. 2. XOR X with FFFFFFFFFFFFFFFFFFFF and encrypt the result with the issuer master key to calculate ZR. 3. Concatenate ZL and ZR to form the application key (UDK key).

[0077] Message 500 can include a pUID510 field that contains the card - specific identifier assigned to the contactless card during personalization. The pUID 510 field data is an alphanumeric combination used to uniquely identify each card and is associated with the user.

[0078] In an embodiment, message 500 includes a pATC 512 field configured to hold a counter value. The counter value holds, as an example, the count of non-contact card reads (taps) in hexadecimal. Further, the counter value may be used to generate a session key for encrypting at least a portion of the message.

[0079] In an embodiment, each time message 500 is created, a new session key is derived and utilized to generate one or more portions of message 500. Specifically, the session key is used to calculate an encrypted MAC (Application Cryptogram).

[0080] The card applet supports a modified variation of the session key derivation option according to EMV 4.3 Book 2 Annex A1.3.1 and generates a unique encrypted session key ASK as follows. ● Encrypt [ATC[2] || ATC[3] || ‘F0’ || ‘00’ || [ATC[0] || [ATC[1] || [ATC[2] || [ATC[3]] with the application key to calculate SKL. ● Encrypt [ATC[2] || ATC[3] || ‘0F’ || ‘00’ || [ATC[0] || [ATC[1] || [ATC[2] || [ATC[3]] with the application key to calculate SKR. ● Concatenate SKL and SKR to form an authentication session key.

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

[0082] The card applet also supports a modified version of the session key derivation option according to EMV 4.3 Book 2 Annex A1.3.1 and generates a unique encrypted session key DESK as follows. Encrypt ●[ATC[2] || ATC[3] || ‘F0' || ‘00’ || ‘00’ || ‘00’ || ‘00’ || ‘00’] with the application key to calculate SKL. Encrypt ●[ATC[2] || ATC[3] || ‘0F’ || ‘00’ || ‘00’ || ‘00’ || ‘00’ || ‘00’] with the application key to calculate SKR. ● Combine SKL and SKR to form the data encryption session key.

[0083] The ciphertext C is determined by calculating the MAC for the 32 - byte transaction data T using the authentication session key (ASK) as follows.

[0084] 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’]

[0085] Consider T as four blocks consisting 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].

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

[0087] The encryption of the ciphertext is performed as follows using a DESK (Data Encipherment Session Key) in the CBC (Cipher Block Chaining) mode for encryption. ● 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].

[0088] Recover using the decryption mode. ● RND = DES3 -1 (DESK) [E1] ● B = DES3 -1 (DESK) [E2] ● C = [E1] XOR [B]

[0089] In an embodiment, some of the data provided in message 500 is static and is set on the card during card personalization, and other data is dynamic and may be generated by the card during operation (e.g., when a read operation is being performed). Note that in some cases, the static information may be updatable, but the customer and the card may need to go through a secure update process managed by the issuer.

[0090] In an embodiment, the contactless card 102 can communicate messages between devices such as a mobile device during a reading operation. For example, in response to the contactless card 102 being tapped on the surface of a device or being brought within the wireless communication range, for example, a reading operation is performed on the contactless card 102, and the contactless card 102 can generate a message and provide it to the device. For example, once within range, the contactless card 102 and the device can 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.

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

[0092] FIG. 6 shows an example of a routine 600 according to an embodiment discussed herein. At block 602, the routine 600 includes receiving, by a node in the system, a request to establish a session for executing a function from a client device, where the function is at least partially executed using a contactless card. In some cases, the node is one of a plurality of nodes of a switchboard system. This node can be preselected by the sending device through DNS operation.

[0093] At block 604, the routine 600 includes generating, by the node, session information corresponding to the session for executing the function, where the session information is composed of a nonce and a signed session token. The nonce and / or the signed session token are used by the system to perform the functions described herein while ensuring that the node routing the data is authenticated, the message from the contactless card is authenticated, and the session for the function is tracked.

[0094] In block 606, routine 600 transmits session information to the client device by the node. The client device can communicate with the contactless card, receive data from the card for authentication, and execute functions. In some cases, the client device may send a nonce from the node to the contactless card. The contactless card can generate a message, reply to the client device, and utilize the nonce when finally communicating with the node, such as incorporating it into the encrypted part of the message (see FIG. 5).

[0095] In block 608, routine 600 receives a message from the contactless card via the client device by the node. The message is generated by the contactless card. FIG. 5 shows an example of message 500.

[0096] In block 610, routine 600 extracts the issuer identifier from the message by the node, and the issuer identifier is associated with the issuer of the contactless card. In some cases, the issuer identifier may be in plain text format.

[0097] In block 612, routine 600 identifies the device associated with the issuer identifier by the node. For example, the node can perform a lookup to determine the server associated with the issuer identifier and the function to be executed.

[0098] In block 614, routine 600 communicates with the device by the node to securely execute the function.

[0099] Figures 7A and 7B illustrate an example of a system 700 configured according to embodiments discussed herein. In some cases, system 700 may be a more detailed view of system 100 and its components. The illustrated system 700 includes one or more systems that support transaction processing, execution of verification functions, and other functions related to contactless cards issued in multiple issuer environments. In an embodiment, system 700 includes one or more issuer systems 202, a personalization system 704, one or more merchant systems 706, and a switchboard system 730. The switchboard system 730 can include additional systems for providing functionality to multiple issuer systems, and these systems can include switchboard nodes configured to route messages and communicate with other systems.

[0100] These systems can be composed of hardware and software components for performing the functions described herein. For example, each system can be composed of one or more servers, processors, memories, storages, networking hardware, input / output devices, etc. for processing instructions according to an embodiment. Further, each system can support and implement a number of application programming interfaces (APIs) configured to enable interoperability between each system while maintaining a high level of security.

[0101] In an embodiment, system 700 includes at least one issuer system 702. The issuer system 702 has a number of components and can provide functions such as issuing contactless cards to customers, authenticating customers, executing transactions, and enabling other contactless card tap-to operations. In one example, the issuer system 702 includes card issuance functions including processing network contactless card requests, maintaining a system of record (SoR), and providing a provisioning service.

[0102] In one example, to issue a card, the issuer system 702 can generate a per-card unique identifier (pUID). Each pUID may be associated with a card owner and a contactless card at the time of issuance. The pUID may be utilized as part of a verification process, and the issuer system 702 may store the pUID in, for example, a database associated with the cardholder. The pUID is written to the SoR and provided to a personalization system 704 that physically generates and issues the contactless card. In certain embodiments, the pUID may be communicated to the personalization system 704 in a batch or batch file. For example, the issuer system 702 can include a process for generating a batch of pUIDs and a function for communicating the batch, such as a batch of emboss files, to the personalization system 704. The personalization system 704 can configure, physically generate, and issue the contactless card as detailed below.

[0103] In some embodiments, the issuer system 702 can provide additional functionality. In some cases, the issuer system 702 can maintain at least a portion of the functionality to perform a verification operation on a customer after the contactless card has been issued. For example, the issuer system 702 can include a function or API that a device, such as a mobile device executing the issuer mobile app 710, uses to verify information first received from the contactless card. The device may communicate data from the contactless card to the issuer system 702 via one or more APIs such as those provided by the MFA service 714, and the issuer system 702 may verify the information based on the information stored in the database. The issuer system 702 can return the result to the device.

[0104] In some cases, the issuer network 702 includes one or more commerce APIs configured to provide commerce services, such as providing PII in a transaction, providing PII to an autofill form, or providing a VCN for executing a transaction or autofill form. In some cases, these commerce APIs may be hosted by third-party services provided outside the issuer network 702, such as under service 734.

[0105] In other examples, the issuer system 702 can offload verification work to service 734. Even in such cases, the issuer system 702 can receive data via an API from a non-contact card through a device, such as a mobile device. Subsequently, the issuer system 702 may be configured to send the data to service 734, and service 734 may execute the verification work. In either case, the issuer system 702 can return the verification result to the device. A device, such as a mobile device, can use the result as part of a verification request, for example, to access a mobile app, as part of a multi-factor authentication operation, or to enable the execution of other functions.

[0106] In an embodiment, the system 700 includes a personalization system 704 that performs operations on the non-contact card to issue a non-contact card to a customer. For example, the personalization system 704 can obtain and / or generate data to be copied to each non-contact card for each customer. The data is unique to each customer and includes information such as account numbers, customer names, expiration dates, card verification values (CVVs), etc. In an embodiment, the personalization system 704 can store the data in a secure memory, such as a hardware security module (HSM) of the non-contact card. The data can also be provided to the issuer system 702 and / or service 734 to enable the execution of non-contact card operations, such as verification, authentication, tap functions, etc.

[0107] The personalization system 704 can also generate a unique key for each contactless card. Each contactless card can have a unique set of keys, which can be further used to generate derived keys that are used to perform cryptographic operations for the card to communicate data in a secure manner. The unique key for each card is based on or associated with the issuing bank. Further, the issuer system 702 and / or the switchboard system 730 can have a set of unique keys for each card that can be used to perform verification operations by being able to generate the same derived keys to decrypt data received from the contactless card during the verification or transaction process.

[0108] The personalization system 704 can also install one or more applets on the card. The applets can be used to perform various functions such as executing cryptographic operations, generating messages and ciphertexts containing data for card verification and transactions. In some cases, the personalization system 704 can install applets to perform functions and can include the version number of the applets. System version management may be necessary to enable other systems to operate accordingly. The system version, like the verification logic, indicates the applet version that the personalization system 704 embeds in the card. For example, the first - party system operates at version 0100, and the use of the central system can operate at a different version, e.g., version 0200, to simplify implementation and enable an authentication network. The JavaCard and MultOS implementations of the applets can share the same version number.

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

[0110] The system 700 further includes a switchboard system 730 and a service system 734, enabling multiple banks or issuers to provide functions from the tap of a proximity card to execution, such as verification, transactions, etc., while maintaining a high level of data security and separation between the data of each issuer. For example, the switchboard system 730 and the service system 734 provide a series of functions and APIs configured to provide services for executing verification, transactions, and other proximity card operations to multiple issuers. In some cases, the switchboard system 730 may be maintained and provided by a central system owned and operated by a separate entity from any of the card issuers.

[0111] In an embodiment, the switchboard system 730 can include a number of components, and systems, including a routing service, a workflow service, an administration service, an authentication service, a usage service, an analytics service, and an administration service 718.

[0112] In an embodiment, the switchboard system 730 and the services are configured such that multiple issuers can operate together. For example, the switchboard system 730 is configured to route messages and data from devices and contactless cards to corresponding services of card issuances, such as service 734. For example, Bank A can issue a contactless card and provide Service A, and the switchboard system 730 is configured to process messages and data from the contactless card issued by Bank A to Service A. In an embodiment, the switchboard system 730 can determine the destination using the information in the messages and data.

[0113] The switchboard system 730 and the services also enable the merchant system 706 to process transactions of multiple different issuers. For example, the switchboard system 730 can include an API that can be used by the merchant's backend to obtain PII associated with the cardholder for executing a transaction. The switchboard system 730 can also include an API configured to start a session, such as a transaction session, and provide a verification token to a merchant app on a mobile device based on a contactless card executed on the mobile device.

[0114] The switchboard system 730 also includes a verification function and verification APIs for performing verification operations, such as verification service 720. The switchboard system 730 can also be coupled with a message verification service 724 configured to communicate with the verification function / API to provide a ciphertext verification service 726. The ciphertext verification service 726 includes a tap algorithm and executes a verification process in cooperation with a verification HSM 728. Each API will be described in detail in the following description.

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

[0116] FIG. 8 shows a configuration example of the contactless card 102 according to the embodiments discussed in this specification. The contactless card 102 can include a payment card such as a credit card, a debit card, a gift card, etc. issued by a service provider or an issuer, which is displayed as a service provider display 802 on the front or back of the contactless card 102. In some cases, the contactless card 102 can include, without being limited to, an identity certificate, a membership card, a hotel key card, etc., even if it has nothing to do with a payment card. In some cases, the transaction card can include a dual interface contactless payment card, a reward card, etc. The contactless card 102 may include a substrate 808, which may include a single layer or one or more laminated layers made of plastic, metal, or other materials. Exemplary base materials include polyvinyl chloride, polyvinyl acetate, acrylonitrile-butadiene-styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, biodegradable materials, etc. In some cases, the contactless card 102 has physical characteristics compliant with the ID-1 format of the ISO / IEC 7816 standard, and the transaction card complies with the ISO / IEC 14443 standard in other respects. However, it should be understood that the contactless card 102 according to the present disclosure may have different characteristics, and the present disclosure does not require a transaction card implemented in a payment card.

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

[0118] As shown in FIG. 8, the contact pads 804 of the contactless card 102 can include a processing circuit 916 for storing, processing, and communicating information, including a processor 902, a memory 904, and one or more interfaces 906. It should be understood that the processing circuit 916 can include additional components, including a processor, a memory, a hardware security module (HSM), an error and parity / CRC checker, a data encoder, an anti-collision algorithm, a controller, a command decoder, security primitives, and anti-tampering hardware necessary to perform the functions described herein.

[0119] Memory 904 may be a read-only memory, a write-once read-many 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 as read-only at factory shipment or may be one-time programmable. One-time programmability provides the opportunity to read as many times as written once. The write-once read-many memory can be programmed at a point after the memory chip is shipped from the factory, for example, in the personalization system 704. The programmed memory cannot be rewritten but can be read as many times as desired. The read / write memory can be programmed and reprogrammed many times after factory shipment. The readable and writable memory may also be read many times after factory shipment. In some cases, the memory 904 may be an encrypted memory that utilizes an encryption algorithm executed by the processor 902 to encrypt data. In some embodiments, at least a portion of the memory is implemented as part of an HSM and can store secret data such as the card's master key.

[0120] Memory 904 may be configured to store one or more applets 908, one or more counters 910, a customer identifier 914, and an account number 912 that may be a virtual account number. In some cases, the customer identifier 914 is a card-specific identifier such as a pUID. Memory 904 can be configured to store additional information such as a version identifier for identifying the version of the applet, an issuer identifier for identifying the issuer or bank, and one or more key identifiers.

[0121] One or more applets 908 can consist of 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 applet 908 is not limited to Java card applets, but can be any software application operable on a contactless card or other device with limited memory. One or more counters 910 consist of numeric counters sufficient to store integers. The customer identifier 914 can consist of a unique alphanumeric identifier assigned to the user of the contactless card 102, which may distinguish the user of the contactless card from the users of other contactless cards and / or the contactless card from other contactless cards. In some cases, the customer identifier 914 can identify both the customer and the account assigned to that customer, and further identify the contactless card 102 associated with the customer's account.

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

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

[0124] In some cases, the contactless card 102 can include one or more antennas 918. The one or more antennas 918 can be disposed within the contactless card 102 around the processing circuit 916 of the contact pad 804. For example, one or more antennas 918 may be integral with the processing circuit 916, and one or more antennas 918 may be used with an external booster coil. As another example, one or more antennas 918 may be provided outside the contact pad 804 and the processing circuit 916.

[0125] In one embodiment, the coil of the contactless card 102 can function as the secondary side of an air-core transformer. The terminal can communicate with the contactless card 102 by cutting off power or amplitude modulation. The contactless card 102 can infer data transmitted from the terminal by utilizing the gap of the power connection of the contactless card, and this data may be functionally maintained via one or more capacitors. The contactless card 102 can communicate back by switching the load of the coil of the contactless card or performing load modulation. Load modulation may be detected by the coil of the terminal due to interference. More generally, using the antenna 918, the processor 902, and / or the memory 904, the contactless card 101 provides a communication interface for communicating via NFC, Bluetooth®, and / or Wi-Fi communication.

[0126] As described above, the contactless card 102 may be built on a software platform operable on a smart card having limited memory such as JavaCard or other devices, and one or more applications or applets may be securely executed. The applet 908 can be added to the contactless card to provide one-time passwords (OTPs) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet(s) 908 is configured to respond to one or more requests such as proximity field data exchange requests from a reader such as a mobile NFC reader (e.g., of a mobile device or a POS terminal), and generate an NDEF message containing an encrypted secure OTP encoded as an NDEF text tag. FIG. 5 shows an example of a message generated by the contactless card 102 and communicated to perform verification and transaction operations.

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

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

[0129] In some cases, the contactless card 102 and the issuer system 702 and / or the switchboard system 730 may include specific data so that the card is properly identified. The contactless card 102 may include one or more unique identifiers (not shown). Each time a read operation is performed, the counter 910 is configured to increment. In some cases, each time data from the contactless card 102 is read (e.g., by a mobile device), the counter(s) 910 is transmitted to a verification service for verification, and it is determined whether the counter(s) 910 is equal to the counter of the issuer system 702 and / or the switchboard system 730 (as part of the verification).

[0130] One or more counters 910 may be configured to prevent replay attacks. For example, if a ciphertext is obtained and reproduced, or if the counter 910 is read, used, or otherwise delivered, the ciphertext is immediately rejected. If the counter 910 is not being used, it may be replayed. In some cases, the counter incremented on the card is different from the counter incremented for a transaction. Since there is no communication between the applets 908 on the contactless card 101, the application transaction counter 910 cannot be determined.

[0131] In some cases, the counters 910 may not be synchronized. In some cases, the counter(s) 910 may be incremented to account for accidental reads that start a transaction, such as a skewed read, but the application does not process the counter(s) 910. In some cases, when the mobile device 10 is powered on, NFC may be enabled and the device 110 may be configured to read available tags, but no action corresponding to the read tag is performed.

[0132] To continue synchronizing counter 910, an application such as a background application may be run, detected when mobile device 110 is powered on, and configured to advance counter 104 in synchronization with issuer system 702 and / or switchboard system 730 indicating that a read has occurred due to the detection. In other examples, hash-based one-time passwords may be utilized to accept mis-synchronization. For example, if within a threshold of 10, counter 910 is configured to advance. However, if within a different number of thresholds, such as within 10 or 1000, the request for re-synchronization may be processed to require the user to tap, gesture, or otherwise indicate one or more times via the user's device via one or more applications. If counter(s) 910 increments in the appropriate order, the user can know that they have done so.

[0133] The key diversification techniques described herein with reference to counter 910, the master key, and diversified keys are an example of encryption and / or decryption by key diversification techniques. Since the present disclosure is equally applicable to other types of important decentralization techniques, this example of an important decentralization technique should not be considered limiting of the present disclosure.

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

[0135] In some cases, to overcome the drawbacks of the 3DES algorithm, which is vulnerable, a session key might be derived (such as a unique key for each session), but instead of using a master key, unique card-derived keys and counters might be used as diversification data. For example, each time the contactless card 102 is in operation, different keys can be used for creating a message authentication code (MAC) and performing encryption. As a result, the encryption becomes triple-layered. The session key is generated by one or more applets and is derived using one or more algorithms with an application transaction counter.

[0136] Furthermore, each card increment is unique and can be assigned by personalization or algorithmically assigned by some identification information. For example, odd-numbered cards increment by 2, and even-numbered cards increment by 5. In some cases, the increment may also change in sequential reads such that one card increments sequentially in a repeat of 1, 3, 5, 2,.... A specific sequence or algorithm sequence can also be defined during personalization or from one or more processes derived from a unique identifier. This makes it difficult for replay attackers to generalize from a small number of card instances.

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

[0138] Figure 10 is a timing diagram showing an example of a sequence for providing data between a contactless card and a client device according to one or more embodiments of the present disclosure. Sequence flow 1000 can include communication between contactless card 102 and client device 1002. Client device 1002 can include application 1004 and processor 1006. In an embodiment, application 1004 may be a banking application or an issuer application. Other examples of applications include merchant applications, web browsers, game applications, etc. In an embodiment, client device 1002 can include any number of applications, and the embodiments are not so limited. In an embodiment, client device 1002 may be a mobile device, a POS terminal, a personal computer, etc. Further, client device 1002 can include additional components such as additional apps, memory for storing instructions for processing by processor 1006, interfaces, etc.

[0139] At line 1008, application 1004 communicates with contactless card 102 (e.g., after bringing contactless card 102 close). In one example, the customer may be instructed to tap contactless card 102 on the surface of the device so that contactless card 102 enters the wireless communication range of the card. For communication between application 1004 and contactless card 102, it may be necessary to bring contactless card 102 close enough to a card reader (not shown) of client device 1002 to enable NFC data transfer between application 1004 and contactless card 102. In an embodiment, communication between application 1004 and contactless card 102 can utilize a wireless interface via an operating system that supports wireless protocols such as NFC, Bluetooth, WiFi, etc.

[0140] At line 1010, after communication is established between the client device 1002 and the contactless card 102, the contactless card 102 generates a message authentication code (MAC) cipher such as message 500. In some cases, this may occur when the contactless card 102 is read by the client device. In particular, this may occur during a read such as an NFC read of a Near Field Data Exchange (NDEF) tag created according to the NFC data exchange format. For example, a reader application such as application 1004 can send a message such as an applet selection message with the applet ID of the NDEF generation applet. When the selection is confirmed, a read file message follows the select file message. For example, the sequence may include "select capability file", "read capability file", and "select NDEF file". At this point, the counter value held 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 500, including a header and a shared secret, is generated. Thereafter, a session key is generated. The MAC cipher is created for a message that includes a header and a shared secret. Thereafter, the MAC cipher can be concatenated with one or more blocks of random data, and the MAC cipher and a random number (RND) can be encrypted with the session key. Thereafter, the ciphertext and the header are concatenated, encoded as ASCII hexadecimal, and returned in the NDEF message format (in response to the "read NDEF file" message). In some cases, the message communicated to the client device 1002 may include an encrypted portion and an unencrypted portion, as described herein.

[0141] In some examples, the MAC cipher may be sent as an NDEF tag, and in other examples, the MAC cipher may be included in a link or Uniform Resource Indicator (e.g., a formatted string). In some cases, application 1004 is configured to send a request to contactless card 102, and the request includes an instruction to generate a MAC cipher. In some cases, the MAC cipher may be included with additional data such as applet version, issuer identifier, card unique identifier, key identifier, as illustrated in FIG. 5. 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 108 to determine where to route the message.

[0142] At line 1012, contactless card 102 sends a message including the MAC cipher to application 1004. 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 wireless data communication means. At line 1014, application 1004 communicates the message including the MAC cipher to processor 1006.

[0143] In the illustrated sequence, at line 1016, client device 1002 including processor 1006 can verify a message containing content such as a MAC cipher in accordance with an instruction from application 1004. For example, as described below, the MAC cipher can be verified, such as through processing via switchboard system 108 and a verification service. In some cases, verification of the MAC cipher may be performed by another device such as client device 1002, or a server of a banking system that is in data communication with client device 1002, issuer system 702, switchboard system 108. For example, processor 1006 may output a message containing the MAC cipher for transmission to a server of the issuer system or switchboard system 108, and the issuer system or switchboard system 108 may verify the data in the message including the MAC cipher, shared secret, and counter. In some cases, the MAC cipher functions as a digital signature for verification. Other digital signature algorithms, such as public key asymmetric algorithms, such as digital signature algorithm or RSA algorithm, or zero knowledge protocol, can be used to perform this verification.

[0144] In an embodiment, the exchange between the contactless card 102 and the client device 1002 can be performed to execute any number of functions, as discussed herein. As described, the embodiments include using the contactless card 102 and tapping the card on the device to perform verification operations, such as MFA. In another example, a transaction for a good or service can be made using the contactless card 102. There are other functions that can be performed by tapping, such as tapping to automatically enter one or more fields, tapping to launch an application, tapping to initialize the contactless card, tapping to install an application, tapping to open a door, tapping to start / enter a vehicle, tapping to unlock a device, etc. The embodiments are not limited to these examples. One or more of the operations described with respect to the sequence flow 1000 may be performed as part of the operation of the tap function.

[0145] As previously described, the systems described herein are configured to support any number of tap functions using contactless cards (e.g., authentication / verification, transaction execution, automatic field entry, etc.). FIG. 11 shows an example of a routine 1100 that can be performed by the system herein to perform authentication or verification with a contactless card. In the illustrated example, the system can receive contactless card information from the contactless card via a device such as a mobile device or a POS terminal. The system can process the information to determine authenticity and generate a result. If the card is authenticated, the result may include a generated authentication token indicating that the card was successfully authenticated. In some cases, the verification token may be used to perform additional functions such as transaction execution, as discussed in more detail in FIG. 14 and routine 1400. Other functions include opening a door, obtaining information, automatically entering a field, launching an application, providing multi-factor authentication, etc.

[0146] In block 1102, routine 1100 includes receiving, by the system, a request that includes a message related to the execution of a verification. In an embodiment, the request may be sent to the switchboard system 1608 via a post to an API. Specifically, the switchboard system 1608 can include a set of APIs configured to receive a request to authenticate a user and provide a response. In this example, the request is a verification or authentication and includes a message having an encrypted portion and an unencrypted portion. In certain embodiments, the request may also include a session token and extensions. The following is an example of the format of the request.

[0147] POST / validation { "tapMessage": "encrypted_portion / decrypted_portion", "sessionToken": "abcdefg..." / / Token from Session Initialization "extensions": {...}}

[0148] Note that the embodiments are not limited to this example. In an embodiment, the encrypted portion of the message is used by the switchboard system 1608 for authentication, and the decrypted portion or the unencrypted portion of the message is used by the switchboard system 1608 to route the message to an appropriate process for performing the authentication. FIG. 5 shows an example of a message 500. In an embodiment, the unencrypted portion can be utilized by the system to determine at least where to route the message for performing the verification.

[0149] In some cases, it may be necessary to first establish a client session between the device and the system in order to obtain a verification token. In such cases, the device may send a request or post to a session initialization API that may contain usage information for the verification token. For example, the verification token may be utilized as part of a transaction, and the session initialization may be established by posting information to the API such as client information including one or more of a merchant identifier, a reader identifier, and an Internet Protocol (IP) address, geolocation, device identifier, user agent, and host name. The post to establish a session for executing a transaction can take the following form, but is not limited as such.

[0150] POST / session{ "merchantId": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "readerId": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "clientInformation": { "ipAddress": "198.xx.xxx.xx", "geolocation": {},"device": {}, "userAgent": "string”, "hostname":"example.com"}}

[0151] In an embodiment, the switchboard system 1608 can 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).

[0152] {"sessionToken": " <jwt>", "valid": true, "validUntil": "2022-02-04T19:15:39.693Z”}

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

[0154] {iss: '', / / Identifies the issuer of the JWT and should be the same value for all JWTs sub: ' <uuid>', / / Randomly generated UUID representing the session ID exp: 1648217401, / / Epoch timestamp indicating the expiration of this JWT merchantId: <merchantiduuid>, / / Merchant ID from the request payload readerId: <readeriduuid>, / / Reader ID from the request payload creationTime: 1648217401, / / An epoch timestamp indicating the point in time when the session was created}

[0155] As described above, the session token can also be included in the request for the validity token. In some cases, the session token may be included in the first request for the validity token, but not required in subsequent requests. In embodiments, the post and response to establish a session may include different usage information based on what the session is being established for. For example, if the session is for performing verification or authentication, the post may include information on the request side. For example, assume the session is established as part of an autofill process. In that case, the session is established as part of the autofill process, and the post may include usage information such as the website that receives the data, the requested data, etc. Embodiments are not limited in this way.

[0156] In block 1104, routine 1100 includes determining, by the system, a verification service associated with the contactless card issuer based on information in the unencrypted portion of the message. For example, the switchboard system 1608 can determine the contactless card issuer based on the issuer identifier included in the message. The verification service can include many processes and / or functions that can be performed to verify information included in the encrypted portion of the message.

[0157] In block 1106, routine 1100 includes sending at least an encrypted portion of the message to a verification service. Since the verification service is associated with a contactless card issuer, it can access secure data related to that specific issuer, but not to other issuers. Thus, the information of each issuing bank may be siloed to enhance data security.

[0158] In an embodiment, the verification service is configured to verify information within the message, such as MAC encryption, counter values, etc. As illustrated and described in FIGS. 12A and 12B, the verification service may send the message or at least a portion of the message (e.g., the encrypted portion) to a message verification service 724 and a ciphertext verification service 726 to perform the verification.

[0159] In an embodiment, the verification service can determine the result of the verification operation performed by the message verification service 724 and the ciphertext verification service 726 and return the result. In some cases, the request may include an indication that the validation was successful or not. Additionally, the verification may determine and / or generate a verification token that may be returned to the system for return to the device.

[0160] In block 1108, routine 1100 includes generating a verification token based on the verification service successfully verifying the information of the encrypted portion of the message. The validation token may be in the JWT format as follows.

[0161] { iss: "DistributionPartner", / / Unique identifier of the validation API implementer exp: "2022-02-04T16:57:19Z", / / Expiration of the verification token (recommended 15-minute TTL) puid: 0123456789101112, / / Unique identifier of the tapped card clientId: "3fa85f64-5717-4562-b3fc-2c963f66afa6", / / Unique identifier of the client timeVerified: "2022-02-04T16:57:19Z" / / Time when the card was considered valid}

[0162] In block 1110, routine 1100 returns a verification token to the mobile device by the system. In an embodiment, the verification token may be a response to a submission and may be in the following form.

[0163] {"requestId": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "valid": true, "validityToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ..."} Note that if the validation process fails, routine 1100 can return an indication of failure to the requesting device.

[0164] FIG. 11 includes a switchboard system 1608 and a routine executed by a device such as a mobile device for verifying contactless card information via the switchboard system 1608. However, in some cases, the device may send a request containing a message directly to the issuer system 702, and the issuer system 702 may cause the message to be verified via the verification service of the switchboard system 1608 and receive a validity token. In still other examples, the issuer system 702 may perform the verification itself and return an indication of whether the contactless card is valid or invalid.

[0165] FIG. 12A shows a detailed view of a verification system 1204 that may be part of the switchboard system 1608 and that performs one or more operations to verify information.

[0166] In some exemplary embodiments, the verification system 1204 includes a message verification service 724 configured to receive an incoming 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, as described with respect to FIGS. 4A-4C, based on a pre-processing performed by the switchboard system 1608, such as via a switchboard node, to process the issuer identifier of the unencrypted portion of the message, the request may be directed to the message verification service 724. In some cases, the message may be received from another system, such as the issuer system 702.

[0167] In an embodiment, the message verification service 724 can perform one or more services to perform an initial verification of the message. For example, the message verification service 724 can analyze the message fields to determine a card-specific identifier (e.g., pUID). The message verification service 724 can search a database, such as the card database 1202, for related card record data and use the unique identifier as a key to perform a basic verification. For example, the message verification service 724 can verify the information in the message by comparing it to the information in the record, such as 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 verification service 724 may verify that it matches the stored data of the card.

[0168] In an embodiment, the card database 1202 can store additional information, such as card personalization details including the card platform and app version, and the message verification service 724 can also confirm that the card platform and / or app version in the message match the stored information.

[0169] In some cases, the card database 1202 can also store an index or key identifier for retrieving an encryption key from the verification HSM 728, and an expected counter value. The encryption key can be used to decrypt the encrypted portion of the message. In other examples, the key identifier or index can be provided in a field of the message itself. Also, when a card record is found in the card database 1202, the message verification service 724 verifies and checks that the counter value is in sequence.

[0170] In response to the first verification being successful, the message verification service 724 records the verification request in the card database 1202 and requests the encrypted text verification service 726 to verify the encrypted text and the information in the encrypted text.

[0171] In an embodiment, the message verification service 724 can also compare whether the counter value in the message matches the counter value held in the card database 1202. In some cases, the counter value (pATC) on the card may become out of sync with the stored counter value. In such cases, the message verification service 724 can ensure that the card counter value is within the allowable range of the stored counter value. In some cases, if the card counter value is outside the allowable range of the stored counter value or is less than the stored counter value, the message verification service 724 can determine that an irregularity has occurred.

[0172] In an embodiment, the basic verification of the message verification service 724 is successful, and the message verification service 724 records the details of the transaction and verification in a log for auditability and can communicate with the ciphertext verification service 726 to verify the cipher. To verify the ciphertext, the ciphertext verification service 726 can first generate one or more key pairs for decrypting the ciphertext. In some cases, the ciphertext verification service 726 may obtain the master key associated with the issuer from the verification HSM 728 using the key identifier of the unencrypted portion of the message. The ciphertext verification service 726 can use the master key to generate a derived key based on the card or unique identifier. The derived key is used to generate a session key for a given session using a counter value held by the verification system and / or a counter value included in the message. The counter value must match or be within the range of the counter value of the contactless card. Note that in some embodiments, the ciphertext verification service 726 may start with the derived key and generate the session key instead of the master key stored in the verification HSM 728. The embodiments are not limited in this way.

[0173] In an embodiment, the ciphertext verification service 726 can decrypt the ciphertext using the decryption session key and compare the information from the ciphertext with stored information, such as information stored in the card database 1202. The information may include a shared secret. In some cases, the counter value may be included in the encrypted portion of the message, and the ciphertext verification service 726 may perform verification of the counter value.

[0174] In an embodiment, if there are also encrypted portions containing additional information such as card identifier, account number, customer name, etc., the ciphertext verification service 726 may verify them. If the decryption of the ciphertext is successful and the information matches, the ciphertext verification service 726 performs verification of the message, and the verification service returns the result of successful verification to the device. In some cases, the result may include a validity token that can be used to perform additional operations.

[0175] In some embodiments, system 700 can utilize a verification HSM 728. The verification HSM 728 may be a payment-grade HSM, store the master key used for encryption, and perform operations involving the master key, such as derivation, encryption, and decryption of other keys. However, payment-grade HSMs are very restricted and require a proprietary library to interact with the HSM. To avoid hardware dependencies and facilitate reference implementations, in some embodiments, as shown in FIG. 12B, a Java key storage 1206 that follows the same steps but uses an open-source cryptographic library is used. Embodiments are not limited in this way.

[0176] FIG. 13 shows an exemplary sequence diagram 1300 according to embodiments discussed herein. The sequence diagram 1300 shows high-level steps that may be performed to verify a user and their contactless card at a switchboard system 1306. FIG. 13 shows one possible sequence, and embodiments are not limited to this sequence. In some cases, one or more steps may be performed before and / or in parallel with other steps.

[0177] At 1312, the client device 1304 receives a request to perform user verification. For example, a mobile app such as a merchant app can generate a request to authenticate the user of the client device 1304 to perform a transaction. In another example, the app may request the user to authenticate as part of a multi-factor authentication sequence. In a third example, the app may request the user to authenticate as part of a login sequence. Embodiments are not limited in this way. In some cases, the request may be generated by the user themselves, for example, via a user interface, or by an external system such as a POS transaction system.

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

[0179] At 1316, the client device 1304 can communicate and exchange with the contactless card 1302. For example, in response to the user bringing the contactless card 1302 within the distance of 1304, wireless communication exchange may occur between the client device 1304 and the contactless card 1302. The wireless exchange may be performed according to wireless protocols such as Bluetooth (registered trademark), NFC, WiFi, etc. In some cases, the exchange may be a "wired" exchange based on the client device 1304 contacting the contact information of 1302. In an embodiment, the exchange can comply with EMV with modifications to the message as discussed herein. In some cases, the client device 1304 can read and / or receive a message from the contactless card 1302. Further, the client device 1304 can also write and / or transmit data that may be incorporated into the data read by the client device 1304, for example, nonce to the card.

[0180] In an embodiment, the client device 1304 can receive data such as a message from the contactless card 1302 as part of the exchange. The message can include an encrypted part, such as a ciphertext, and an unencrypted part. FIG. 5 shows an example of a message 500.

[0181] At 1318, the client device 1304 can send a verification request to the switchboard system 1306. The request can include a message. As explained in FIG. 11, the request may be a post to the API of the switchboard network 1308. At 1320, the switchboard network 1308 can determine where to route the request and which verification service will perform the verification. Specifically, the switchboard network 1308 can utilize the issuer identifier of the unencrypted portion of the message to determine the issuer and its verification service.

[0182] At 1322, the hub network 1308 can send the message to the verification system 1310 to be verified. The verification system 1310 can process the message using a service specifically assigned to the issuer and / or data associated with the issuer. At 1324, the verification system 1310 can perform one or more verifications as explained with respect to FIGS. 12A and 12B.

[0183] At 1326, the verification system 1310 can return the result of the verification to the switchboard network 1308, and the switchboard network 1308 can transfer the result to the client device 1304 at 1328. The result may include a verification token used to verify the user. For example, the validation token can be used as a login for the user to log in to the application. In another example, the verification token is provided to another system as part of an MFA sequence. In a third example, the authentication token may be provided to an access control system to obtain access to a door or room. As explained in more detail in FIG. 14, the verification token may be provided to the merchant system to execute a transaction after it is determined.

[0184] In an embodiment, the system 700 can be utilized to perform additional functions such as conducting transactions among a cardholder, an issuer, and a merchant. FIG. 14 shows an example routine 1400 that can be executed by a system 700 including a switchboard system 1608 to process merchant transactions. In some cases, a transaction may be initiated on a device such as a mobile device or a POS terminal.

[0185] In block 1402, routine 1400 includes receiving a request for contactless cardholder information, which may include one or more indicators, a verification token, and encryption parameters. The request for information may be necessary to execute a transaction. One or more indicators can indicate what information the merchant system is requesting to execute the transaction. The information includes the customer's name (first, middle, last), date of birth, social security number, address, account number, contactless card information (account number, CVV, expiration date), etc.

[0186] In an embodiment, the verification token may be a token provided by the system that can be used to perform functions as described in FIGS. 11, 12A, 12B, and 13. The validation token indicates that the contactless card has been authenticated by the system. In some cases, the contactless card may have been pre-authenticated or may be authenticated as part of the transaction process.

[0187] The encryption parameters can include a merchant certificate previously provided to the merchant. For example, the system can provide a unique certificate for each merchant during the onboarding process. In addition to the merchant certificate, the encryption parameters can also include a public key and a public key signature. The public key signature is used for verifying the public key along with the merchant.

[0188] In an embodiment, the request may be a post to the API interface of the switchboard system 730. 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.

[0189] POST / cardholder-information {"fields": ["firstName", "middleName", "lastName", "dob", "ssn", "address", "card"], / / Fields to return from customer record "validityToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ...", "encryptionParameters": {"certificate": "-----BEGIN CERTIFICATE-----\nQWERT....", "ephemeralPublicKey": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ...", "publicKeySignature": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ..." / / Signature of the public key. Used to verify the public key in conjunction with the certificate }}

[0190] In some cases, customer consent may be required before the information requested by the merchant is provided to the merchant. As an example, a merchant app on a device such as a mobile device or a POS device can ask the customer whether they consent to providing the information to the merchant. Thereafter, the merchant app can send the consent message as an API post to system 700, such as the switchboard system 730. The following is an example of the POST format.

[0191] POST / cardholder-information / consent { "fields": ["firstName", "middleName", "lastName", "dob", "ssn", "address", "card"], / / Fields to be returned from customer record "validityToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ...", "sessionToken": "abc..." / / Token from session initialization }

[0192] Consent can include the display of information permitted to be provided to the merchant, a validity token, and a session token. In some cases, system 700 can send a confirmation request to the device, for example, via the issuer's mobile app. If consent is given successfully, system 700 can return a successful response to the consent-to-share request. The following is an example of such a response.

[0193] 700 OK {"requestId": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "success": true}

[0194] In block 1404, routine 1400 includes determining the commerce services associated with the contactless card issuer. For example, switchboard system 730 can perform a lookup to determine the issuer associated with the contactless card based on the information in the cardholder information request. In a specific example, switchboard system 730 can utilize the validity token to determine the issuer. As discussed, the validity token includes information such as the issuer or sales partner, and switchboard system 730 can utilize the information to determine the relevant commerce service(s) to further process the request.

[0195] In block 1406, routine 1400 includes sending at least a portion of the request to a commerce service. The commerce service may be part of the switchboard system 1608, such as a "merchant / commerce api", and performs one or more operations. Specifically, the commerce service verifies the validity token and the information within the validity token. In an embodiment, the validity token is encrypted via a public key obtained by the merchant and transmitted to the commerce service. The commerce service includes the associated private key and can perform decryption before verifying the information within the token.

[0196] The commerce service also confirms that the cardholder has consented to the provision of the requested information. For example, the commerce service can confirm that the customer has consented to a shared record on the service system 734.

[0197] In an embodiment, the commerce service can be configured to obtain data that the customer has consented to share in response to verification of the validity token. In some cases, the commerce service may also obtain information from the issuer system 702 via an API. For example, the commerce service sends a request to the issuer system 702, which includes one or more indicators, a validity token, and encryption parameters. In an embodiment, the issuer system 702 can verify the merchant certificate based on information provided by the merchant during the onboarding process.

[0198] The issuer system 702 can 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 702 so that the switchboard system 730 cannot "see" or decrypt the information. Thus, the customer's information is securely held by the issuer system 702 and / or the switchboard system 730 and is only displayed to the merchant system to execute the transaction.

[0199] In one example, the issuer system 702 can generate an Elliptic Curve Diffie-Hellman (ECDH) secret and encrypt the requested cardholder data. The issuer system 702 can return the encrypted data and the contactless card issuer certificate to the commerce service and switchboard system 730. Further, at block 908, routine 1400 includes receiving the contactless cardholder information and the contactless card issuer certificate, for example, from the issuer system 702.

[0200] At block 1410, routine 1400 includes sending a response to the merchant system for a request for contactless cardholder information. The response may include encrypted cardholder information. In this way, information is securely exchanged between the issuer system 702 and the merchant system 706. The response may include a request identifier that identifies the associated request (see block 1402), an indication of 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 and the issuer certificate. The public key, the public key signature, or both can be encrypted with the merchant's public key so that only the merchant system 706 can decrypt the public key and the signature. The unencrypted public key is used to encrypt the information sent to the issuer system 702, and the issuer system 702 can decrypt the information with the issuer's private key.

[0201] The merchant system 706 can verify the issuer certificate based on information exchanged between the merchant system 706 and the issuer system 702 during the onboarding process. The merchant system 706 can decrypt the public key and the signature with the merchant's private key to obtain the key and the signature. The signature of the certificate can be used to verify the issuer's public key. The following are example responses. Note that the embodiments are not limited in this way, and the responses may take different forms.

[0202] {"requestId": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "success": true, "cardholderInformation": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ....", / / Encrypted cardholder information "encryptionParameters": { "ephemeralPublicKey": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ...." / / Ephemeral key encrypted with the public key provided by the merchant "certificate": "-----BEGIN CERTIFICATE-----\nQWERT....", "publicKeySignature": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ..." / / Signature of the public key. Used to verify the public key in conjunction with the certificate },}

[0203] In an embodiment, the merchant system 706 can receive the encrypted cardholder information and decrypt it with the merchant's private key. In an embodiment, the merchant system 706 can use the information to perform a transaction or another function (e.g., enter it into one or more fields of a checkout form, store the information in a secure data store for future use, etc.).

[0204] FIG. 15 shows an example of a sequence diagram 1500 executed according to an embodiment. This sequence may be executed among the systems discussed herein as part of a transaction process in which a merchant utilizes a verification token to obtain information for performing a transaction.

[0205] At 1514, the client device 1502 can send a request to the merchant system 1504 to execute a transaction. The transaction may be a purchase of goods or services, and the embodiments are not limited in this regard. In an embodiment, the request can include information regarding the transaction, identifier, purchased item, customer information, etc. In an embodiment, the request can also include a verification token that the merchant system 1504 can use to execute a transaction with a backend banking system, such as a switchboard system 1506 and an issuer system 1512. The verification token may have been previously obtained according to the processing flow and sequence described above.

[0206] At 1516, the merchant system 1504 can send a request for information to execute a transaction to the switchboard system 1508 of the switchboard system 1506. The request is an API POST and includes a list (fields) of the requested information, a verification token, and encryption information that may be used to encrypt the requested information. FIG. 14 in block 1402 describes an example of an API POST format according to an embodiment.

[0207] At 1518, the switchboard system 1508 can utilize the requested information to determine the issuer and / or commerce system associated with the transaction. For example, the switchboard system 1508 can utilize the verification token to determine the associated issuing bank and the corresponding commerce system.

[0208] At 1520, the switchboard system 1508 can send a request to the determined commerce system 1510 and process the request to determine information. Further, at 1522, the commerce system 1510 can send a request for the requested information to the issuer system 1512. The issuer system 1512 can use encryption information to encrypt the requested information so that the data is secure and unidentifiable until the merchant system 1504 receives and decrypts the information, as described in FIG. 14.

[0209] At 1524, the issuer system 1512 can determine information based on the request and encrypt the information. The encrypted information may be returned to the commerce system 1510 at 1526. The commerce system 1510 can send the encrypted information to the switchboard system 1508 at 1528. The encrypted information remains secure, and neither the system nor the switchboard system 1506 may have the ability to decrypt the information. And the information remains secure until it is decrypted by the merchant system 1504. At 1530, the switchboard system 1508 sends the encrypted information to the merchant system 1504. The merchant system 1504 decrypts the information and can use the information to finalize the transaction at 1532.

[0210] FIG. 16 shows an example of a simplified processing flow 1600 that may be executed according to an embodiment. Specifically, the processing flow 1600 may be executed in an environment that utilizes a switchboard system 108 / 208 that provides processing and communication in a plurality of bank-issuing system environments. The processing flow 1600 is an example of a flow for executing a transaction between a merchant and a customer using a contactless card issued by any of a plurality of issuing banks, and includes both obtaining a verification token (as described in FIGS. 7A and 7B - 9) and obtaining transaction information (as described in FIGS. 10 and 11).

[0211] At line 1602, the user can tap the contactless card of the mobile device 104. As an example, the user can tap the contactless card on the device in response to a prompt displayed by the mobile app prompting to tap the card. The contactless card provides data to the mobile device 104, and the mobile device 104 can transfer that data to the switchboard system 1608. The data includes encrypted data and unencrypted data within a message such as message 900b.

[0212] At line 1604, the switchboard system 1608 can utilize the data within the message to determine a card validator, such as a validation service. For example, the switchboard system 1608 can perform a lookup using unencrypted data, such as the issuer ID 910, and determine a verification service 720 for routing the message.

[0213] The switchboard system 1608 can send the message to a corresponding verification service 720 that includes a verification API configured to process messages containing encrypted portions. Specifically, the corresponding verification service 720 may decrypt the encrypted portion and authenticate the data, as described, for example, in FIGS. 12A or 12B.

[0214] At line 1606, the verification service 720 can communicate and return a validity token to the switchboard system 1608 and the mobile device 104. At line 1610, the merchant system 706 requests user / consumer information from the switchboard system 1608 along with a request for cardholder information including a valid token and other data, as described in FIG. 14. The switchboard system 1608 can perform a lookup with the corresponding card issuer based on the information received from the merchant system 706 (e.g., the validity token).

[0215] Switchboard system 1608 communicates with the issuer network and corresponding card issuer's commerce services and receives encrypted user / consumer information at row 1614. The switchboard system 1608 can return the encrypted user / consumer to the merchant system 706, and the merchant system 706 decrypts the information to perform a transaction or another function.

[0216] FIG. 17 shows a simplified example of an encryption flow 1700 that can be executed in accordance with the embodiments discussed herein to ensure that data communicated between an issuer system and a destination system such as merchant system 1714 is secure. At 1702, merchant 1714 requests card member information from switchboard system 1716 in a request message, e.g., via an API. At 1704, encryption flow 1700 includes the switchboard system 1716 performing a lookup to determine the card issuer in order to determine the commerce API 1718 that routes the data. The data is transmitted to the associated commerce API service. At 1706, the certificate authority 1720 verifies the merchant certificate and the result is returned. At 1708, service 1718 generates an ECDH secret (or public / private key pair) and the flow of encrypting the card member data is included. The card member data is notified to merchant 1714 at 1708. At 1710, encryption flow 1700 includes the merchant system verifying the certificate. Further, at 1712, encryption flow 1700 includes the merchant generating an ECDH secret and decrypting the card member data.

[0217] FIG. 18 shows a distributed network authentication system 1900 according to an exemplary embodiment. As will be described further below, system 1900 can include client node 1802, API 1804, network 1806, distributed ledger node 1810, mapping 1812, and client device 1814. FIG. 18 illustrates a single instance of the components, but system 1900 can include any number of components.

[0218] System 1900 can include client node 1802, which can be a network-enabled computer as described herein. In some cases, client node 1802 can be a server and can be a dedicated server computer, 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 capable of supporting system 1900.

[0219] In some cases, client node 1802 can execute one or more applications, such as software applications, that enable network communication with one or more components of system 1900, send and / or receive data, and perform the functions and processes described herein.

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

[0221] API 1804 can be provided in the form of a library that includes specifications of routines, data structures, object classes, and variables. In some cases, such as Representational State Transfer (REST) services, an API (e.g., a REST API, a RESTful API, or an API that embodies RESTful practices) is a specification of remote calls that are exposed to API consumers (e.g., an application running on a client computing device can become a consumer of a REST API by making a remote call to the REST API). REST services generally refer to a software architecture for coordinating components, connectors, and / or other elements within a distributed system (such as a distributed hypermedia system).

[0222] The client node 1802 can communicate with one or more other components of the system 1900 directly or via the network 1806. The network 1806 can be composed of 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 the components of the system 1900. FIG. 18 shows the communication between the components of the system 1900 via the network 1806, but it is understood that any component of the system 1900 can communicate directly with another component of the system 1900 without, for example, going through the network 1806.

[0223] System 1900 can include a verification node 1808, which can be a network - enabled computer as described herein. In some cases, the verification node 1808 can be a dedicated server computer, a blade server, or a server that can be 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.

[0224] In some cases, the verification node 1808 can execute one or more applications, such as a software application, that enables network communication with one or more components of System 1900, transmits and / or receives data, and performs the functions and processes described herein.

[0225] In some cases, each verification node can be associated with a routing number that identifies an entity that manages keys for an authentication namespace. The authentication namespace can be associated with one or more specific sets of security keys (such as master keys, diversified keys, session keys, etc.) associated with a particular entity, a particular card set, or an entity, card set, or card type.

[0226] System 1900 can include a distributed ledger node 1810, which can be a network - enabled computer as described herein. In some cases, the distributed ledger node 1810 can be a dedicated server computer, a blade server, or a server that can be 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.

[0227] In some cases, the decentralized ledger node 1810 can execute one or more applications, such as a software application, that enable network communication with one or more components of the system 1900, transmit and / or receive data, and perform the functions and processes described herein.

[0228] The decentralized ledger node 1810 can include a mapping 1812. In some cases, the mapping 1812 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 decentralized. The one or more databases can be internally hosted by any component of the system 1900, or one or more databases can be externally hosted with respect to any component of the system 1900. In one example, the one or more databases are included in the decentralized ledger node 1810, and in other examples, the one or more databases are stored external to the decentralized ledger node 1810 but are capable of data communication with the decentralized ledger node 1810. 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 (registered trademark), Hypertext Markup Language, JavaScript, Hypertext Preprocessor language, Practical Extraction and Report Language, Extensible Markup Language, and 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 to the databases can be made in SQL (e.g., SELECT column1, column2 FROM table1, table2 WHERE column2='value';). It is understood that the one or more databases can be implemented in any database programming language, and the programming implementation of the queries can be adjusted as needed for compatibility with the one or more databases and to reflect the specific information being queried.

[0229] In some cases, one or more databases may be included within the distributed ledger node 1810. In other examples, one or more databases are remote from the distributed ledger node 1810 but are capable of data communication with the distributed ledger node 1810. Data communication between the one or more databases and the distributed ledger node 1810 can be either direct data communication or data communication via a network such as the network 1806.

[0230] In some cases, the client node 1802 can perform data communication with the distributed ledger node 1810. The distributed ledger node 1810 can include a mapping 1812. The mapping 1814 can include, for example, a mapping between a verification node address and the verification node 1808, a mapping between a routing number and a verification node address, and / or a mapping between a routing number and the verification node 1808. In some cases, the mapping 1812 can include a digital signature associated with an entity having permission to verify a routing number. Based on one or more of these associations, the client node 1802 can call a verification node for verification and / or provide instructions to the client device for reaching an appropriate verification node. This can be achieved by calling a verification API associated with the verification node 1808.

[0231] In some cases, the iteration of mappings described herein, such as the mapping 1812, can also include a version number of software or an applet. The version number can be used to identify a verification node or a verification node address or to select from multiple verification addresses for one verification node.

[0232] In some cases, the client node 1802 and the distributed ledger node 1810 are permitted (e.g., permitted to participate in the network) with the help of certificates and / or cryptographic authentication mechanisms (e.g., non-perishable tokens). The certificates and / or cryptographic authentication mechanisms may be issued, for example, by a consortium institution or other management entity associated with the distributed network. If appropriate permissions are granted, the distributed ledger node 1810 can update the mapping 1812 to reflect, for example, routing numbers, addresses of verification nodes, and different associations between verification nodes. In some cases, the degree of permission can be issued. For example, if the client node 1802 has the function of routing data to the verification node 1808 (or other verification nodes), a certain level of permission can be given to the client node 1802. As another example, if the distributed ledger node 1810 has the ability to update the mapping 1812, the distributed ledger node 1810 can have different, higher levels of permission.

[0233] System 1900 may include a client device 1814, which can be a network-enabled computer as described herein. In some cases, the distributed ledger node 1814 can be a server, can be a dedicated server computer, a blade server, or can also be 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 1814 can also be a mobile device. For example, the mobile device can include an Apple® iPhone®, iPod®, iPad®, or other mobile device running Apple's iOS® operating system, a device running Microsoft's Windows® Mobile operating system, a device running Google's Android® operating system, and / or other smartphones, tablets, or similar wearable mobile devices. In some cases, the client device 1814 can communicate data with another network-enabled computer, such as a smart card (e.g., a contactless card or a contact card), not shown in FIG. 18.

[0234] In some cases, the client device 1814 can run one or more applications, such as software applications, that enable network communication with one or more components of System 1900, send and / or receive data, and perform the functions and processes described herein.

[0235] In some cases, upon receiving an authentication request, the client device 1814 can call the client node 1802 (e.g., via an API). The call can include a routing number and / or an applet or software version number, and the client node 1802 can query the distributed ledger node 1810 and the mapping 1812. When the query returns the identification of a verification node (e.g., verification node 1808), and / or the verification node address associated with its routing number and / or applet or software version, the client node 1802 can reply to the client device 1814. Thereafter, the client device 1814 can proceed with authentication with the verification node. Authentication can be performed, for example, by the systems and methods described herein, such as the generation, encryption, transmission, decryption, and verification of ciphertexts described herein.

[0236] In some cases, the client node 1802 can co-reside with the verification node 1808. In these examples, the client node 1802 can handle authentication with a single call from the client device 1814. In some examples, this can be allowed only if it is permitted to send a complete authentication transmission (e.g., a ciphertext as described herein) to a client node not involved in the authentication.

[0237] In some cases, if the client node 1802 receives from the client device 1814 a routing number that is not handled at its location, the client node 1802 can return a code indicating that this routing number is not handled, along with the verification node address of the responsible verification node. Thereafter, the client device 1814 can use the received verification node address to send a complete authentication transmission to the verification node 1808.

[0238] In some cases, the client node 1802 can enter the distributed network with different permissions. For example, the client node 1802 can become a read-only router for data. As another example, the client node 1802 can have permission to send a message to the distributed ledger node 1810 to update one or more routing paths of one or more routing numbers. However, the client node 1802 is prevented from updating one or more routing paths of one or more routing numbers of other entities that are not associated with or have not been granted this permission by the client node 1802. As another example, the distributed ledger node 1810 can include contracts and / or records that can verify the permission of a specific entity to modify a specific routing record based on its digital signature. As another example, the consortium institution or other management entity controlling the distributed network can have the right to add, among other things, new members (e.g., client nodes, distributed ledger nodes, verification nodes, and / or client devices), new signature credentials, new keys, new certificates, and further additional rights to revoke any of the foregoing. In some cases, when security, legal, and / or financial conditions are met, the foregoing permissions can be delegated to the client node 1802, the distributed ledger node 1810, and / or the verification node 1808, but delegation is not mandatory.

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

[0240] In some cases, entities can establish standards for nodes with APIs based on the intended functions of those nodes. For example, a first standard can be established for data routing nodes and a second standard can be established for nodes that perform mapping and / or authentication functions. As another example, routing APIs, mapping APIs, and verification APIs can be established such that these functions can be performed with the same device or hardware configuration. However, if verification node 1808 uses a key that includes a private key for authentication, it may be necessary to store the key in one or more HSMs to enhance the security of the key and prevent the key from being entered into memory.

[0241] FIG. 19 shows a method 1900 performed by a distributed network authentication system according to an exemplary embodiment. For example, this method can be performed by distributed network authentication system 1800 or another distributed network authentication system.

[0242] In block 1902, a client device can send an authentication request to a 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.

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

[0244] In block 1906, the query can return the identification information of the verification node and / or the address of the verification node, and the distributed ledger node can send this identification information to the client node.

[0245] In block 1908, the client node can send the identification information to the client device. After receiving the identification, the client device can proceed with authentication with the identified verification node and / or the verification node address in block 1910.

[0246] FIG. 20 shows an embodiment of an exemplary computer architecture 2000 suitable for implementing various embodiments as described above. In one embodiment, the computer architecture 2000 can include or be implemented as part of one or more of the systems or devices discussed herein.

[0247] As used in this application, the terms "system" and "component" are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by exemplary computing architecture 2000. For example, a component may be, but is not limited to, a process running on a processor, a processor, a hard disk drive, a plurality of storage drives (optical and / or magnetic storage media), an object, an executable file, an execution thread, a program, and / or a computer. For instance, an application operating on a server and the server can both 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 or distributed between two or more computers. Further, components can be communicatively coupled to each other by various types of communication media and can coordinate their operations. The coordination includes one-way information exchange and two-way information exchange. For example, a component can communicate information in the form of signals communicated through a communication media. The information can be implemented as signals assigned to various signal lines. In such an assignment, each message becomes a signal. However, in further embodiments, data messages can alternatively be employed. Such data messages can be transmitted through various connections. Exemplary connections include parallel interface, serial interface, and bus interface.

[0248] Computing architecture 100 includes various common 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, the embodiments are not limited to implementation by computing architecture 100.

[0249] As shown in FIG. 20, computing architecture 100 includes a processor 2012, a system memory 2004, and a system bus 2006. The processor 2012 may be any of a variety of commercially available processors.

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

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

[0252] System memory 2004 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 media suitable for storing information. In the illustrated embodiment shown in FIG. 20, system memory 2004 can include non-volatile 2008 and / or volatile 2010. The basic input / output system (BIOS) can be stored in non-volatile 2008.

[0253] Computer 2002 can include various types of computer-readable storage media in the form of one or more low-speed memory units, such as an internal (or external) hard disk drive 2030, a magnetic disk drive 2016 for reading from or writing to a removable magnetic disk 2020, and an optical disk drive 2028 for reading from or writing to a removable optical disk 2032 (e.g., CD-ROM or DVD). The hard disk drive 2030, the magnetic disk drive 2016, and the optical disk drive 2028 can be connected to the system bus 2006 by an HDD interface 2014, and an FDD interface 2018, and an optical disk drive interface 2034, respectively. The HDD interface 2014 for external drive implementation can include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

[0254] The drives and associated computer-readable media provide volatile and / or non-volatile storage such as data, data structures, computer-executable instructions, etc. For example, a number of program modules, such as an operating system 2022, one or more applications 2042, other program modules 2024, and program data 2026, can be stored on the drive and non-volatile 2008, as well as volatile 2010. In one embodiment, one or more applications 2042, other program modules 2024, and program data 2026 can include, for example, various applications and / or components of the systems discussed herein.

[0255] The user can input commands and information into the computer 2002 via one or more wired / wireless input devices such as a pointing device like a keyboard 2050 or a mouse 2052. Other input devices include a microphone, an infrared (IR) remote control, a radio frequency (RF) remote control, a game pad, a stylus pen, a card reader, a dongle, a fingerprint reader, a glove, a graphic tablet, a joystick, a keyboard, a retina reader, a touch screen (capacitive, resistive, etc.), a trackball, a track pad, a sensor, a stylus, and the like. These and other input devices are often connected to the processor 2012 via an input device interface 2036 coupled to the system bus 2006, but can also be connected by other interfaces such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.

[0256] A monitor 2044 or other type of display device is also connected to the system bus 2006 via an interface such as a video adapter 2046. The monitor 2044 can be either inside or outside the computer 2002. In addition to the monitor 2044, a computer typically includes other peripheral output devices such as speakers, printers, and the like.

[0257] Computer 2002 can operate in a network environment using logical connections for wired and / or wireless communication with one or more remote computers, such as remote computer 2048. The remote computer(s) 2048 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based consumer electronics, peer device, or other common network node, and typically includes many or all of the elements described in relation to computer 2002, but only memory and / or storage device 2058 is shown for simplicity. The logical connections depicted include wired / wireless connections to local area network 2056 and / or a larger network, such as wide area network 2054. Such LAN and WAN network environments are common in offices and companies, facilitating enterprise-wide computer networks such as intranets, all of which can be connected to a global communication network such as the Internet.

[0258] When used in a local area network 2056 network environment, computer 2002 is connected to local area network 2056 via a wired and / or wireless communication network interface or network adapter 2038. Network adapter 2038 can facilitate wired and / or wireless communication to local area network 2056, which can also include a wireless access point disposed thereon to communicate with the wireless capabilities of network adapter 2038.

[0259] When used in a wide area network 2054 network environment, computer 2002 can include a modem 2040, or be connected to a communication server on wide area network 2054, or have other means for establishing communication via wide area network 2054, such as via the Internet. Modem 2040 is an internal or external wired and / or wireless device and is connected to system bus 2006 via input device interface 2036. In a network environment, program modules depicted in relation to computer 2002, or portions thereof, can be stored in remote memory and / or storage device 2058. The network connections shown are exemplary, and it will be understood that other means of establishing a communication link between computers can be used.

[0260] Computer 2002 is operable to communicate with wired and wireless devices or entities that use standards of the IEEE802 family, such as wireless devices (e.g., IEEE 802.11) operably arranged for wireless communication. This includes at least Wi-Fi (or Wireless Fidelity), WiMax, Bluetooth® wireless technologies, etc. Thus, the communication can be in a pre-defined structure like a conventional network or can be merely an ad-hoc communication between at least two devices. A Wi-Fi network uses wireless technologies called IEEE802.11 (a, b, g, n, etc.) to provide a secure, reliable, and high-speed wireless connection. Wi-Fi networks can be used to connect computers to each other, to the Internet, and to wired networks (using media and functions related to IEEE802.3).

[0261] As described above in this specification, the various elements of the apparatus include various hardware elements, software elements, or combinations of both. Examples of hardware elements can include devices, logic 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, and the like. 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, determining 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, thermal tolerance, processing cycle budget, input data speed, output data speed, memory resources, data bus speed, and other design or performance constraints for a given implementation.

[0262] The components and functions of the above-described device can be implemented using any combination of discrete circuits, application-specific integrated circuits (ASICs), logic gates, and / or single-chip architectures. Further, the functions of the present device can be implemented using a microcontroller, a programmable logic array, and / or a microprocessor, or preferably any combination of the foregoing. It should be noted that herein, hardware, firmware, and / or software elements may sometimes be referred to collectively or individually as "logic" or "circuit."

[0263] FIG. 21 is a block diagram showing an exemplary communication architecture 2100 suitable for implementing various embodiments as described above. The communication architecture 2100 includes various common 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, this embodiment is not limited to implementation by the communication architecture 2100 and may be consistent with the systems and devices described herein.

[0264] As shown in FIG. 21, the communication architecture 2100 includes one or more clients 2102 and a server 2104. The server(s) 2104 can implement one or more functions and embodiments discussed herein. The clients 2102 and the server 2104 are operatively connected to one or more respective client data stores 2106 and server data stores 2108 that can be employed to store information local to each of the respective clients 2102 and the server 2104, such as cookies and / or related context information.

[0265] Client 2102 and server 2104 can communicate information with each other using communication framework 2110. Communication framework 2110 can implement well-known communication technologies and protocols. Communication framework 2110 can 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 (appropriate gateways and translators).

[0266] The communication framework 2110 can implement various network interfaces arranged to receive, communicate with, and connect to a communication network. The network interface can be regarded as a special form of the input / output (I / O) interface. The network interface can adopt connection protocols including, but not limited to, direct connect, Ethernet (such as 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 can be used to connect to various types of communication networks. For example, multiple network interfaces can be adopted to enable communication via broadcast, multicast, and unicast networks. When the processing requirements need higher speed and capacity, a distributed network controller architecture can also be adopted to increase the communication bandwidth required by the client 2102 and the server 2104 by pooling, load balancing, and other methods. The communication network can be any one and a combination of wired networks and / or wireless networks, including, but not limited to, direct interconnection, custom connections protected by security, private networks (such as enterprise intranets), public networks (such as the Internet), personal area networks (PAN), local area networks (LAN), metropolitan area networks (MAN), operating missions as nodes on the Internet (OMNI), wide area networks (WAN), wireless networks, cellular networks, and other communication networks.< / readeriduuid> < / merchantiduuid> < / uuid> < / jwt> < / puid> < / message> < / nonce> < / nonce>

Claims

1. A computer-implemented method, comprising: receiving, by a node in a system, a request to establish a session for executing a function from a client device, wherein the function is executed at least in part using a contactless card; generating, by the node, session information corresponding to the session for executing the function, wherein the session information includes a nonce and a signed session token; transmitting, 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, wherein the issuer identifier is related to the issuer of the contactless card; identifying, by the node, a device related to the issuer identifier; communicating, by the node, with the device to securely execute the function. A computer-implemented method comprising the above.

2. The computer-implemented method according to claim 1, further comprising verifying the signed session token before extracting the issuer identifier from the message. The computer-implemented method according to claim 1.

3. The signed session according to claim 1 is a JavaScript Object Notation (JSON) Web Token (JWT). The computer-implemented method according to claim 1.

4. The signed session token is composed of the nonce, client session information, and a function request using the private key of the node. The computer-implemented method according to claim 1.

5. The client session information includes session identification information for identifying the session. The computer-implemented method according to claim 4.

6. The session information further includes terms of use and a version of the terms of use. The computer-implemented method according to claim 1.

7. The computer-implemented method according to claim 6, further comprising receiving from the client device a consent date for the terms of use and the version of the terms of use. The computer-implemented method according to claim 6.

8. The node is located in a region mapped to the time zone of the client device. The computer-implemented method according to claim 1. Claim 9 The message includes the issuer identifier, issuer key identifier (pKey ID), card unique identifier (pUID), the nonces, and the ciphertext. The computer-implemented method according to claim 1. Claim 10 The issuer identifier is in plain text and identifies the issuer of the contactless card, a device associated with the issuer of the contactless card, or both. The computer-implemented method according to claim 1. Claim 11 A computing device comprising: a processor; when executed by the processor, causing the processor to: receive a request to establish a session for executing a function from a client device, wherein the function is executed at least in part using a contactless card; generate session information corresponding to the session for executing the function, wherein 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 from the message, wherein the issuer identifier is related to the issuer of the contactless card; identify a device associated with the issuer identifier; communicate with the device to securely execute the function; a memory storing instructions to cause the above to be performed. A computing device. Claim 12 when executed by the processor, further comprising instructions to cause the processor to verify the signed session token before extracting the issuer identifier from the message. The computing device according to claim 11. Claim 13 The signed session is a JavaScript Object Notation (JSON) Web Token (JWT). The computing device according to claim 11. Claim 14 The signed session token includes the nonce, client session information, and a function request by a secret key of the node. The computing device according to claim 11. Claim 15 The client session information includes session identification information for identifying the session. The computing device according to claim 14. Claim 16 The session information further includes a usage agreement for the function and a version of the usage agreement. The computing device according to claim 11. **Claim 17** receiving, from the client device, a consent date for the usage agreement for the function and the version of the usage agreement. The computing device according to claim 16. **Claim 18** The node is located in a region mapped to the time zone of the client device. The computing device according to claim 11. **Claim 19** The message includes an issuer identifier, an issuer key identifier (pKey ID), a card unique identifier (pUID), a nonce, and a ciphertext. The computing device according to claim 11. **Claim 20** The issuer identifier is in plain text and identifies the issuer of the contactless card, a device related to the issuer of the contactless card, or both. The computing device according to claim 11.

Images