Techniques for handling contactless card functionality in multiple banking system environments

Abstract

A system and technique for performing functions in multiple banking system environments using switch routing.

Description

[0001] Related Applications

[0002] This application claims here under 35 U.S.C. §119 to co-pending provisional patent application No. 63 / 350,699, filed on June 9, 2022, by Casey Scott Barrett et al., entitled “TECHNIQUES TO PROVIDE CONTACTLESS CARD TAP TO PERFORM FUNCTIONS IN MULTIPLE BANKING SYSTEM ENVIRONMENT,” co-pending provisional patent application No. 63 / 351,652, filed on June 13, 2022, by Casey Scott Barrett et al., entitled “TECHNIQUES TO PERFORM TAP TO VERIFICATION WITH CONTACTLESS CARD,” and co-pending provisional patent application No. 63 / 351,652, filed on June 13, 2022, by Casey Scott Barrett et al., entitled “TECHNIQUES TO PROVIDE SECURE CRYPTOGRAPHIC AUTHENTICATION OF CONTACTLESS CARDS BY DISTRIBUTED ENTITIES" by the present invention. The disclosures of these provisional patent applications are incorporated herein by reference. Background Art

[0003] Contactless card products have become so well known and ubiquitous that they have fundamentally changed the way today's society views and conducts financial transactions and behaviors. Contactless card products are typically represented by a plastic or metal card-type member that is supplied and provided to customers through credit card issuers (such as banks and other financial institutions). With the card, an authorized customer or cardholder is able to purchase services and / or goods without the need to immediately exchange cash directly. Data security and transaction integrity are critical to businesses and customers who facilitate these transactions. As the use of contactless cards to perform electronic transactions accounts for an increasing share of commercial activities, this demand continues to grow. Therefore, there is a need to provide businesses and users with appropriate solutions that overcome current deficiencies to provide data security, authentication and verification for contactless cards. Summary of the invention

[0004] In one aspect, a computer-implemented method includes receiving, by a node in a system, a request from a client device to establish a session to perform a function, wherein the function is performed at least in part using a contactless card, generating, by the node, session information corresponding to the session to perform the function, wherein the session information includes a random number and a signed session token, sending, by the node, the session information to the client device, receiving, by the node, a message from the contactless card via the client device, extracting, by the node, a card issuer identifier from the message, the card issuer identifier being associated with an issuer of the contactless card, identifying, by the node, a device associated with the card issuer identifier, and communicating, by the node with the device to securely perform the function.

[0005] In one aspect, a computing device includes a processor. The computing device also includes a memory storing instructions that, when executed by the processor, cause the processor to receive a request from a client device to establish a session to perform a function, wherein the function is performed at least in part using a contactless card, generate session information corresponding to the session to perform the function, wherein the session information includes a random number 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, the issuer identifier is associated with an issuer of the contactless card, identify a device associated with the issuer identifier, and communicate with the device to securely perform the function.

[0006] In one aspect, a non-transitory computer-readable storage medium includes instructions that, when executed by a computer, cause the computer to receive a request from a client device to establish a session to perform a function, wherein the function is performed at least in part using a contactless card, generate session information corresponding to the session to perform the function, wherein the session information includes a random number 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, the issuer identifier being associated with an issuer of the contactless card, identify a device associated with the issuer identifier, and communicate with the device to securely perform the function. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] To facilitate identification of the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which the element is first introduced.

[0008] Figure 1 An example of a system 100 according to an embodiment is shown. Figure 2 An example of a system 200 configured to operate in accordance with the embodiments discussed herein is shown.

[0009] Figure 3 An example of a sequence 300 is shown according to an embodiment.

[0010] Figures 4A-4C is an example of a sequence 400 according to an embodiment.

[0011] Figure 5 An example of a message 500 is shown according to an embodiment.

[0012] Figure 6 Routine 600 is shown according to one embodiment.

[0013] Figure 7 An example of a system 700 is shown in accordance with an embodiment.

[0014] Figure 8 A contactless card 102 is shown according to one embodiment.

[0015] Fig. 9 A transaction card component 900 is shown according to one embodiment.

[0016] Fig.10 A sequence flow 1000 is shown according to an embodiment.

[0017] Fig.11 Routine 1100 is shown according to an embodiment.

[0018] Fig. 12A An example of a system 1204 is shown according to an embodiment.

[0019] Fig. 12B An example of a system 1204 is shown according to an embodiment.

[0020] Fig.13 An example of a sequence 1300 is shown, according to an embodiment.

[0021] Fig.14 Routine 1400 is shown according to one embodiment.

[0022] Fig.15 An example of a sequence 1500 is shown, according to an embodiment.

[0023] Fig.16 An example of a sequence 1600 is shown, according to an embodiment.

[0024] Fig.17 An example of a sequence 1700 is shown, according to an embodiment.

[0025] Fig.18 An example of a system 1800 is shown according to an embodiment.

[0026] Fig.19 An example of a routine 1900 is shown according to an embodiment.

[0027] Fig. 20 A computer architecture 2000 is shown according to one embodiment.

[0028] Fig.21 A communication architecture 2100 is shown according to one embodiment. DETAILED DESCRIPTION

[0029] Embodiments may generally be directed to implementing contactless card functions in a multi-issuer computing environment. These functions may include tap functions, where a user may tap their contactless card on a device (such as a mobile device) to perform a function. For example, a user may use their contactless card to verify their identity, perform a payment, launch an application, log into an application, automatically fill a form or field, navigate to a specified network location or application on a device, unlock a door, initiate a contactless card, etc.

[0030] The system discussed here can enable users to perform these functions in a multi-card issuer environment. In addition, the system discussed herein enables card issuers (such as banks) to issue contactless cards with a tapping function to customers while maintaining a high level of security. The system discussed is different from previous solutions because they provide a single platform for multiple card issuers or banks to provide the tapping function. Traditionally, each card issuer or bank will need to establish and maintain its own system to provide contactless card features. This includes maintaining its own hardware, software, database, security protocols, etc., which can become very expensive for the card issuer or bank to maintain. However, the embodiment discussed enables the card issuer or bank to unload most of the processing, storage and security functions to a neutral or central system. As will be discussed in more detail, the central system is configured to provide contactless card features for multiple card issuers while maintaining a high level of security and data integrity. The functions and data of each card issuer can be managed and protected separately, so that another card issuer or bank cannot access the data or functions of another card issuer. As will be discussed in more detail, these features can be provided by a switch system configured to process and execute each contactless card function in a secure manner. Other benefits to card issuers can include providing highly secure authentication options for mobile networks, which typically lack strong authentication options available in local applications.

[0031] In addition, the embodiments discussed herein utilize App and SDK and Supported on two major mobile platforms A tap mobile web experience on . An embodiment includes providing a tap software development kit including The functions and services on the platform that perform the operations discussed in this article. The SDK can be installed into a host application, such as a native application or a web browser application, and includes App Yes. The SDK provides functional support for near field communication between mobile devices and contactless cards, via App Install local applications and provide the ability to obscure data and / or display portions. In one example, the SDK can be configured to download applications from an application store such as App Store) to download and install the app.

[0032] exist In an operating system environment, embodiments include using a JavaScript SDK and a native Android SDK. The JavaScript SDK can be installed into a website, for example, via the website source code or an application. The JavaScript SDK also includes a The JavaScript SDK may also include functionality to provide customizable user interface (UI) capabilities and obfuscation. In an embodiment, the JavaScript SDK supports websites using Hypertext Transfer Protocol Secure (HTTPS) and supports Libraries. Embodiments are not limited in this manner, and UI libraries may be supported. Embodiments also include utilizing a local Android SDK that can be implemented in an application on a device (e.g., a mobile device). The Android SDK can facilitate applications and / or websites via a web browser that wirelessly communicates with devices such as contactless cards. The Android SDK also enables applications or web browsers to communicate and utilize other basic Android services, such as an operating system and low-level services. Embodiments are not limited to these examples.

[0033] With general reference to the symbols and nomenclature used herein, one or more parts of the subsequent detailed description may be presented in terms of program processes executed on a computer or computer network. These procedural descriptions and representations are used by those skilled in the art to convey the essence of their work to other technicians in the field in the most effective way. The process is generally conceived here as a self-consistent series of operations that lead to the desired result. These operations are those that require physical manipulation of physical quantities. Usually, although not necessarily, these quantities take the form of electrical, magnetic or optical signals that can be stored, transmitted, combined, compared and otherwise manipulated. Mainly for idiomatic reasons, it is sometimes proven to be convenient to refer to these signals as bits, values, elements, symbols, characters, items, numbers, etc. However, it should be noted that all of these and similar terms are associated with appropriate physical quantities and are merely convenient labels applied to these quantities.

[0034] In addition, these operations are often referred to in terms such as adding or comparing, which are usually associated with mental operations performed by human operators. However, in any operation described herein that constitutes a part of one or more embodiments, such ability of a human operator is not necessary, or in most cases is not desirable. Instead, these operations are machine operations. Useful machines for performing the operations of various embodiments include digital computers selectively activated or configured by computer programs stored therein, which are written according to the teachings herein, and / or include devices or digital computers specially constructed for the desired purpose. Various embodiments also relate to devices or systems for performing these operations. These devices can be specially constructed for the desired purpose. The structures required for various these machines will be apparent from the description given.

[0035] Reference is now made to the accompanying drawings, in which the same reference numerals are used to refer to the same elements throughout. In the following description, for the purpose of explanation, many specific details are set forth in order to provide a thorough understanding thereof. However, it is apparent that novel embodiments may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate their description. It is intended to cover all modifications, equivalents, and substitutes within the scope of the claims.

[0036] Figure 1 An example of a multi-issuer system 100 configured to operate in accordance with the embodiments discussed herein is shown. The system 100 may include a computing system configured to be able to perform functions with a contactless card, such as the contactless card 102 and cryptographic techniques discussed herein. These functions may include performing transactions and other functions, such as authenticating a user and tapping functions. The tapping functions may include tapping to automatically fill in fields on a mobile device, tapping to launch an application on a mobile device, tapping to open a door, tapping to activate a card, tapping to generate and issue a virtual card number (VCN), and other tapping operations.

[0037] System 100 shows a high-level configuration that enables multiple users to use contactless cards issued by one or more card issuers to perform operations including transactions with merchant systems. In the illustrated example, system 100 includes multiple banking systems 106a, retail systems 106b, other financial systems 106c, and government systems 106d. These transaction systems can be configured to enable users to perform transactions to purchase goods and services using contactless cards. In addition, these systems can be configured to provide verification services to customers via their contactless cards. Embodiments are not limited in this manner.

[0038] System 100 may be configured to perform various operations for customers, issuing banks, merchants, etc. These operations may be initiated by a customer using contactless card 102, resulting in information exchange between contactless card 102 and other systems of system 100. Depending on the operation being performed, e.g., tap to launch an application, tap to autofill text, tap to authenticate, tap to perform a transaction, tap to provide (autofill) a VCN, etc., data may be routed and sent to various systems of system 100 to perform their respective operations.

[0039] For example, when tapped on another device (such as mobile device 104), contactless card 102 can initiate a transaction with one of the merchant systems, which can also be configured to communicate with one of the other systems (such as one or more escrow services). These services can include authentication services and business services. However, embodiments are not limited in this manner. Other services can be configured to perform operations so that the customer can perform any number of taps on functions.

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

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

[0042] For example, a customer may wish to perform a transaction for goods or services (retailer system 106b). A customer may initiate a transaction via their mobile device or interaction with a point of sale (POS) terminal. The device or terminal may send a message for the transaction to the switch system 108, which may determine how to further process the message and complete the transaction. The message may include an encrypted portion and an unencrypted portion. The encrypted portion may include sensitive data that may be used by the issuing bank system function to process the transaction, and the unencrypted portion may include data that may be used by the switch system 108 to route the message and data to the correct issuing bank system function via an application programming interface and services (such as business services). The switch system 108 may communicate with the mobile device 104 and then communicate with the merchant backend system (106) to first verify the contactless card and the user, establish a business session between the mobile device, the business service, and the merchant system, and perform the transaction in a secure manner.

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

[0044] Any number of banks or financial institutions can provide a variety of services 110 or functions that can be used by customers, merchants, and banks to provide services 110 including processing transactions and verifying customers and their contactless cards. These services can include verification services and business services. These services can be hosted on a central platform (such as a cloud-based system), and each bank can have its own set of services. In addition, each bank's services 110 can be hosted by the same central platform, and the switch system 108 can determine which bank's service to call via the API based on the information in the message.

[0045] In an embodiment, the system 100 may also perform engagement operations for participating merchants and merchant systems to operate with the switch system 108 environment. In an embodiment, participating merchants may include generating a unique identifier associated with the merchant and providing the unique identifier to the merchant, such as issuing a merchant certificate. The system 100 may also enable merchants and card issuers to exchange data (such as key pairs) to perform operations securely without revealing sensitive data to the switch system 108. The system 100 may also enable merchants to configure and set one or more configurations, such as configuration data fields to support merchant use cases.

[0046] The system 100 may also perform engagement operations for a card issuer. For example, the system 100 may enable a bank or card issuer to generate a unique identifier (e.g., an issuer ID) that may be used to uniquely identify the issuer when performing authentication and other functions. The system 100 may also enable a bank or card issuer to generate key pairs and / or distribute key pairs with merchants and other service providers. These and other details will be described in the following description.

[0047] Figure 2 An example of a system 200 according to embodiments discussed herein is shown. The system 200 includes additional devices and systems configured to enable a contactless card issuer to tap for card services. Specifically, the system 200 enables any number of card issuer systems to provide card services to their clients in a secure and reliable manner through a switching fabric (i.e., switch system 108).

[0048] In an embodiment, the switch system 108 includes one or more nodes 204 configured to perform routing operations. Each switch node 204 may include a session and random number generator 206, a message router 208, 210, an operational data store 212, and a metric store 214. In addition, each of the nodes may be configured to be identical and share a configuration, but each switch node 204 may independently process messages and requests and route them to appropriate systems, such as merchant systems and card issuer systems. For example, each of the nodes 204 is configured to act as a trust intermediary between a card issuer system, a merchant system 222, and / or a verification system 224. Each switch node 204 is configured to route each message to the correct card issuer system while maintaining data security. For example, a switch node 204 may route messages between a card issuer system and a merchant system without the node being able to access private data in the message.

[0049] The switch system 108 can be configured as a server system that includes a collection of hardware, software networking components that work together 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 run server applications, such as server applications executable on each of the nodes 204. In some cases, each of the server computers can be configured to operate one or more nodes in a virtual environment, for example. The storage devices are configured to store data accessed by the applications, and the network adapters are used to connect the server computers to the network.

[0050] Each of the server computers can be configured to execute software including an operating system, applications, and security software. The networking components of the server system include network switches, routers, and firewalls. Network switches are used to connect server computers to other devices on the network. Routers are used to route traffic between different networks. Firewalls are used to protect server systems from unauthorized access and attacks.

[0051] In some embodiments, the node 204 can operate in a cloud-based computing environment, for example, a collection of hardware, software, and networking components capable of delivering cloud computing services. The switch node 204 and computing services are delivered via the Internet, and they can be accessed from anywhere in the world via an Internet connection. In an embodiment, the client 236 can access the switch node 204 via a domain name system 202 or a domain name system (DNS). DNS202 is a hierarchical and distributed naming system for computers, services, and other resources connected to the Internet or other networks. It associates various information with domain names assigned to each registered participant. In one example, DNS202 can convert names known to software executed on the client 236 to route data to one or more switch nodes 204 of the switch system 108. In an embodiment, DNS202 can generate numbers, such as Internet Protocol (IP) addresses, address records (A-records), or another host name (C-name record). Figure 3 An example sequence 300 is shown for a client to identify and resolve an identifier of one of the nodes 204 of the switch system 108. At a high level, the domain name system 202 translates known domain names into numeric Internet Protocol (IP) addresses used to locate and identify computer services and devices with underlying network protocols. The client uses the global DNS system to select the best node to use, as described in sequence 300.

[0052] In an embodiment, the client sdk 236 communicates with the switch system 108 to perform one or more partner services 232, such as conducting transactions with merchants, verifying customers, or other tap functions. Once the client sdk 236 identifies the switch node 204 and resolves the address to communicate with the switch node 204, the client sdk 236 can send one or more messages to the switch node 204 to authenticate and perform operations. The switch 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 switch node 204:

[0053] X-Sb-Api-Key:<CLIENT API KEY>

[0054] X-Sb-Dvc-Fngrprnt: Device-specific device fingerprint

[0055] A client API key can have the following example structure: 65535-GReyx5BuEAaE72bWbFZJfHRL8Dbt1Uum, where Table 1 describes the values, names, and meanings:

[0056]

[0057] Table 1

[0058] The switch node 204 can authorize or authenticate the client sdk 236 or user, and the switch node 204 can utilize additional components (such as the session and random number generator 206 and the message router 208) to perform this operation, such as Figure 4A-4C Note that the validator verification system 224 never interacts with the merchant system 222 and vice versa. The node 204 proxies all communications.

[0059] In an embodiment, the switch system 108 can manage the synchronization of shared operational data 212 and member management across the network using the Hyperledger Fabric 220. The Hyperledger Fabric 220 is a distributed ledger framework with a permissioned network model where only authorized participants can join the network and access data stored on the ledger.

[0060] In an embodiment, the hyperledger fabric 220 can be generated by creating one or more groups of peers, ordering services, and channels. Once the network is created, the system 200 deploys the chain code to the network or nodes 204 that are allowed to access the fabric. Chain code is code that runs on the blockchain and executes the network control 226 and operational data 212 logic code. Once the chain code is deployed, each of the switch nodes 204 is configured to call transactions on the blockchain to add data, such as operational data, to the blockchain. The switch node 204 or another device can query the ledger to retrieve data. The ledger is a distributed database that stores all data that has been added to the blockchain.

[0061] All nodes 204 keep independently verifiable logs of their actions that can be sent to a centralized aggregator to build a picture of overall network usage. At a central level, the system 200 can manage network operational data and management and have a centralized view of network usage, aggregated and abstracted to the appropriate level.

[0062] Figure 3 An example sequence 300 is shown for a client to utilize DNS to resolve and communicate with one or more nodes in a switch system. The sequence 300 shown includes a client 236, a DNS 202, and a switch node 204. At 302, the sequence 302 includes the client 236 sending a request for a text record switchboard.{domain}.{tld} to a default DNS server. The text record may be pre-configured in the client application and / or the client sdk. At 304, the DNS 202 returns one or more records. The DNS record structure may include the following:

[0063] ●Root Record:

[0064] ○ Name: switchboard.{domain}.{tld}

[0065] ○Type: TXT

[0066] ○ Resolution:

[0067] ■{nodename_1}.{operator_a}.{region_i}.switchboard.{domain}.{tld},

[0068] ■{nodename_2}.{operator_a}.{region_i}.switchboard.{domain}.{tld},

[0069] ■{nodename_1}.{operator_b}.{region_ii}.switchboard.{domain}.{tld},

[0070] ■{nodename_2}.{operator_b}.{region_ii}.switchboard.{domain}.{tld},

[0071] ■*etc.

[0072] ○Used to determine the location of the active node

[0073] ●Node record:

[0074] ○Name: {nodename}.{operator}.{region}.switchboard.{domain}.{tld}

[0075] ○ Type: A / AAAA or CNAME

[0076] ○ Resolution: Actual node hostname or IP

[0077] ○Used for: communicating with nodes

[0078] In an embodiment, at 306, the client 236 may determine the current time zone. For example, the client application or SDK may use a function to obtain the current time zone, such as in JavaScript: Intl.DateTimeFormat().resolvedOptions().timeZone). The embodiment is not limited in this manner, and the application or SDK may determine the time zone via another / different function call. At 308, the client 236 is configured to map the time zone to a region or a short version identifier of the region. An example includes America / New York->na-e. For example, the region may be based on a DNS name. Table 2 shows several examples of time zones mapped to regions:

[0079]

[0080] Table 2

[0081] Embodiments are not limited to these examples, and other time zone to region mappings may be utilized. Additionally, in embodiments, regions may also be represented as a bidirectional graph structure, where edges represent geographic neighbors. For example, na-e <-> na-w and sa <-> na-w and sa <-> na-e. This representation is useful for node selection.

[0082] At 310, the client may identify or select a DNS record option returned at 304 that is located in the zone. If there are multiple matches, the client may select one at random. If there is no available node in the zone, then at 312 the client may determine and use a data graph of neighboring zones to select a node in the nearest zone where a node is available. For example, sa has no node but is connected to na-e where a node exists, so na-e is selected. In some embodiments,

[0083] 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 can return the result. At 318, the client 236 can communicate with the switch node 204 and begin the process of interacting with the switch.

[0084] Figure 4A-4C An example sequence 400 of operations performed between a contactless card and services provided by a card issuer and / or a merchant is shown. The illustrated sequence 400 includes actions and communications performed by the contactless card 102, the client sdk 236 including a client application and a client sdk, the domain name system 202, the switch system 108, the partner services 232 including merchants and / or validators, and the control service 234 including a client server or system.

[0085] In an embodiment, at 402, the client sdk 236 including the client application can send a request and establish a session with the client server 484 so that the results can be associated with the correct client device or user. The request establishes a relationship between the client device and the client server, which can be a card 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 can be user session identification information of a specific implementation of the client.

[0086] At 408, the client sdk 236 may initiate a contactless card authentication process with the client sdk 235. For example, the client sdk 236 may call a function and / or pass information to the client sdk 236 to initiate authentication via a contactless card. At 410-414, the client may utilize DNS to identify a node and establish communication with the node. Specifically, at 410, the client sdk 236 may send a request for a switch host name, and at 412, the DNS 486 may return information including one or more host names. At 414, the client sdk 236 may determine the switch node to communicate with. Figure 3An example of a more detailed sequence of the process of establishing communications with a switch node is shown.

[0087] At 416, the client sdk 236 may send a session request to the switch system 108. In an embodiment, the session request may be<FUNCTION REQUEST> In an embodiment, the function request may be the data / function that the client wants to request once the contactless card has been verified. The function may be used for any of the services discussed herein, e.g., authenticating a user, performing a transaction, requesting autofill data, etc. At 418, the switch system 108 may generate a random number and a signed session token. The signed session token may be a JSON Web Token (JWT). When generating the JWT, the following elements should be set:

[0088] ●iss: the unique ID of the current node,

[0089] ●nonce: an octal character, a randomly generated number,

[0090] ●exp: expiration timestamp (+5 minutes),

[0091] ●client_id: the client ID of the requesting client,

[0092] ●sub: request the client's device fingerprint,

[0093] ●sid: arbitrary session information sent from the client,

[0094] ●scope: The function requested to be executed.

[0095] A nonce can be a unique, randomly generated byte that ensures that contactless card messages are not repeatable. Nonce numbers are critical to the security and operation of the switch system. Nonce validity is tracked by binding it to a session that can be verified by any member of the platform. As mentioned above, a session is a signed JSON network token issued by the network using the private key of a specific node. These JWTs can be verified by systems with the corresponding public key, and they can also be verified by confirming that it was issued by us or an approved representative. A signed session token is a token generated by a JWT that establishes the validity and expiration of the nonce and associates the contactless card tap with the current client session. For example, a signed session token includes the following:<NODE PRIVATE KEY> Signed <nonce>,<CLIENT SESSION INFO> and <functionrequest>, where the node private key is the switch system 108 private key. The switch system 108 can include a node public / private key, which is a key pair used to sign and verify the JWT.

[0096] At 420, the switch system 108 may return session information to the client sdk 236. The session information may include a signed session token (<SIGNED SESSION TOKEN> ), random number <nonce>, Functional Service Terms <functiontos>and Terms of Service Version<TOS VERSION> The function TOS may be a term of service that the user must agree to in order to allow the client to perform the requested function, and the TOS version may be a version of the terms of service. At 422, the client SDK 236 may determine and / or receive the user's agreement to the terms of service. In one example, the client SDK 236 captures and records the user's agreement to the terms of service.<CONSENT DATE> and<TOS VERSION> Top pair<FUNCTION TOS> The consent date can be the timestamp of when the user agreed to the TOS.

[0097] At 424, the client SDK 236 exchanges one or more messages with the contactless card. In one example, the exchange can be based on the contactless card being tapped to the client device. In an embodiment, the client SDK 236 can provide data to the contactless card 102 to use during the session to perform the function. The data can be provided to the contactless card 102 in an NDEF message. In one example, the data is written to the card in NDEF format using a binary update command. The data may include a random number to provide a security level that the message received from the card is part of the same session. In addition, the data may 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 NDEF message format.

[0098]

[0099]

[0100] In an embodiment, an updated MAC may be calculated to protect the control indicator. Specifically, MAC M is determined by calculating a MAC on 10 bytes of the update data U using an updated MAC card key (MCK), as shown below:

[0101] U=[Control Indicators(2bytes)||Update Date Time(8bytes)||'80'||'000000 00 00']

[0102] Treat U as two 8-byte data blocks: U = U1||U2

[0103] ●Calculate B = DES (MCKL) [U1]

[0104] ●Calculate B = [B XOR U2]

[0105] ●Calculate B = DES(MCKL)[B]

[0106] ●Calculate B = DES -1 (MCKR)[B]

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

[0108] At 424, the contactless card may generate and provide a message to a client device including the client sdk 236. The systems discussed herein may utilize the data in the message to perform the requested function. Figure 5 One example of a message, message 500, is shown and discussed in FIG.

[0109] At 426, the client including the client sdk 236 can send a message and information to the switch system 108. The message can be a message received from the contactless card 102, such as message 500. In addition, the client sdk 236 can send the consent date, TOS version, and signed session token to the switch system 108. The switch system 108 can use this information to ensure that the session is valid. At 428, the switch system 108 verifies whether the signed session token is valid, for example, whether it is a previously provided signed session token, whether it includes a previously generated random number, and whether it is in the message.

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

[0111] In an embodiment, the switch system 108 is configured to generate secure communications and communicate with the card issuer system (e.g., client server 484 and authenticator 488). At 432, the switch system 108 sends a key request to the client server 484. The key can be used to perform secure communications. In one example, the key request can be an elliptic curve Diffie-Hellman (ECDH) key request. The embodiment is not limited in this manner, and alternative key protocols can be used, such as super singular isotope Diffie-Hellman key exchange (SIDH or SIKE), private key / public key pairing (RSA), etc.

[0112] At 434, client server 484 generates a portion of a key. In some cases, client server 484 may generate half of an ECDH key for encryption / decryption of PII. Specifically, client server 484 may generate <CLIENT EC PUBLIC KEY> and <CLIENT EC PRIVATE KEY> using elliptic curve P256. The client EC public key and the client EC private key are the first half of the ECDH key agreement.

[0113] At 436, the client server 484 stores the generated portion of the key in memory. Specifically, the client server 484 may store a portion of the key having<KEY ID> of<CLIENT EC PUBLIC KEY> and<CLIENT EC PRIVATE KEY> , where the key ID is used by the client server to cache its short-lived EC public / private key to later complete the ECDH key, e.g., identify the ECDH key part to generate the entire ECDH key. In one example, the key can be stored in a secure storage location and can be used when receiving PII for the session.

[0114] In an embodiment, at 438, the client server 484 may return the public key portion along with the key ID to the switch system 108. The switch system 108 may store the public key portion along with the key ID for later use, such as generating an ECDH key. At 440, the switch system 108 may request verification to be performed by the verifier 488. In one example, the switch system 108 may send a request verification as a request verification <MESSAGE>, <SIGNED SESSION TOKEN>, <CLIENT EC PUBLIC KEY>, <CONSENT DATE>, and <TOS VERSION>. At 442, the verifier 488 may issue an out-of-band request to the switch system 108 to obtain a public key to verify the session. At 444, the switch system 108 may provide the node's public key, i.e., <NODE PUBLIC KEY>. In addition, at 446, 488 may utilize the node's public key to verify the secure session token.

[0115] In an embodiment, at 448, the verifier 488 may verify the message. In an embodiment, the verifier 488 may perform a number of verifications, including ensuring that the random number and additional information in the message, such as the card's unique identifier (pUID) and counter value (pATC), are correct. Fig. 12A and Fig. 12B Additional details of the verification process that can be performed are discussed.

[0116] At 450, the authenticator 488 can store information associated with the session. For example, the authenticator 488 can store<CONSENT DATE> and<TOS VERSION> and <puid>The Teh validator 488 can also generate another part of the key, such as an ECDH key. For example, 488 can use the elliptic curve P256 to generate<ISSUER EC PUBLIC KEY> and<ISSUER EC PRIVATE KEY> The card issuer EC public key and the card issuer EC private key can be the second half of the ECDH key negotiation.

[0117] At 454, the validator 488 may generate a complete ECDH key. For example, the validator 488 generates a complete ECDH key from<ISSUER ECPRIVATE KEY> and<CLIENT EC PUBLIC KEY> generate<ECDH KEY> The ECDH key is the final key generated using ECDH key negotiation.

[0118] The validator 488 may utilize the ECDH key to encrypt the data of the function. For example, in some cases, if the validator 488 validates the message, then at 456 the validator 488 may execute the function request to create a function result and encrypt the result with the ECDH key. For example, the validator 488 may execute <FUNCTION REQUEST> to create <FUNCTIONRESULT> and encrypt it with <ECDH KEY>. The function result may be any result based on the requested function, such as verification of a card.

[0119] At 458, the validator 488 may return the function result to the switch system 108. In some cases, the function result is returned encrypted. For example, the validator 488 may return<ENCRYPTED FUNCTION RESULT> and<ISSUER ECPUBLIC KEY> .

[0120] In an embodiment, the switch system 108 sends the function result to the client server 484 to process the result. In one example, the switch system 108 may send<ENCRYPTED FUNCTION RESULT> ,<KEY ID> ,<ISSUER EC PUBLIC KEY> and<SIGNED SESSION TOKEN> At 462 and 464, the client server 484 may request a public key from the switch system 108 and receive the public key from the switch system 108. In some cases, the exchange may be performed via an out-of-band communication channel. The public key of the node may be<NODE PUBLIC KEY> The public key can be used to verify the sender of the function result, etc. At 466, 484 can use the public key of the node<NODE PUBLIC KEY> To verify the signed session key to verify the sender of the information. At 468, the client server 484 can extract the client information from the signed session token. For example, the client server 484 can extract the client information from the signed session token.<SIGNED SESSION TOKEN> Extract<CLIENT SESSION INFO> , that is, extracting the user session identification information of the client-specific implementation.

[0121] Additionally, at 470, client server 484 may retrieve the client private key using the key ID. Specifically, client server 486 may use the <KEY ID> to obtain and delete the <CLIENT PRIVATE KEY> from the cache. At 472, client server 484 may generate or calculate an ECDH key. For example, client server 484 may use<CLIENTPRIVATE KEY> +<ISSUER EC PUBLIC KEY> To calculate<ECDH KEY> At 474, the client server 484 may decrypt the function result using the calculated key. Specifically, the client server 484 may use<ECDH KEY> right<ENCRYPTED FUNCTION RESULT> Decrypt to determine<FUNCTION RESULT> At 476, the client server 484 associates the function result with the session.

[0122] In an embodiment, at 478, the switch system 108 may return to the client sdk 492 whether the function result was completed successfully. In addition, at 480, the client sdk 492 may notify the client application 490 of the result. At 482, the client application 490 may utilize the function. For example, 482 may communicate with the client server 484 to obtain the edited <FUNCTION RESULT> using <CLIENT SESSION INFO> to continue the function.

[0123] Figure 5 An example of a message 500 that may be communicated by the contactless card 102 to perform the functions described herein is shown. One or more fields in the message 500 may also be used to route the message 500 through a switch system and perform authentication / verification techniques.

[0124] In an embodiment, message 500 includes applet version 502 field, issuer autonomous indicator 504 field, issuer identifier 506 field, pKey ID 508 field, pUID 510 field, pATC 512 field, random number 514 field, and encrypted password 516 .

[0125] In an embodiment, the fields may be plain text or encrypted. For example, the applet version 502 field may include the applet version in plain text. The applet version is used to indicate which applet version is installed on the contactless card 102 and may be used by other systems to determine how to process the message 500 when communicating. For example, different applet versions may require different verification logic, e.g., older messages may be routed through the card issuer system to perform various verification operations, while newer messages may be routed through the switch system to perform various operations including verification.

[0126] In an embodiment, the message 500 includes an issuer autonomous indicator 504 field that may include issuer data and is set at the time of personalization. In addition, the message 500 includes an issuer identifier 506 field that may include a unique ID assigned to an issuing entity (e.g., an issuer). For example, during a participating operation of the joining system, each issuer may be assigned a unique identifier. The issuer ID may be used by the switch system 108 to route the message and its contents to the appropriate service associated with the specific issuer.

[0127] In an embodiment, the message 500 includes a pKey ID 508 field. In some cases, the pKey ID 508 field may include data identifying a set of master keys for the card issuer. The card issuer's set of master keys may use a set of derived master keys or unique derived keys (UDKs) for each card. In addition, during the personalization process of the card, each card's own set of master keys (UDKs) may be generated. The card's UDK may be used to generate a session key for generating an application password. The session key generated by the card may be regenerated by a system (e.g., an authenticator system) using the pKeyID to identify the card issuer's master key and regenerate the session key by the system to perform authentication.

[0128] In an embodiment, each contactless card 102 is assigned a unique 16-digit decimal digital identification (pUID) when personalized. The derivation of the unique key for the card applet using the pUID is performed off-card. The generated application key is injected during the personalization process 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:

[0129] 1. Create multiple issuer master key sets and assign a unique three-byte pKey ID (6 hexadecimal digits) to each key set.

[0130] 2. For each card application:

[0131] 1. Associate one of the issuer's pKey IDs with the card's pUID.

[0132] 2. Use pKey ID to identify the card issuer master key for application key generation (UDK) and subsequent cryptographic calculations and data encryption.

[0133] 3. For each of the application keys (UDK), create the diversified data as follows:

[0134] 1. Create a 16-digit quantity X from the 16-digit pUID

[0135] 2. Each application key (UDK) is formed by the following steps:

[0136] 1. Compute ZL by encrypting X using the appropriate card issuer master key identifier (pKey-ID);

[0137] 2. Calculate ZR by XORing X with FFFFFFFFFFFFFFFF, and then encrypt the result using the card issuer master key;

[0138] 3. Connect ZL and ZR to form the application key (UDK key).

[0139] Message 500 may include a pUID 510 field containing a card unique identifier assigned to the contactless card at personalization time. The pUID 510 field data may be a combination of alphanumeric characters used to uniquely identify each card and associate it with a user.

[0140] In an embodiment, the message 500 includes a pATC 512 field configured to store a counter value. In one example, the counter value stores the read (tap) count on the contactless card in hexadecimal format. In addition, the counter value can be used to generate a session key to encrypt at least a portion of the message.

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

[0142] According to EMV 4.3 Book 2 Annex A1.3.1, the card's applet supports an improved variant of the session key derivation option to generate a unique cryptographic session key ASK as follows:

[0143] ● Calculate SKL by encrypting [ATC[2]||ATC[3]||'F0'||'00'||[ATC[0]||[ATC[1]||[ATC[2]||[ATC[3]] with the application key

[0144] ● Calculate SKR by encrypting [ATC[2]||ATC[3]||'0F'||'00'||[ATC[0]||[ATC[1]||[ATC[2]||[ATC[3]] with the application key

[0145] ●Concatenate SKL with SKR to form an authentication session key.

[0146] The authentication session key is used to encrypt the password MAC.

[0147] According to EMV 4.3 Book 2 Annex A1.3.1, the card applet also supports an improved variant of the session key derivation option to generate a unique encrypted session key DESK as follows:

[0148] ● Calculate SKL by encrypting [ATC[2]||ATC[3]||'F0'||'00'||'00'||'00'||'00'||'00'] with the data encryption key

[0149] ●Calculate SKR by encrypting [ATC[2]||ATC[3]||'0F'||'00'||'00'||'00'||'00'||'00'] with the data encryption key

[0150] ●Concatenate SKL with SKR to form a data encryption session key.

[0151] The cryptogram C is determined by computing a MAC over the 32-byte transaction data T using the authentication session key (ASK) as follows:

[0152] 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']

[0153] Treat T as four 8-byte data blocks: T = T1||T2|T3||T4

[0154] ●Calculate B = DES (ASKL) [T1]

[0155] ●Calculate B = [B XOR T2]

[0156] ●Calculate B = DES(ASKL)[B]

[0157] ●Calculate B = [B XOR T3]

[0158] ●Calculate B = DES(ASKL)[B]

[0159] ●Calculate B = [B XOR T4]

[0160] ●Calculate DES(ASKL)[B]

[0161] ●Calculate B = DES -1 (ASKR)[B]

[0162] Finally, the cipher C = DES(ASKL)[B]

[0163] The password is encrypted using the data encryption session key (DESK) in cipher block chaining mode (CBC) as follows:

[0164] ●Generate 8-byte random number [RND]

[0165] ●Calculate E1=DES3(DESK)[RND]

[0166] ●Calculate B = [E1] XOR [C]

[0167] ●Calculate E2 = DES3 (DESK) [B]

[0168] ●Finally, the 16-byte encrypted payload E = [E1] || [E2]

[0169] To recover using decryption mode:

[0170] RND=DES3 -1 (DESK)[E1]

[0171] B = DES3 -1 (DESK)[E2]

[0172] ●C=[E1]XOR[B]

[0173] In an embodiment, a portion of the data provided in message 500 is static and is set on the card during personalization of the card, while other data is dynamic and may be generated by the card during operation (e.g., when performing a read operation). Note that in some cases, static information may be updateable, but may require the customer and card to go through a secure update process, which may be controlled by the card issuer.

[0174] In an embodiment, contactless card 102 can communicate messages between devices (such as mobile devices) during a read operation. For example, in response to contactless card 102 being tapped onto a surface of a device, such as being brought into wireless communication range, a read operation can be performed on contactless card 102, and contactless card 102 can generate and provide a message to the device. For example, once in range, contactless card 102 and the device can perform one or more exchanges so that contactless card 102 sends a message to the device. Figure 4A Step 424 shows an example of an exchange.

[0175] The wireless communication may be according to a wireless protocol, such as near field communication (NFC), Bluetooth, WiFi, etc. In some cases, messages may be communicated between the contactless card 102 and the device via wired means (eg, via contact pad 804) and according to the EMV protocol.

[0176] Figure 6 An example of a routine 600 according to an embodiment discussed herein is shown. In block 602, the routine 600 includes receiving, by a node in a system, from a client device, a request to establish a session to perform a function, wherein the function is at least partially performed using a contactless card. In some cases, the node may be one of a plurality of nodes of a switch system. The node may be pre-selected by a sending device via a DNS operation performed.

[0177] In block 604, the routine 600 includes generating, by the node, session information corresponding to the session to perform the function, wherein the session information includes a random number and a signed session token. The random number and / or the signed session token can be 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 keeping track of the session for the function.

[0178] In block 606, routine 600 sends session information by the node to the client device. The client device may communicate with the contactless card to receive data from the card to authenticate and perform functions. In some cases, the client device may send a random number from the node to the contactless card. The contactless card may utilize the random number when generating a message to communicate to the client device, and the node may incorporate it into an encrypted portion of the message (see Figure 5 ).

[0179] In block 608, the routine 600 receives a message from the contactless card via the client device by the node. The message may be generated by the contactless card. Figure 5 An example of message 500 is shown.

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

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

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

[0183] Figure 7 An example of a system 700 configured in accordance with the embodiments discussed herein is shown. In some cases, the system 700 may be a more detailed view of the system 100 and its components. The illustrated system 700 includes one or more systems to support processing transactions, performing authentication functions, and other functions involving contactless cards issued in multiple issuer environments. In an embodiment, the system 700 includes one or more issuer systems 202, a personalization system 704, one or more merchant systems 706, and a switch system 730. The switch system 730 may include additional systems to provide functionality to multiple issuer systems, which may include switch nodes configured to route messages and communicate with other systems.

[0184] These systems can be configured with hardware and software components to perform the functions discussed herein. For example, each system can be configured with one or more servers, processors, memory, storage, network hardware, input / output devices, etc. to process instructions according to the embodiments. In addition, each of the systems can support and implement multiple application programming interfaces (APIs) configured to achieve interoperability between each of the systems while maintaining high security.

[0185] In an embodiment, system 700 includes at least one card issuer system 702. Card issuer system 702 may have multiple components and provide functionality to issue contactless cards to customers, authenticate customers, perform transactions, and enable other contactless card tapping operations. In one example, card issuer system 702 includes card issuance functionality including processing network contactless card requests, maintaining a system of record (SoR), and providing configuration services.

[0186] In one example, to issue a card, the issuer system 702 may generate card unique identifiers (pUIDs), each of which may be associated with a cardholder and a contactless card at the time of issuance. For example, the pUIDs may be used as part of a verification process, and the issuer system 702 may store the pUIDs in a database associated with the cardholder. The pUIDs may be written to the SoR and provided to the personalization system 704 to physically generate and issue the contactless card. In some cases, the pUIDs may be communicated to the personalization system 704 in the form of a batch or batch file. For example, the issuer system 702 may include a process for generating a batch of pUIDs, and functionality for communicating the batch (e.g., an embossing file batch) to the personalization system 704. The personalization system 704 may configure and physically generate and issue the contactless cards, as will be discussed in more detail below.

[0187] In some embodiments, the issuer system 702 may provide additional functionality. In some cases, once a contactless card has been issued, the issuer system 702 may maintain at least a portion of the functionality to perform verification operations on a customer. For example, the issuer system 702 may include functionality and APIs that a device (such as a mobile device executing the issuer mobile application 710) may use to verify information initially received from a contactless card. The device may communicate data from the contactless card to the issuer system 702 via one or more APIs (such as an API provided by the MFA service 714), and the issuer system 702 may verify the information based on information stored in a database. The issuer system 702 may return a result to the device.

[0188] In some cases, the issuer network 702 includes one or more business APIs that are configured to provide business services, such as providing PII during transactions, providing PII to automatically populate forms, providing VCNs to perform transactions or automatically populate forms, etc. In some cases, these business APIs may be hosted outside of the issuer network 702 by a provided third-party service (such as under service 734).

[0189] In other cases, the issuer system 702 can offload the verification operation to the service 734. In these cases, the issuer system 702 can still receive data from the contactless card via a device (e.g., a mobile device) and through an API. The issuer system 702 can then be configured to send the data to the service 734, and the service 734 can perform the verification operation. In either case, the issuer system 702 can return the verification result to the device. The device (such as a mobile device) can use the result as part of a verification request, for example, to access a mobile application as part of a multi-factor authentication operation, or to enable the performance of another function.

[0190] In an embodiment, the system 700 includes a personalization system 704 for performing operations on the contactless card to issue it to a customer. For example, the personalization system 704 can obtain and / or generate data that can be copied to each contactless card of each customer. The data can be unique to each customer and include information such as an account number, customer name, expiration date, card verification value (CVV). In an embodiment, the personalization system 704 can store the data in a secure memory, such as a hardware security module (HSM) of the contactless card. The data can also be provided to the issuer system 702 and / or service 734 so that they can perform contactless card operations such as verification, authentication, tapping, etc.

[0191] The personalization system 704 may also generate a unique key for each of the contactless cards. Each of the contactless cards may have a unique key pair that may also be used to generate a derived key that is used to perform cryptographic operations for the card to communicate data in a secure manner. Each unique key for the card may be based on and / or associated with an issuer bank. Additionally, the issuer system 702 and / or the switch system 730 may have a unique set of keys for each card that may be used to perform authentication operations by being able to generate the same derived key to decrypt data received from the contactless card during the authentication or transaction process.

[0192] The personalization system 704 may also install one or more applet programs on the card. The applet program may be used to perform various functions including performing cryptographic operations and generating messages and passwords, which include data for performing card verification and transactions. In some cases, the personalization system 704 may install applet programs to perform functions and include applet program version numbers. System versions may be required so that other systems may operate accordingly. The system version specifies the applet program version to be embedded in the card by the personalization system 704 and the verification logic. For example, a first-party system may operate under version 0100, while the use of a central system may operate under a different version (e.g., version 0200) to simplify implementation and enable authentication networks. JavaCard and MultOS implementations of applet programs may share the same version number.

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

[0194] The system 700 also includes a switch system 730 and a service system 734 to enable multiple banks or card issuers to provide contactless card tapping execution functions, such as authentication, transactions, etc., while maintaining a high level of data security and separation between each card issuer's data. For example, the switch system 730 and the service system 734 provide a set of functions and APIs that are configured to provide services to multiple card issuers to perform authentication, transactions, and other contactless card operations. In some cases, the switch system 730 can be maintained and provided by a central system that is owned and operated by an entity separate from any card issuer.

[0195] In an embodiment, the switch system 730 may include multiple components and systems including routing services, workflow services, management services, authentication services, usage services, analytics services, and administration services 718 .

[0196] In an embodiment, the switch system 730 and the service are configured to enable multiple card issuers to operate together. For example, the switch system 730 is configured to route messages and data from devices and contactless cards to corresponding services of the card issuers, such as service 734. For example, bank A can issue contactless cards and provide service A, and the switch system 730 is configured to process messages and data from the contactless cards issued by bank A to service A. In an embodiment, the switch system 730 can use information in the messages and data to determine where to send them.

[0197] The switch system 730 and services also enable the merchant system 706 to process transactions for multiple different card issuers. For example, the switch system 730 may include an API that can be used by a merchant backend to obtain PII associated with a cardholder to perform a transaction. The switch system 730 may also include an API that is configured to initiate a session (e.g., a transaction session) and provide a verification token to a merchant application on a mobile device based on a contactless card executed on the mobile device.

[0198] The switch system 730 also includes a verification function and a verification API (e.g., verification service 720) to perform verification operations. The switch system 730 can also be coupled with a message verification service 724, which is configured to communicate with the verification function / API to provide a cryptographic verification service 726. The cryptographic verification service 726 includes a development algorithm and is coupled with a verification HSM 728 to perform verification operations. The following description will discuss the API in more detail.

[0199] In an embodiment, the system 700 includes multiple systems that provide functions and services using a contactless card. At least a portion of these services can be performed with a contactless card and another device (such as a mobile device). As will be discussed in more detail, the mobile device can execute one or more applications that can be configured to operate with the functions and APIs provided by the system 700. In one example, a software development kit including instructions and functions that operate with the functions and APIs can be used to develop one or more applications. The mobile application can include a card issuer mobile application 710 (such as a banking application) and a merchant mobile application 712. However, the embodiment is not limited to this approach, and other applications such as a web browser, a mini or micro application (e.g., an application clip), an operating system, etc. can be configured to operate and utilize the functions provided by the system 700.

[0200] Figure 8 An example configuration of a contactless card 102 according to an embodiment discussed herein is shown. The contactless card 102 may include a contactless card, a payment card (such as a credit card, debit card, or gift card) issued by a service provider or a card issuer, as shown by a service provider mark 802 on the front or back of the contactless card 102. In some examples, the contactless card 102 is not related to a payment card and may include, but is not limited to, an identification card, a membership card, a hotel key card, etc. In some examples, a transaction card may include a dual-interface contactless payment card, a reward card, etc. The contactless card 102 may include a substrate 808 that may include a single layer or one or more laminated layers composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 102 may have physical characteristics that conform to the ID-1 format of the ISO / IEC 7816 standard, and the transaction card may otherwise conform to the ISO / IEC 14443 standard. However, it should be understood that a contactless card 102 according to the present disclosure may have different characteristics and the present disclosure does not require implementation of a transaction card in a payment card.

[0201] The contactless card 102 may also include identification information 806 displayed on the front and / or back of the card and a contact pad 804. The contact pad 804 may include one or more pads and is configured to establish communication with another client device (such as an ATM, user device, smartphone, laptop, desktop, mobile device, or tablet) via a transaction card. The contact pad may be designed according to one or more standards (such as the ISO / IEC 7816 standard) and may be capable of communicating according to the EMV protocol. The contactless card 102 may also include processing circuitry, an antenna, and other components, as will be described in detail in the accompanying drawings. Fig. 9 These components may be located behind the contact pads 804 or elsewhere on the substrate 808, such as within a different layer of the substrate 808, and may be electrically and physically coupled to the contact pads 804. The contactless card 102 may also include a magnetic stripe or tape, which may be located on the back of the card ( Figure 8 ). The contactless card 102 may also include a near field communication (NFC) device coupled to an antenna capable of communicating via the NFC protocol. The embodiments are not limited in this manner.

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

[0203] The memory 904 may be a read-only memory, a write-once read-many memory, or a read / write memory, such as a RAM, a ROM, and an EEPROM, and the contactless card 102 may include one or more of these memories. The read-only memory may be a factory-programmable read-only memory or a one-time programmable memory. One-time programmability provides an opportunity to write once and then read multiple times. The write-once / read-many memory may be programmed at a certain point in time after the memory chip leaves the factory, such as the personalization system 704. Once the memory is programmed, it can be rewritten, but it can be read multiple times. The read / write memory may be programmed and reprogrammed multiple times after leaving the factory. The read / write memory may also be read multiple times after leaving the factory. In some cases, the memory 904 may be an encrypted memory that encrypts encrypted data using an encryption algorithm executed by the processor 902. In some embodiments, at least a portion of the memory may be implemented as part of an HSM to store secret data, such as a master key for a card.

[0204] The memory 904 may be configured to store one or more applets 908, one or more counters 910, a customer identifier 914, and one or more account numbers 912, which may be virtual account numbers. In some cases, the customer identifier 914 may be a unique identifier for a card, such as a pUID. The memory 904 may be configured to store additional information, such as a version identifier for identifying an applet version, an issuer identifier for identifying an issuer or bank, one or more key identifiers, and the like.

[0205] The one or more applets 908 may include one or more software applications configured to execute on one or more contactless cards, such as Card applet. However, it should be understood that applet 908 is not limited to Java Card applet, but can be any software application operable on a contactless card or other device with limited memory. One or more counters 910 may include a digital counter sufficient to store an integer. Customer identifier 914 may include a unique alphanumeric identifier assigned to a user of contactless card 102, and the identifier may distinguish the user of the contactless card from other contactless card users and / or the contactless card from another contactless card. In some examples, customer identifier 914 may identify a customer and an account assigned to the customer, and may also identify the contactless card 102 associated with the customer's account.

[0206] As depicted, the one or more account numbers 912 may include thousands of one-time use virtual account numbers associated with the contactless card 102. The one or more applets 908 of the contactless card 102 may be configured to manage the one or more account numbers 912 (e.g., select the one or more account numbers 912, mark the selected one or more account numbers 912 as used, and send the one or more account numbers 912 to a mobile device for autofill via an autofill service).

[0207] The processor 902 and memory elements of the above exemplary embodiments are described with reference to the contact pad 804, but the present disclosure is not limited thereto. It should be understood that these elements may be implemented outside the contact pad 804, may be completely separated from the contact pad, or may be implemented as other elements other than the processor 902 and memory 904 elements located in the contact pad 804.

[0208] In some examples, the contactless card 102 may include one or more antennas 918. The one or more antennas 918 may be placed within the contactless card 102 and around the processing circuit 916 of the contact pad 804. For example, the one or more antennas 918 may be integrated with the processing circuit 916, and the one or more antennas 918 may be used with an external booster coil. As another example, the one or more antennas 918 may be external to the contact pad 804 and the processing circuit 916.

[0209] In an embodiment, the coil of the contactless card 102 can act as the secondary 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 use the gap in the power connection of the contactless card to infer the data sent from the terminal, which can be functionally maintained by one or more capacitors. The contactless card 102 can communicate by switching the load or load modulation on the coil of the contactless card. Load modulation can be detected in the terminal coil by interference. More generally, using one or more antennas 918, processors 902 and / or memory 904, the contactless card 101 provides a communication interface to communicate via NFC, Bluetooth and / or Wi-Fi communications.

[0210] As described above, the contactless card 102 can be built on a software platform operable on a smart card or other device with limited memory (such as JavaCard), and one or more applications or applets can be securely executed. One or more applets 908 can be added to the contactless card to provide a one-time password (OTP) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet 908 can be configured to respond to one or more requests (such as near field data exchange requests) from a reader (such as a mobile NFC reader (e.g., a mobile device or a point-of-sale terminal)) and generate an NDEF message including a cryptographically secure OTP encoded as an NDEF text tag. Figure 5 Examples of messages that may be generated and communicated by contactless card 102 to perform authentication and transaction operations are shown.

[0211] One example of an NDEF OTP is an NDEF short record layout (SR=1). In such an example, one or more applets 908 may be configured to encode the OTP as an NDEF Type 4 well-known type text tag. In some examples, an NDEF message may include one or more records. One or more applets 908 may be configured to add one or more static tag records in addition to the OTP record.

[0212] In some examples, one or more applet applications 908 can be configured to simulate an RFID tag. The RFID tag can include one or more polymorphic tags. In some examples, each time the tag is read, different cryptographic data that can indicate the authenticity of the contactless card is presented. Based on one or more applet applications 908, the NFC reading of the tag can be processed, the data can be sent to a server (such as a server of a banking system), and the data can be verified on the server.

[0213] In some examples, the contactless card 102 and the card issuer system 702 and / or the switch system 730 may include certain data so that the card can be correctly identified. The contactless card 102 may include one or more unique identifiers (not shown). Each time a read operation occurs, one or more counters 910 may be configured to increment. In some examples, each time data from the contactless card 102 is read (e.g., by a mobile device), one or more counters 910 are sent to a verification service for verification, and it is determined whether one or more counters 910 (as part of the verification) are equal to the counters of the card issuer system 702 and / or the switch system 730.

[0214] The one or more counters 910 can be configured to prevent replay attacks. For example, if a password has been obtained and replayed, the password will be immediately rejected if the one or more counters 910 have been read or used or otherwise passed. If the one or more counters 910 have not been used, they can be replayed. In some examples, the counter incremented on the card is different from the counter incremented by the transaction. Since there is no communication between the applet 908 on the contactless card 102, the contactless card 101 cannot determine the one or more application transaction counters 910.

[0215] In some examples, one or more counters 910 may not be synchronized. In some examples, to account for unexpected reads that initiate transactions (such as reading at an angle), one or more counters 910 may be incremented, but the application does not process one or more counters 910. In some examples, when mobile device 10 is awake, NFC may be enabled, and device 110 may be configured to read available tags, but not make any response to the read.

[0216] In order to keep one or more counters 910 synchronized, an application (such as a background application) can be executed that will be configured to detect when the mobile device 110 wakes up and synchronizes with the card issuer system 702 and / or the switch system 730, which indicates a read that occurred due to the detection, and then moves the counter 104 forward. In other examples, a hashed one-time password can be used so that a window of false synchronization can be accepted. For example, if within a threshold of 10, one or more counters 910 can be configured to move forward. However, if within a different threshold number (e.g., within 10 or 1000), a request to perform a resynchronization can be processed, which requests the user to tap, gesture, or otherwise indicate one or more times through the user's device via one or more applications. If one or more counters 910 increase in the appropriate order, it can be known that the user has done so.

[0217] The key diversification technique described herein with reference to one or more counters 910, master keys, and diversification keys is an example of an encryption and / or decryption key diversification technique. This example key diversification technique should not be considered a limitation of the present disclosure, as the present disclosure is equally applicable to other types of key diversification techniques.

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

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

[0220] Additionally, the increments may be unique to each card and may be assigned through personalization or may also be assigned through some identifying information algorithm. For example, odd numbered cards may increment by 2 and even numbered cards may increment by 5. In some examples, the increments may also vary across sequential reads, such that a card may sequentially increment by 1, 3, 5, 2, 2, ..., and so on. The specific sequence or algorithmic sequence may be defined at personalization or from one or more processes derived from a unique identifier. This may make it more difficult for a replay attacker to generalize from a small number of card instances.

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

[0222] Fig.10 1000 is a timing diagram illustrating an example 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 may include communication between a contactless card 102 and a client device 1002. Client device 1002 may include an application 1004 and a processor 1006. In an embodiment, application 1004 may be a bank or card issuer application. Other examples of applications may include merchant applications, web browsers, game applications, etc. In an embodiment, client device 1002 may include any number of applications, and embodiments are not limited in this manner. In an embodiment, client device 1002 may be a mobile device, a point of sale terminal, a personal computer, etc. In addition, client device 1002 may include additional components, such as additional applications, a memory for storing instructions processed by processor 1006, an interface, etc.

[0223] At line 1008, the application 1004 communicates with the contactless card 102 (e.g., after being brought into proximity with the contactless card 102). In one example, the customer may be instructed to tap the contactless card 102 on the surface of the device to ensure that the card is within the wireless communication range of the card. The communication between the application 1004 and the contactless card 102 may involve the contactless card 102 being brought sufficiently close to a card reader (not shown) of the client device 1002 to enable NFC data transmission between the application 1004 and the contactless card 102. In some cases, the communication between the application 1004 and the contactless card 102 may be performed via an operating system that supports a wireless protocol (such as NFC, Bluetooth, WiFi, etc.) and utilizes a wireless interface.

[0224] At line 1010, after communication is established between client device 1002 and contactless card 102, contactless card 102 generates a message authentication code (MAC) password, such as message 500. In some examples, this may occur when contactless card 102 is read by the client device. In particular, this may occur when a near field data exchange (NDEF) tag is read (such as an NFC read), which may be created according to an NFC data exchange format. For example, a reader application (such as application 1004) may send a message with an applet ID of an NDEF production applet, such as an applet selection message. After confirming the selection, a sequence of a select file message and then a read file message may be sent. For example, the sequence may include "select capability file", "read capability file", and "select NDEF file". At this point, a counter value maintained by contactless card 102 may be updated or incremented, followed by "read NDEF file". At this point, a message (such as message 500) that may include a header and a shared key may be generated. A session key may then be generated. A MAC password may be created for a message that may include a header and a shared key. The MAC password may then be concatenated with one or more random data blocks, and the MAC password and random number (RND) may be encrypted with the session key. Thereafter, the password and header may be concatenated and 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.

[0225] In some examples, the MAC password can be sent as an NDEF tag, while in other examples, the MAC password can be included (e.g., as a formatted string) with a link or uniform resource indicator. In some examples, application 1004 can be configured to send a request to contactless card 102, the request including instructions to generate a MAC password. In some examples, the MAC password can be included with, for example, Figure 5 The additional data shown (e.g., applet version, issuer identifier, card unique identifier, and key identifier) ​​are included together. In an embodiment, at least the applet version and issuer identifier may be unencrypted in the unencrypted portion of the message. The switch system 108 may use the applet version and / or issuer identifier to determine where to route the message.

[0226] At line 1012, the contactless card 102 sends a message including the MAC password to the application 1004. In some examples, the transmission of the MAC password occurs via NFC, however, the present disclosure is not limited thereto. In other examples, such communication can be performed via Bluetooth, Wi-Fi or other wireless data communication means. At line 1014, the application 1004 communicates the message including the MAC password to the processor 1006.

[0227] In the sequence shown, at line 1016, the client device 1002 including the processor 1006 can verify the message including the content (such as the MAC password) according to the instruction from the application 1004. For example, the MAC password can be verified, as described below, for example, by the switch system 108 and the verification service. In some examples, verifying the MAC password can be performed by the client device 1002 or another device (such as a server of a bank system, a card issuer system 702, a switch system 108, etc.) that communicates data with the client device 1002. For example, the processor 1006 can output a message including the MAC password for transmission to a server of the card issuer system or the switch system 108, which can verify the data in the message including the MAC password, the shared key and the counter. In some examples, the MAC password can be used as a digital signature for verification. Other digital signature algorithms (such as public key asymmetric algorithms, digital signature algorithms and RSA algorithms or zero-knowledge protocols) can be used to perform this verification.

[0228] In an embodiment, an exchange between the contactless card 102 and the client device 1002 may be performed to perform any number of functions described herein. As discussed, embodiments include utilizing the contactless card 102 and tapping the card to a device to perform an authentication operation, such as MFA. In another example, the contactless card 102 may be used to perform a transaction for goods or services. There are other taps that perform functions, including tapping to automatically fill in one or more fields, tapping to launch an application, tapping to initialize a contactless card, tapping to install an application, tapping to open a door, tapping to start / enter a car, tapping to unlock a device, and the like. Embodiments are not limited to these examples. One or more operations discussed with respect to the sequence flow 1000 may be performed as part of a tap function operation.

[0229] As described above, the systems described herein are configured to support any number of tap functions using contactless cards, such as authentication / verification, performing transactions, auto-populating fields, etc. Fig.11 An example of a routine 1100 is shown that can be performed by the system herein to perform authentication or verification using a contactless card. In the example shown, the system can receive contactless card information from a contactless card via a device (such as a mobile device or a POS terminal). The system can process the information to determine whether it is authentic and generate a result. If the card is authenticated, the result can include a generated verification token indicating that the card was successfully verified. In some cases, such as Fig.14 As discussed in more detail in routine 1400, the verification token can be used to perform additional functions, such as performing transactions. Other functions may include opening doors, obtaining information, automatically filling in fields, launching applications, providing multi-factor authentication, etc.

[0230] In block 1102, routine 1100 includes receiving by the system a request including a message associated with performing a verification. In an embodiment, the request may be sent to the switch system 1608 via a submission to an API. Specifically, the switch system 1608 may include a set of APIs configured to receive the request and provide a response to authenticate the user. In this example, the request may be a verification or authentication and include a message having an encrypted portion and an unencrypted portion. In some embodiments, the request may also include a session token and an extension. Below is an example format of a request.

[0231] POST / validation

[0232] {"tapMessage":"encrypted_portion / decrypted_portion",

[0233] "sessionToken":"abcdefg..." / / Token from Session Initialization

[0234] "extensions":{...}}

[0235] Note that the embodiments are not limited to this example. In an embodiment, the switch system 1608 may use the encrypted portion of the message for authentication, while the switch system 1608 may use the decrypted or unencrypted portion to route the message to the appropriate process to perform the authentication. Figure 5 An example of a message 500 is shown. In an embodiment, the system may utilize the unencrypted portion to determine at least where to route the message to perform authentication.

[0236] In some cases, a client session may first be requested to be established between the device and the system to obtain a verification token. In these cases, the device may send a request or submission to a session initialization API that may include usage information for the verification token. For example, a verification token may be used as part of a transaction, and session initialization may be established by submitting information such as a merchant identifier, a reader identifier, and client information including one or more of an Internet Protocol (IP) address, a geographic location, a device identifier, a user agent, and a host name to the API. The submission to establish a session to perform a transaction may have the following format, but is not limited to this approach:

[0237] POST / session{

[0238] "merchantId":"3fa85f64-5717-4562-b3fc-2c963f66afa6",

[0239] "readerId":"3fa85f64-5717-4562-b3fc-2c963f66afa6",

[0240] "clientInformation":{"ipAddress":"198.xx.xxx.xx","geolocation":{},"userAgent":"string","hostname":"example.com"}}

[0241] In an embodiment, the switch system 1608 can process the submission and perform one or more operations to determine the risk factor based on the client information and the determination of whether to issue a session token. In response, the system can return a session token in JavaScript Object Notation (JSON) Web Token (JWT) format:

[0242] {"sessionToken":" <jwt>",

[0243] "valid":true,

[0244] "validUntil":"2022-02-04T19:15:39.693Z"}

[0245] Additionally, the session token JWT signed by the session API can include the following embedded details:

[0246] {iss:", / / Identifies the issuer of the JWT, will be the same for each JWT sub:' <uuid>', / / Randomly generated UUID represents the session ID

[0247] exp:1648217401, / / The epoch timestamp indicating the time when this JWT expires

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

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

[0250] creationTime:1648217401, / / The epoch timestamp indicating the time when the session was created}

[0251] As described above, the session token may 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 is not required in future requests. In an embodiment, the submission and response to establish a session may include different usage information based on the purpose for which the session is being established. For example, if the session is to perform verification or authentication, the submission may include information about the requesting party. For example, assume that the session is being established as part of an auto-fill process. In this case, the session is being established as part of the auto-fill process, and the submission may include usage information, such as the website receiving the data, the data requested, etc. The session is being established as part of the auto-fill process, and the submission may include usage information, such as the website receiving the data, the data requested, etc. The embodiments are not limited in this manner.

[0252] In block 1104, the routine 1100 includes determining, by the system, a verification service associated with a contactless card issuer based on information in the unencrypted portion of the message. For example, the switch system 1608 may determine the contactless card issuer based on an issuer identifier included in the message. One or more verification services may include multiple processes and / or functions that may be executed to verify information in the encrypted portion of the message.

[0253] In block 1106, the routine 1100 includes sending at least the encrypted portion of the message to the verification service. Since the verification service is associated with the contactless card issuer, it can access secure data associated with that particular issuer, but not any other issuer. Thus, the information for each issuing bank can be isolated to increase data security.

[0254] In an embodiment, the authentication service is configured to verify information in the message, such as a MAC password, a counter value, etc. Fig. 12A and Fig. 12B As shown and discussed, the authentication service can send the message or at least a portion of the message (e.g., an encrypted portion) to the message authentication service 724 and the cryptographic authentication service 726 to perform authentication.

[0255] In an embodiment, the verification service can determine the result of the verification operation performed by the message verification service 724 and the password verification service 726 and return the result. In some cases, the request can include an indication of successful or unsuccessful verification. In addition, the verification can determine and / or generate a verification token that can be returned to the system to be returned to the device.

[0256] In block 1108, the routine 1100 includes generating a verification token based on the information in the encrypted portion of the successful verification message from the verification service. The verification token may be in a JWT format, such as:

[0257] {iss:"DistributionPartner", / / Verify the unique identifier of the API implementer

[0258] exp:"2022-02-04T16:57:19Z", / The time when a valid token should expire (15 minutes TTL is recommended)

[0259] puid:0123456789101112, / / unique identifier of the card tapped

[0260] clientId: "3fa85f64-5717-4562-b3fc-2c963f66afa6", / / unique identifier of the client timeVerified: "2022-02-04T16:57:19Z" / / time point at which the card was considered valid}

[0261] In block 1110, the routine 1100 returns the verification token to the mobile device by the system. In an embodiment, the verification token may be a response to the submission, and its format may be, for example:

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

[0263] "valid":true,

[0264] "validityToken":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ..."}

[0265] Note that if one or more authentication operations fail, the routine 1100 can return a failure indication to the requesting device.

[0266] Fig.11 Routines executed by the switch system 1608 and a device, such as a mobile device, are included to verify the contactless card information through the switch system 1608. However, in some cases, the device may send a request including a message directly to the issuer system 702, and the issuer system 702 may route the message through the verification service of the switch system 1608 to perform verification and receive a validity token. In even other cases, the issuer system 702 may perform the verification itself and return an indication as to whether the contactless card is valid.

[0267] Fig. 12A A detailed view of the authentication system 1204 that can perform one or more operations to authenticate information and can be part of the switch system 1608 is shown.

[0268] In some example embodiments, the verification system 1204 includes a message verification service 724 configured to receive an incoming verification request (e.g., a message generated by a contactless card when performing a tap or NFC read, or at least an encrypted portion of the message). In one example, the request can be directed to the message verification service 724, for example, via a switch node based on processing performed by the switch system 1608 to process the issuer identifier in the unencrypted portion of the message, such as Figure 4A-4C In some cases, the message may be received from another system (such as the card issuer system 702).

[0269] In an embodiment, the message verification service 724 may perform one or more services to perform an initial verification of the message. For example, the message verification service 724 may parse the message fields to determine a unique identifier of the card, such as a pUID. The message verification service 724 may use the unique identifier as a key to retrieve the associated card record data stored in a database (such as, card database 1202) and perform basic verification on the record data. For example, the message verification service 724 may verify the information in the message based on the information in the record (e.g., application version, issuer ID, pKeyID, pUID, pATC, random number, and / or pSHSEC). The 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.

[0270] In an embodiment, the card database 1202 may store additional information such as card personalization details including the card platform and applet version (application version), and the message verification service 724 may also ensure that the card platform and / or applet version in the message matches the stored information.

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

[0272] In response to the initial verification being successful, the message verification service 724 records the verification request in the card database 1202 and requests the password verification service 726 to verify the password and the information in the password.

[0273] In an embodiment, the message authentication service 724 may also compare the counter value in the message with the counter value maintained in the card database 1202. In some cases, the counter value on the card (pATC) may be out of sync with the stored counter value (e.g., unregistered read). In these cases, the message authentication service 724 may ensure that the card counter value is within an acceptable range of the stored counter values. In some cases, if the card counter value exceeds the acceptable range of the stored counter value or is less than the stored counter value, the message authentication service 724 may determine that fraud has occurred.

[0274] In an embodiment, the basic verification of the message verification service 724 is successful, and the message verification service 724 can record the transaction and verification details for auditing, and communicate with the password verification service 726 to verify the password. In order to verify the password, the password verification service 726 can generate one or more pairs of keys to first decrypt the password. In some cases, the password verification service 726 can use the key identifier in the unencrypted part of the message from the verification HSM 728 to retrieve the master key associated with the card issuer. The password verification service 726 can use the master key to generate a derived key based on the card or unique identifier. Then, the derived key can be used to generate a session key for a given session using a counter value maintained by the verification system and / or a counter value provided in the message. The counter value should match or be within the range of the counter value on the contactless card. Note that in some embodiments, the password verification service 726 can start with a derived key that can be stored in the verification HSM 728 instead of a master key, and then generate a session key. The embodiment is not limited to this approach.

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

[0276] In an embodiment, the cryptographic verification service 726 can verify additional information including the card identifier, account number, customer name, etc., if they are also in the encrypted portion. If the cryptographic is successfully decrypted and the information matches, the cryptographic verification service 726 can verify the message, and the verification service can return a successful verification result to the device. In some cases, the result can include a validity token that can be used to perform additional operations.

[0277] In some embodiments, the system 700 can utilize a verification HSM 728, which can be a payment-grade HSM, to store master keys used in cryptography and perform operations involving them, such as deriving other keys, encryption, decryption. However, payment-grade HSMs are very limited and require proprietary libraries to interact with them. To avoid hardware dependencies and make reference implementations easier, some embodiments use a java key store 1206, such as Fig. 12B As shown, it follows the same steps, but uses an open source cryptographic library. The embodiments are not limited in this manner.

[0278] Fig.13 An example sequence diagram 1300 is shown in accordance with embodiments discussed herein. The sequence diagram 1300 shows high-level steps that may be performed to authenticate a user and their contactless card through a switch system 1306. Fig.13 One possible sequence is shown, and the embodiments are not limited to this sequence. In some cases, one or more steps may occur before other steps and / or in parallel with each other.

[0279] At 1312, client device 1304 receives a request to perform user verification. For example, a mobile application (such as a merchant application) can generate a request to verify the user of client device 1304 to perform a transaction. In another example, as part of a multi-factor authentication sequence, the application can request to verify the user. In a third example, as part of a login sequence, the application can request to verify the user. Embodiments are not limited in this manner. In some cases, the request can be generated by the user himself, such as via a user interface, or by an external system (such as a POS transaction system).

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

[0281] At 1316, the client device 1304 may communicate with the contactless card 1302. For example, in response to the user bringing the contactless card 1302 within range of 1304, a wireless communication exchange may occur between the client device 1304 and the contactless card 1302. The wireless exchange may be based on a wireless protocol, such as Bluetooth, NFC, WiFi, etc. In some cases, the exchange may be a "wired" exchange of the client device 1304 based on the contact points of contact 1302. In an embodiment, the exchange may be based on EMV, and the message may be modified as described herein. In some cases, the client device 1304 may read and / or receive messages from the contactless card 1302. In addition, the client device 1304 may also write and / or send data to the card, for example, a random number that may be merged back into the data read by the client device 1304.

[0282] In an embodiment, the client device 1304 may receive data (such as in a message) as part of the exchange from the contactless card 1302. The message may include, for example, an encrypted portion and an unencrypted portion of a password. Figure 5 An example of a message 500 is shown.

[0283] At 1318, the client device 1304 may send a verification request to the switch system 1306. The request may include a message. Fig.11 As discussed in , the request can be a submission to an API of the switch network 1308. At 1320, the switch network 1308 can determine where to route the request and the verification service that performs the verification. Specifically, the switch network 1308 can utilize the card issuer identifier in the unencrypted portion of the message to determine the card issuer and its verification service.

[0284] At 1322, the hub network 1308 may send the message to the verification system 1310 to be verified. The verification system 1310 may process the message using services specifically assigned to the card issuer and / or data associated with the card issuer. At 1324, the verification system 1310 may perform one or more verifications, such as regarding Fig. 12A and Fig. 12B discussed.

[0285] At 1326, the verification system 1310 can return the verification result to the switch network 1308, and at 1328, the switch network 1308 can forward the result to the client device 1304. The result can include a verification token that can be used to verify the user. For example, the verification token can be used as a login name for the user to log into an application. In another example, the verification token can be provided to another system as part of an MFA sequence. In a third example, the verification token can be provided to an entry system to enter a door or room. As will be described in Fig.14 As discussed in more detail in , a verification token can be determined and then provided to the merchant system to perform the transaction.

[0286] In embodiments, system 700 may be used to perform additional functions, such as conducting transactions between cardholders, card issuers, and merchants. Fig.14 One example routine 1400 is shown that may be executed by the system 700 including the switch system 1608 to process a transaction for a merchant. In some cases, the transaction may be initiated on a device, such as a mobile device or a POS terminal.

[0287] 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 information request may be required to perform a transaction. The one or more indicators may indicate what information the merchant system is requesting to perform the transaction, such as fields. The information may include the customer's name (first, middle, and last), date of birth, social security number, address, account number, contactless card information (account number, cvv, expiration date), etc.

[0288] In an embodiment, the verification token may be a token provided by the system that can be used to perform functions, such as Fig.11 , Fig. 12A , Fig. 12B and Fig.13 The verification token indicates that the contactless card is authenticated by the system. In some cases, the contactless card may have been authenticated previously or as part of a transaction process.

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

[0290] In an embodiment, the request may be a submission to an API interface of the switch system 730. The following is an example format of an API POST according to an embodiment. Note that the embodiment is not limited to this method, and the request may be in other formats.

[0291] POST / cardholder-information

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

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

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

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

[0296] "publicKeySignature":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ..." / / Public key signature. Should be used in conjunction with a certificate to verify the public key

[0297] }}

[0298] In some cases, before the information requested by the merchant will be provided to the merchant, the customer may first have to agree. In one example, a merchant application on a device (such as a mobile device or a POS device) can confirm with the customer that they agree to provide the information to the merchant. The merchant application can then send the consent message as an API submission to the system 700 (e.g., the switch system 730). The following is an example format of a POST.

[0299] POST / cardholder-information / consent

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

[0301] / / Fields returned from the customer record

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

[0303] "sessionToken":"abc..." / / from session initialization

[0304] }

[0305] The consent may include an indication of the information allowed to be provided to the merchant, a validity token, and a session token. In some cases, the system 700 may send a confirmation request to the device, for example, via a mobile application of the card issuer. If the consent is successfully given, the system 700 may return a successful response that consents to the sharing request. The following is an example response.

[0306] 700OK

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

[0308] "success":true}

[0309] In block 1404, the routine 1400 includes determining a business service associated with a contactless card issuer. For example, the switch system 730 may perform a lookup to determine which card issuer is associated with the contactless card based on information in the cardholder information request. In a specific example, the switch system 730 may utilize a validity token to determine the card issuer. As discussed, the validity token includes information such as the card issuer or a distributed partner, and the switch system 730 may utilize the information to determine one or more associated business services that may further process the request.

[0310] In block 1406, the routine 1400 includes sending at least a portion of the request to a business service. The business service may be part of the switch system 1608, such as a "merchant / business api," and perform one or more operations. Specifically, the business service may verify the validity token and the information in the validity token. In an embodiment, the validity token may be communicated to the one or more business services encrypted via a public key obtained by the merchant. The one or more business services may include an associated private key and perform decryption prior to verifying the information within the token.

[0311] One or more business services can also ensure that the cardholder has agreed to provide the requested information. For example, the business service can ensure that the customer has agreed to share records on the service system 734.

[0312] In an embodiment, one or more merchant services may be configured to obtain the requested data in response to verifying the validity token, and the customer has agreed to share the data. In some cases, the merchant service may obtain information from the issuer system 702 via an API. For example, the merchant service sends a request to the issuer system 702, which may include one or more indicators, the validity token, and encryption parameters. In an embodiment, the issuer system 702 may verify the merchant credentials based on information provided by the merchant during the engagement process.

[0313] The card issuer system 702 may also obtain the requested information from one or more data stores (e.g., a database). The information may then be encrypted by the card issuer system 702 so that the switch system 730 may not be able to "see" or decrypt the information. Thus, the customer's information is securely maintained by the card issuer system 702, and / or the switch system 730 is only visible to the merchant system to perform the transaction.

[0314] 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 merchant services and switch system 730. In addition, at block 908, the routine 1400 includes receiving the contactless card holder information and the contactless card issuer certificate from the issuer system 702, for example.

[0315] At box 1410, routine 1400 includes sending a response to the contactless cardholder information request to the merchant system. The response may include encrypted cardholder information. Therefore, information can be securely transmitted between the card issuer system 702 and the merchant system 706. The response may include additional information, such as a request identifier (see box 1402) of the associated request identified, an indication of whether the request is successful, and encryption parameters. The encryption parameters may include a public key, a card issuer certificate, and a public key signature to verify the public key with the card 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 signature. The unencrypted public key can be used to encrypt information to be sent to the card issuer system 702, and the card issuer system 702 can decrypt the information with the card issuer's private key.

[0316] The merchant system 706 can verify the issuer certificate based on the information exchanged between the merchant system 706 and the issuer system 702 during the engagement process. The merchant system 706 can decrypt the public key and signature with the merchant's private key to obtain the key and signature. The signature of the certificate can be used to verify the issuer's public key. The following is an example response. Note that the embodiment is not limited in this manner and the response can be in a different format.

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

[0318] "success":true,

[0319] "cardholderInformation":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ....", / / Encrypted cardholder information

[0320] "encryptionParameters":{"ephemeralPublicKey":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ...." / / Temporary key, encrypted with the public key passed by the merchant

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

[0322] "publicKeySignature":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ..." / / Signature of the public key. Should be used in conjunction with the certificate to verify the public key

[0323] },}

[0324] In an embodiment, the merchant system 706 can receive the encrypted cardholder information and decrypt it using the merchant's private key. In an embodiment, the merchant system 706 can use the information to perform a transaction or other functions, such as populating one or more fields of a checkout form, saving the information in a secure data store for future use, etc.

[0325] Fig.15 An example of a sequence diagram 1500 performed in accordance with an embodiment is shown. The sequence may be performed between the systems discussed herein as part of a transaction process that utilizes a verification token to obtain information to perform a transaction by a merchant.

[0326] At 1514, the client device 1502 may send a request to the merchant system 1504 to perform a transaction. The transaction may be for the purchase of goods or services, and the embodiments are not limited in this manner. In embodiments, the request may include information about the transaction, an identifier, one or more purchase terms, customer information, etc. In embodiments, the request may also include a verification token that may be used by the merchant system 1504 to perform a transaction with a backend banking system (e.g., the switch system 1506 and the card issuer system 1512). The verification token may have been pre-acquired according to the previously described process flow and sequence.

[0327] At 1516, merchant system 1504 may send a request for information to perform the transaction to switch system 1508 of switch system 1506. The request may be an API POST and include a list of requested information (fields), a verification token, and encryption information that may be used to encrypt the requested information. Fig.14 An example API POST format according to an embodiment is discussed at block 1402 .

[0328] At 1518, the switch system 1508 can utilize the information in the request to determine the card issuer and / or merchant system associated with the transaction. For example, the switch system 1508 can utilize the verification token to determine the associated card issuer bank and the corresponding merchant system.

[0329] At 1520, the switch system 1508 can send a request to the determined merchant system 1510 to process the request and determine the information. In addition, at 1522, the merchant system 1510 can send a request for the requested information to the card issuer system 1512. The request can include encryption information that can be used by the card issuer system 1512 to encrypt the requested information so that the data remains secure and unrecognizable until the merchant system 1504 receives and decrypts the information, such as Fig.14 shown.

[0330] At 1524, the card issuer system 1512 may determine information based on the request and encrypt the information. At 1526, the encrypted information may be returned to the merchant system 1510. At 1528, the merchant system 1510 may send the encrypted information to the switch system 1508. The encrypted information may remain secure, and neither the system switch system 1506 has the ability to decrypt the information. And the information remains secure until it is decrypted by the merchant system 1504. At 1530, the switch system 1508 may send the encrypted information to the merchant system 1504. At 1532, the merchant system 1504 may decrypt the information and use the information to complete the transaction.

[0331] Fig.16 An example of a simplified process flow 1600 that can be performed according to an embodiment is shown. Specifically, the process flow 1600 can be performed in an environment that utilizes the switch system 108 / 208 to provide processing and communication in a multi-bank issuing system environment. The process flow 1600 is an example of a process for performing a transaction between a merchant and a customer using a contactless card issued by one of multiple issuing banks, and includes obtaining a verification token (such as Figure 7-9 as shown) and obtain transaction information (as Fig.10 and 11 shown).

[0332] At line 1602, the user may tap their contactless card on the mobile device 104. In one example, the user may tap their contactless card on the device in response to a mobile application prompt to tap the card. The contactless card provides data to the mobile device 104, and the mobile device 104 may forward the data to the switch system 1608. The data may include encrypted and unencrypted data in a message, such as message 900b.

[0333] At line 1604, the switch system 1608 can use the data in the message to determine the card validator, such as a verification service. For example, the switch system 1608 can perform a lookup using unencrypted data (e.g., the card issuer id 910) to determine the verification service 720 to route the message.

[0334] The switch system 1608 can send the message to the corresponding authentication service 720 including an authentication API configured to process the message containing the encrypted portion. Specifically, the corresponding authentication service 720 can decrypt the encrypted portion and authenticate the data, for example, Fig. 12A or Fig. 12B described.

[0335] At line 1606, the verification service 720 can communicate the validity token back to the switch system 1608 and the mobile device 104. At line 1610, the merchant system 706 requests the user / customer information from the switch system 1608 with a request for cardholder information (including the validity token and other data), such as Fig.14 The switch system 1608 can perform a lookup with the corresponding card issuer based on the information (eg, validity token) received from the merchant system 706.

[0336] At line 1614, the switch system 1608 communicates with the merchant service of the card issuer network and the corresponding card issuer and receives the encrypted user / customer information. The switch system 1608 can return the encrypted user / customer to the merchant system 706, and the merchant system 706 will decrypt the information to perform transactions or other functions.

[0337] Fig.17 A simplified example of an encryption process 1700 that can be performed in accordance with embodiments discussed herein to ensure that data communicated between an issuer system and a destination system, such as a merchant system 1714, is secure is shown. At 1702, a merchant 1714 requests cardholder information from a switch system 1716, for example, in a request message through an API. At 1704, the encryption process 1700 includes the switch system 1716 performing a lookup to determine the issuer to determine which business API 1718 to route the data. The data is communicated to the associated business API service. At 1706, the certificate authority 1720 verifies the merchant certificate and / or returns a result. At 1708, the process includes the service 1718 generating an ECDH secret (or public / private key pair) and encrypting the cardholder data. At 1708, the cardholder data is communicated to the merchant 1714. At 1710, the encryption process 1700 includes the merchant system verifying the certificate. Additionally, at 1712, the encryption flow 1700 includes the merchant generating an ECDH secret and decrypting the cardholder data.

[0338] Fig.18 A distributed network authentication system 1900 is shown according to an example embodiment. As discussed further below, the system 1900 may include a client node 1802, an API 1804, a network 1806, a distributed ledger node 1810, a mapping 1812, and a client device 1814. Fig.18 A single instance of a component is shown, but system 1900 may include any number of components.

[0339] The system 1900 may include a client node 1802, which may be a network-enabled computer as described herein. In some examples, the client node 1802 may be a server, which may be a dedicated server computer, a blade server, or may be a personal computer, a laptop, a notebook, a PDA, a network computer, a mobile device, a wearable device, or any processor-controlled device capable of supporting the system 1900.

[0340] In some examples, client node 1802 may execute one or more applications (such as software applications) that enable, for example, network communications with one or more components of system 1900, send and / or receive data, and perform the functions and processes described herein.

[0341] The client node may include an API 1804. For example, various different APIs may be provided to an application (e.g., executing on a computing device, such as a network-enabled computer) that may interact with the service. For example, an application executing on a device (e.g., a smart phone, smart watch, tablet, laptop, or other device) calls the API 1804 to interact with the network-based service to interact with the service, such as by performing a remote call to the API to interact with the network-based service.

[0342] The API 1804 may be provided in the form of a library of specifications including routines, data structures, object classes, and variables. In some cases, such as for a Representational State Transfer (REST) ​​service, an API (e.g., a REST API or a RESTful API, or an API that embodies certain RESTful practices) is a specification of remote calls exposed to API clients (e.g., an application executing on a client computing device may become a client of a REST API by executing a remote call to the REST API). A REST service generally refers to a software architecture for coordinating components, connectors, and / or other elements within a distributed system (e.g., a distributed hypermedia system).

[0343] The client node 1802 may communicate with one or more other components in the system 1900 directly or via a network 1806. The network 1806 may include one or more of a wireless network, a wired network, or any combination of wireless and wired networks, and may be configured to connect the components of the system 1900. Fig.18 Communications between components of system 1900 are shown via network 1806 , but it should be understood that any component of system 1900 may communicate directly with another component of system 1900 , e.g., without involving network 1806 .

[0344] System 1900 may include a verification node 1808, which may be a network-enabled computer as described herein. In some examples, verification node 1808 may be a server, which may be a dedicated server computer, a blade server, or may be a personal computer, a laptop, a notebook, a PDA, a network computer, a mobile device, a wearable device, or any processor-controlled device capable of supporting system 1900.

[0345] In some examples, verification node 1808 may execute one or more applications (such as, software applications) that are capable of, for example, engaging in network communications with one or more components of system 1900, sending and / or receiving data, and performing the functions and processes described herein.

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

[0347] The system 1900 may include a distributed ledger node 1810, which may be a network-enabled computer as described herein. In some examples, the distributed ledger node 1810 may be a server, which may be a dedicated server computer, a blade server, or may be a personal computer, a laptop, a notebook, a PDA, a network computer, a mobile device, a wearable device, or any processor-controlled device capable of supporting the system 1900.

[0348] In some examples, distributed ledger node 1810 may execute one or more applications (e.g., software applications) capable of, for example, communicating with a network of one or more components of system 1900, sending and / or receiving data, and performing the functions and processes described herein.

[0349] Distributed ledger node 1810 may include mapping 1812. In some examples, mapping 1812 may be in the form of one or more databases. Exemplary databases may include, but are not limited to, relational databases, non-relational databases, hierarchical databases, object-oriented databases, network databases, and any combination thereof. One or more databases may be centralized or distributed. One or more databases may be hosted internally by any component of system 1900, or one or more databases may be hosted externally of any component of system 1900. In some examples, one or more databases may be included in distributed ledger node 1810, while in other examples, one or more databases may be stored externally of distributed ledger node 1810, but communicate data with distributed ledger node 1810. One or more databases may be implemented in a database programming language. Exemplary database programming languages ​​include, but are not limited to, structured query language (SQL), MySQL, hypertext markup language, JavaScript, hypertext preprocessor language, practical extraction and reporting language, extensible markup language, and universal gateway interface. Queries to one or more databases may be implemented in the same database programming language as the one or more databases implemented. For example, if one or more databases are SQL databases, then the databases may be queried using SQL (e.g., SELECT column1, column2 FROM table1, table2 WHERE column2 = 'value';). It should be understood that one or more databases may be implemented using any database programming language, and the programming implementation of the query may be adjusted as needed to be compatible with the one or more databases and to reflect the specific information to be queried.

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

[0351] In some examples, client node 1802 can communicate data with distributed ledger node 1810. Distributed ledger node 1810 can include mapping 1812. Mapping 1814 can include, for example, a mapping between a verification node address and a verification node 1808, a mapping between a routing number and a verification node address, and / or a mapping between a routing number and a verification node 1808. In some examples, mapping 1812 can include a digital signature associated with an entity with authority to verify the routing number. Based on one or more of these associations, client node 1802 can call a verification node for verification and / or provide directions to the client device to reach the appropriate verification node. This can be achieved by calling a verification API associated with verification node 1808.

[0352] In some examples, an iteration of a mapping described herein, such as mapping 1812, may also include a software or applet version number. The version number may be used to identify a verification node or verification node address, or to select between multiple verification addresses for a verification node.

[0353] In some examples, client nodes 1802 and distributed ledger nodes 1810 can be licensed (e.g., allowed to join the network) with the help of certificates and / or password authentication mechanisms (e.g., non-interchangeable tokens). Certificates and / or password authentication mechanisms can be issued, for example, by a federation or other administrative entity associated with the distributed network. If appropriate permissions are granted, distributed ledger node 1810 can update mapping 1812 to reflect, for example, different associations between routing numbers, verification node addresses, and verification nodes. In some examples, levels of permissions can be issued. For example, if client node 1802 is used to route data to verification node 1808 (or other verification nodes), client node 1802 can be granted a certain level of permissions. As another example, if distributed ledger node 1810 has the ability to update mapping 1812, distributed ledger node 1810 can have different, higher levels of permissions.

[0354] System 1900 may include client devices 1814, which may be network-enabled computers as described herein. In some examples, distributed ledger node 1814 may be a server, which may be a dedicated server computer, a blade server, or may be a personal computer, a laptop, a notebook, a PDA, a network computer, a mobile device, a wearable device, or any processor-controlled device capable of supporting system 1900. Client device 1814 may also be a mobile device; for example, a mobile device may include iPhone, iPod, iPad or running Apple Any other mobile device running Microsoft Mobile operating system devices, running Google 1814 can communicate with a device running a Windows XP operating system, and / or any other smartphone, tablet, or similar wearable mobile device. Fig.18 Data communications are performed with another network-enabled computer not shown, such as a smart card (e.g., a contactless card or a contact-based card).

[0355] In some examples, client device 1814 may execute one or more applications (such as software applications) that are capable of, for example, communicating with a network of one or more components of system 1900, sending and / or receiving data, and performing the functions and processes described herein.

[0356] In some examples, upon receiving an authentication request, the client device 1814 may call the client node 1802 (e.g., via an API). The call may include a routing number and / or a small application or software version number, and the client node 1802 may query the distributed ledger node 1810 and the mapping 1812. Once the query returns an identification of a verification node (e.g., verification node 1808) and / or a verification node address associated with the routing number and / or small application or software version, the client node 1802 may reply to the client device 1814. The client device 1814 may then proceed to authenticate with the verification node. Authentication may be performed, for example, by the systems and methods described herein, such as by the generation, encryption, transmission, decryption, and verification of passwords described herein.

[0357] In some examples, client node 1802 may be co-resident with verification node 1808. In these examples, client node 1802 may handle authentication in a single call from client device 1814. In some examples, this may be acceptable only if it is permitted to send a complete authentication transmission (e.g., a password as described herein) to a client node that is not involved in authentication.

[0358] In some examples, if client node 1802 receives a routing number that is not processed for its location from client device 1814, client node 1802 can return a code indicating that the routing number is not processed, as well as the address of the responsible verification node. Client device 1814 can then send a complete authentication transmission to verification node 1808 using the received verification node address.

[0359] In some examples, client node 1802 may enter the distributed network with different permissions. For example, client node 1802 may be a read-only router for data. As another example, client node 1802 may have the authority to send a message to distributed ledger node 1810 to update one or more routing paths of one or more routing numbers. However, client node 1802 will be blocked from updating one or more routing paths of one or more routing numbers of other entities that control other routing numbers that are not related to client node 1802 or have not been granted this permission. As another example, distributed ledger node 1810 may contain contracts and / or records that can change specific routing records based on the authority of a specific entity to verify its digital signature. As another example, a consortium or other management entity that controls a distributed network may have additional privileges, including but not limited to adding new members (e.g., client nodes, distributed ledger nodes, verification nodes, and / or client devices), adding new signing credentials, adding new keys, adding new certificates, and revoking any of the above. In some examples, if security, legal, and / or financial conditions are met but delegation is not required, the above permissions can be delegated to client node 1802, distributed ledger node 1810, and / or validating node 1808.

[0360] In some examples, one or more APIs can facilitate communication between components of system 1900 via network 1806. In other examples, one or more APIs are not required. Instead, components of system 1900 can communicate directly and / or be dedicated to one or more designated entities to allow designated entities to prevent data from being transmitted to, from, or via undesignated entities. This can further promote data security and avoid detection of data traffic patterns by undesignated entities.

[0361] In some examples, an entity may establish standards for nodes with APIs based on the intended functionality of those nodes. For example, a first standard may be established for a data routing node, and a second standard may be established for a node that performs mapping and / or authentication functions. As another example, a routing API, a mapping API, and a verification API may be established, which may allow the same device or hardware configuration to perform these functions. However, the use of keys including secret keys used by verification nodes 1808 for authentication may require that the keys be stored in one or more HSMs to improve key security and ensure that the keys never enter storage.

[0362] Fig.19 A method 1900 performed by a distributed network authentication system according to an example embodiment is shown. For example, the method may be performed by the distributed network authentication system 1800 and / or by another distributed network authentication system.

[0363] In block 1902, the client device may send an authentication request to the client node. The authentication request may include, but is not limited to, a routing number, a software version number, and / or a small application version number. The request may be made by an API call or other communication between the client device and the client node.

[0364] In block 1904, after receiving the authentication request, the client node may 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 may submit a query to the mapping.

[0365] In block 1906, the query may return an identification of a validating node and / or a validating node address, and the distributed ledger node may send the identification to the client node.

[0366] In block 1908, the client node may send the identification to the client device. After receiving the identification, in block 1910, the client device may proceed with authentication using the identified validating node and / or validating node address.

[0367] Fig. 20 An embodiment of an exemplary computer architecture 2000 suitable for implementing various embodiments as previously described is shown. In one embodiment, the computer architecture 2000 may include or be implemented as part of one or more systems or devices discussed herein.

[0368] As used in this application, the terms "system" and "component" are intended to refer to computer-related entities, which can be hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing computer architecture 2000. For example, a component can be, but is not limited to, a process running on a processor, a processor, a hard drive, multiple storage drives (of optical and / or magnetic storage media), an object, an executable file, an execution thread, a program, and / or a computer. By way of example, both an application running on a server and a server can be components. One or more components can reside in a process and / or an execution thread, and a component can be located on a computer and / or distributed between two or more computers. In addition, components can be communicatively coupled to each other by various types of communication media to coordinate operations. The coordination can involve unidirectional or bidirectional information exchange. For example, a component can transmit information in the form of a signal transmitted by a communication medium. The information can be implemented as a signal assigned to various signal lines. In such an assignment, each message is a signal. However, alternatively, further embodiments can also adopt data messages. Such data messages can be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0369] The computing architecture 100 includes various common computing elements, such as one or more processors, multi-core processors, coprocessors, memory units, chipsets, controllers, peripherals, 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 the computing architecture 100.

[0370] like Fig. 20 As shown, computing architecture 100 includes processor 2012, system memory 2004, and system bus 2006. Processor 2012 may be any of a variety of commercially available processors.

[0371] The system bus 2006 provides an interface for system components, including but not limited to the system memory 2004 to the processor 2012. The system bus 2006 can be any of several types of bus structures, which can further be interconnected with 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. Example slot architectures can include but are not limited to accelerated graphics port (AGP), card bus, (extended) industry standard architecture ((E)ISA), micro channel architecture (MCA), network user bus, peripheral component interconnect (extended) (PCI (X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), etc.

[0372] The computing architecture 100 may include or implement various articles of manufacture. Articles of manufacture may include computer-readable storage media for storing logic. Examples of computer-readable storage media may include any tangible media capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, etc. Examples of logic may include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, etc. Embodiments may also be implemented at least in part as instructions contained in or on a non-transitory computer-readable medium, which may be read and executed by one or more processors to enable the operations described herein to be performed.

[0373] The system memory 2004 may 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), bidirectional memory, phase change or ferroelectric memory, silicon-silicon oxide-silicon nitride-silicon oxide-silicon (SONOS) memory, magnetic or optical cards, device arrays (such as redundant array of independent disks (RAID) drives), solid-state storage devices (e.g., USB memory, solid-state drive (SSD)), and any other type of storage medium suitable for storing information. Fig. 20 In the illustrative embodiment shown, system memory 2004 may include non-volatile 2008 and / or volatile 2010. A basic input / output system (BIOS) may be stored in non-volatile 2008.

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

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

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

[0377] 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 may be internal or external to the computer 2002. In addition to the monitor 2044, computers typically include other peripheral output devices, such as speakers, printers, and the like.

[0378] The computer 2002 can operate in a networked environment using logical connections via wired and / or wireless communications with one or more remote computers, such as (one or more) remote computers 2048. The one or more remote computers 2048 can be workstations, server computers, routers, personal computers, portable computers, microprocessor-based entertainment devices, peer devices, or other public network nodes, and typically include many or all of the elements described relative to the computer 2002, although for the purpose of simplicity, only memory and / or storage devices 2058 are shown. The depicted logical connections include wired / wireless connections to a local area network 2056 and / or a larger network, such as a wide area network 2054. Such LAN and WAN networking environments are common in offices and companies, and facilitate enterprise-wide computer networks (such as intranets), all of which can be connected to a global communication network, such as the Internet.

[0379] When used in a LAN 2056 networking environment, the computer 2002 is connected to the LAN 2056 through a wired and / or wireless communication network interface or network adapter 2038. The network adapter 2038 can facilitate wired and / or wireless communications to the LAN 2056, which can also include a wireless access point disposed thereon for communicating with the wireless functionality of the network adapter 2038.

[0380] When used in a wide area network 2054 networking environment, the computer 2002 may include a modem 2040, or be connected to a communication server on the wide area network 2054, or have other means for establishing communications on the wide area network 2054, such as through the Internet. The modem 2040 may be an internal or external wired and / or wireless device connected to the system bus 2006 via the input device interface 2036. In a networked environment, program modules or portions thereof described relative to the computer 2002 may be stored in the remote memory and / or storage device 2058. It should be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

[0381] The computer 2002 is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively arranged in wireless communications (e.g., IEEE 802.11 over-the-air modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth, among others. TM Wireless technology. Therefore, the communication can be a predefined structure like a conventional network, or just an ad hoc communication between at least two devices. Wi-Fi networks use radio technology called IEEE802.11 (a, b, g, n, etc.) to provide secure, reliable, and fast wireless connections. Wi-Fi networks can be used to connect computers to each other, to the Internet, and to wired networks (which use IEEE 802.3 related media and functions).

[0382] As previously described herein, various elements of the device may include various hardware elements, software elements, or a combination of the two. Examples of hardware elements may 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 cells, logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software elements may 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, processes, software interfaces, application program interfaces (APIs), instruction sets, computing codes, computer codes, 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 may vary depending on many factors, such as desired computing rates, power levels, thermal tolerances, processing cycle budgets, input data rates, output data rates, memory resources, data bus speeds, and other design or performance constraints desired for a given implementation.

[0383] The components and features of the above-described devices may be implemented using any combination of discrete circuits, application specific integrated circuits (ASICs), logic gates, and / or single chip architectures. In addition, where appropriate, features of the devices may be implemented using microcontrollers, programmable logic arrays, and / or microprocessors, or any combination of the above. It should be noted that hardware, firmware, and / or software elements may be collectively or individually referred to herein as "logic" or "circuitry."

[0384] Fig.21 2 is a block diagram depicting an exemplary communication architecture 2100 suitable for implementing various embodiments as described above. The communication architecture 2100 includes various common communication elements, such as transmitters, receivers, transceivers, radios, network interfaces, baseband processors, antennas, amplifiers, filters, power supplies, etc. However, the embodiments are not limited to implementation by the communication architecture 2100, which can be consistent with the systems and devices discussed herein.

[0385] like Fig.21 As shown, the communication architecture 2100 includes one or more clients 2102 and one or more servers 2104. The one or more servers 2104 can implement one or more functions and embodiments discussed herein. The one or more clients 2102 and the one or more servers 2104 are operably connected to one or more corresponding client data stores 2106 and server data stores 2108, which can be used to store local information of the corresponding one or more clients 2102 and one or more servers 2104, such as network cookies and / or related context information.

[0386] One or more clients 2102 and one or more servers 2104 can communicate information between each other using a communication framework 2110. The communication framework 2110 can implement any well-known communication technologies and protocols. The communication framework 2110 can be implemented as a packet-switched network (e.g., a public network such as the Internet, a private network such as an intranet, etc.), a circuit-switched network (e.g., a public switched telephone network), or a combination of a packet-switched network and a circuit-switched network (with appropriate gateways and converters).

[0387] The communication framework 2110 can implement various network interfaces arranged to accept, communicate and connect to the communication network. The network interface can be regarded as a special form of input / output (I / O) interface. The network interface can adopt connection protocols, including but not limited to direct connection, Ethernet (e.g., thick, thin, twisted pair 10 / 100 / 1000Base T, etc.), token ring, wireless network interface, cellular network interface, IEEE 802.7ax network interface, IEEE 802.16 network interface, IEEE 802.20 network interface, etc. In addition, multiple network interfaces can be used to interact with various communication network types. For example, multiple network interfaces can be used to allow communication through broadcast, multicast and unicast networks. If the processing request requires higher speed and capacity, a distributed network controller architecture can be similarly adopted to aggregate, load balance and otherwise increase the communication bandwidth required by one or more clients 2102 and one or more servers 2104. The communication network can be any type and combination of wired and / or wireless networks, including but not limited to direct interconnections, secure custom connections, private networks (e.g., corporate intranets), public networks (e.g., the Internet), personal area networks (PANs), local area networks (LANs), metropolitan area networks (MANs), operating missions as nodes on the Internet (OMNI), wide area networks (WANs), wireless networks, cellular networks, and other communication networks.< / readeriduuid> < / merchantiduuid> < / uuid> < / jwt> < / puid> < / functiontos> < / nonce> < / functionrequest> < / nonce>

Claims

1. A computer-implemented method comprising: receiving, by a node in the system, from a client device, a request to establish a session to perform a function, wherein the function is performed at least in part using a contactless card; generating, by the node, session information corresponding to a session for performing the function, wherein the session information includes a random number and a signed session token; The node sends the session information to the client device; receiving, by the node via the client device, a message from the contactless card; extracting, by the node, a card issuer identifier from the message, the card issuer identifier being associated with the card issuer of the contactless card; identifying, by the node, a device associated with the issuer identifier; and The node communicates with the device to securely perform the function.

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

3. The computer-implemented method of claim 1, wherein the signed session is a JavaScript Object Notation (JSON) Web Token (JWT).

4. The computer-implemented method of claim 1 , wherein: The signed session token includes the random number, client session information, and a function request with the private key of the node.

5. The computer-implemented method of claim 4, wherein the client session information includes session identification information identifying the session.

6. The computer-implemented method of claim 1, wherein the session information further includes a feature terms of service and a terms of service version.

7. The computer-implemented method of claim 6, comprising receiving, from the client device, an assent date to the feature terms of service and the terms of service version.

8. The computer-implemented method of claim 1, wherein the node is located in a region that is mapped to a time zone of the client device.

9. The computer-implemented method of claim 1, wherein the message includes the issuer identifier, an issuer key identifier (pKey ID), a card unique identifier (pUID), a random number, and a password.

10. The computer-implemented method of claim 1, wherein the issuer identifier is in clear text and identifies an issuer of the contactless card, a device associated with the issuer of the contactless card, or both.

11. A computing device comprising: processor; and a memory storing instructions that, when executed by the processor, cause the processor to: receiving, from a client device, a request to establish a session to perform a function, wherein the function is performed at least in part using a contactless card; generating session information corresponding to a session for performing the function, wherein the session information includes a random number and a signed session token; sending the session information to the client device; receiving a message from the contactless card via the client device; extracting a card issuer identifier from the message, the card issuer identifier being associated with the card issuer of the contactless card; identifying a device associated with a card issuer identifier; as well as Communicate with the device to securely perform the function.

12. The computing device of claim 11, comprising further instructions that, when executed by the processor, cause the processor to verify the signed session token prior to extracting the issuer identifier from the message.

13. The computing device of claim 11, wherein: The signed session is a JavaScript Object Notation (JSON) Web Token (JWT).

14. The computing device of claim 11, wherein: The signed session token includes the random number, client session information, and the function request with the private key of the node.

15. The computing device of claim 14, wherein: The client session information includes session identification information identifying the session.

16. The computing device of claim 11, wherein: The session information also includes the feature service terms and service terms version.

17. The computing apparatus of claim 16, comprising receiving, from the client device, an assent date to the functional terms of service and the terms of service version.

18. The computing device of claim 11, wherein the node is located in a region that is mapped to a time zone of the client device.

19. The computing device of claim 11, wherein: The message includes the card issuer identifier, the card issuer key identifier (pKey ID), the card unique identifier (pUID), a random number and a password.

20. The computing device of claim 11, wherein: The issuer identifier is in plain text and identifies an issuer of the contactless card, a device associated with the issuer of the contactless card, or both.

Images