Techniques for handling contactless card functionality in multi-bank system environment

Abstract

A system and technique for performing functions within a multi-bank system using switch routing. 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, where the function is performed at least in part with a contactless card; generating, by the node, session information corresponding to a session for executing a function, wherein the session information comprises a nonce and a signed session token; sending, by the node, the session information to the client device; receiving, by the node, a message from the contactless card via the client device; extracting, by the node, an issuer identifier from the message, the issuer identifier being associated with an issuer of the contactless card; identifying, by the node, a device associated with the issuer identifier; and communicating, by the node, with the device to securely perform the function.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Patent Application No. 18 / 221,704, filed on July 13, 2023, which is a continuation-in-part of U.S. Patent Application No. 18 / 207,831, filed on June 9, 2023, which claims priority to U.S. Provisional Patent Application No. 63 / 405,749, filed on September 12, 2022, the disclosure of which is incorporated herein in its entirety. This application also claims priority to U.S. Provisional Patent Application No. 63 / 388,859, filed on July 13, 2022, the disclosure of which is incorporated herein in its entirety. Technical Field

[0003] The present disclosure generally relates to techniques for processing contactless card functions in a multi-bank system. Background Art

[0004] Contactless card products have become so well known and ubiquitous that they have fundamentally changed the way financial transactions and business processes are viewed and conducted in today's society. Contactless card products are most commonly made of plastic or metal card-like components issued and provided to customers by credit card issuers (such as banks and other financial institutions). Using the card, authorized customers or cardholders can purchase services and / or goods without the immediate and direct exchange of cash. Data security and transaction integrity are critical to businesses and customers who facilitate these transactions. As electronic transactions performed using contactless cards account for an increasing share of commercial activities, this demand is also growing. Therefore, it is urgent 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

[0005] 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 non-repeating random value (nonce) used only once and a signed session token; sending, by the node, the session information to the client device; receiving, by the node, a message from the contactless card via the client device; extracting, by the node, an issuer identifier from the message, the issuer identifier being associated with an issuer of the contactless card; identifying, by the node, a device associated with the issuer identifier; and communicating, by the node with the device to securely perform the function.

[0006] In one aspect, a computing device includes a processor. The computing device also includes a memory storing instructions, which, 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 nonce and a signed session token; send the session information to the client device; receive a message from the contactless card via the client device; extract an issuer identifier from the message, 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.

[0007] 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 nonce and a signed session token; send the session information to the client device; receive a message from the contactless card via the client device; extract an issuer identifier from the message, 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.

[0008] In one aspect, a computer-implemented method includes: reading, by a computing device, a contactless card after the contactless card enters a communication field; selecting, by the computing device, an applet stored in a memory of the contactless card based on the reading of the contactless card; transmitting, by the computing device, a first command to the contactless card; and transmitting, by the computing device, a second command to the contactless card.

[0009] In one aspect, a computing system includes a computing device including a processor and a memory. The memory of the computing device stores instructions that, when executed by the processor, cause the processor to: read a contactless card after the contactless card enters a communication field; select an applet stored in the memory of the contactless card based on the reading of the contactless card; transmit a first command to the contactless card; and transmit a second command to the contactless card.

[0010] In one aspect, a non-transitory computer-readable storage medium stores instructions that, when executed by a computing device, cause the computing device to perform a process. The process includes: reading a contactless card after the contactless card enters a communication field; selecting an applet stored in a memory of the contactless card based on the reading of the contactless card; transmitting a first command to the contactless card; and transmitting a second command to the contactless card. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] To facilitate identification of the discussion of any particular element or action, the most significant digit(s) in a reference number refers to the reference numeral that first introduces that element.

[0012] Figure 1 An example of a system 100 according to an embodiment is shown.

[0013] Figure 2 An example of a system 200 configured to operate in accordance with an embodiment is shown.

[0014] Figure 3 is an example of a sequence 300 according to an embodiment.

[0015] FIG. 4A to FIG. 4C is an example of a sequence 400 according to an embodiment.

[0016] Figure 5 An example of a routine 500 is shown in accordance with an embodiment.

[0017] Figure 6 An example of a message 600 is shown according to an embodiment.

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

[0019] Fig. 8A and Figure 8B An example of a system 800 is shown in accordance with an embodiment.

[0020] Fig. 9 An example of a contactless card 102 according to an embodiment is shown.

[0021] Fig.10 An example of a contactless card component 1000 according to one embodiment is shown.

[0022] Fig.11 An example of a sequence flow 1100 is shown according to an embodiment.

[0023] Fig.12 An example of a routine 1200 is shown according to an embodiment.

[0024] Fig.13AAn example of a system 1304 is shown in accordance with an embodiment.

[0025] Fig. 13B An example of a system 1304 is shown in accordance with an embodiment.

[0026] Fig.14 An example of a sequence 1400 is shown according to an embodiment.

[0027] Fig.15 An example of a routine 1500 is shown according to one embodiment.

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

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

[0030] Fig.18 An example of a sequence 1800 is shown, according to an embodiment.

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

[0032] Fig. 20 An example of a routine 2000 is shown according to an embodiment.

[0033] Fig.21 An example of a routine 2100 is shown according to an embodiment.

[0034] Fig. 22 An example of a computer architecture 2200 is shown according to an embodiment.

[0035] Fig.23 An example of a communication architecture 2300 is shown according to an embodiment. DETAILED DESCRIPTION

[0036] Exemplary embodiments of the invention will now be described in order to illustrate the various features of the invention. The embodiments described herein are not intended to be limiting as to the scope of the invention, but are intended to provide examples of the components, uses, and operations of the invention.

[0037] In addition, the described features, advantages and characteristics of the exemplary embodiments may be combined in any suitable manner. Those skilled in the relevant art will recognize that an embodiment may be implemented without one or more specific features or advantages of the embodiment. In other examples, additional features and advantages may be recognized in certain embodiments, and these features and advantages may not be present in all embodiments. Those skilled in the relevant art will understand that the described features, advantages and characteristics of any embodiment can be combined interchangeably with the features, advantages and characteristics of any other embodiment.

[0038] Embodiments are generally directed to enabling contactless card functionality in a multi-issuer computing environment. These functions may include tap-to functionality, where a user may tap their contactless card against a device, such as a mobile device, to perform a function. For example, a user may utilize their contactless card to verify their identity, perform a payment, launch an application, log into an application, automatically fill in a form or field, navigate to a specified network location or app on a device, unlock a door, initiate a contactless card, and the like.

[0039] The system discussed herein can enable users to perform these functions in a multi-issuer environment. Further, the system discussed herein enables card issuers (such as banks) to issue contactless cards with a tap 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 issuers or banks to provide tap functionality. Traditionally, each issuer or bank needs to establish and maintain their own system to provide contactless card features. This feature includes maintaining their own hardware, software, databases, security protocols, etc., which may become extremely expensive for issuers or banks to maintain. However, the embodiment discussed enables issuers or banks to offload most of the processing, storage and security functionality 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 issuers while maintaining a high level of security and data integrity. The functionality and data of each issuer can be managed and protected separately so that another issuer or bank cannot access the data or functions of another issuer. As will be discussed in more detail, these features can be provided by a switchboard system configured to process and execute each contactless card function in a secure manner. Additional benefits for issuers can include providing highly secure authentication options for mobile networks that typically lack robust authentication options available in native applications.

[0040] Further, the embodiments discussed herein utilize App and SDK supports two major mobile platforms A tap mobile web experience on . An embodiment includes providing a touch 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 app or a web browser app, and includes App Supported. SDK provides near field communication between mobile devices and contactless smart cards via App The SDK can be configured to install native apps, as well as hide data and / or display parts. App Store) to download and install the app.

[0041] exist In an operating system environment, embodiments include utilizing 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 app. The JavaScript SDK also includes support for The JavaScript SDK can also include functions for providing customizable user interface (UI) functions and obfuscation. In an embodiment, the JavaScript SDK supports websites that utilize the secure hypertext transfer protocol (HTTPS) and supports Libraries. Embodiments are not limited in this manner, and UI libraries may be supported. Embodiments also include utilizing native Android SDKs, which can be implemented in applications on a device (e.g., a mobile device). The Android SDK can help applications and / or websites communicate wirelessly with devices such as contactless cards via a web browser. The Android SDK also enables applications or web browsers to communicate and utilize other basic Android services, such as operating systems and low-level services. Embodiments are not limited to these examples.

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

[0043] For another example, the personalization of the card can be decoupled from the authentication of the card, which advantageously allows multiple entities to perform authentication securely and consistently without unnecessary exchange of sensitive data. In some examples described herein, the decoupling of card personalization from authentication can be achieved by adding a key identifier to the data payload communicated between the card and various other devices (e.g., client devices and / or servers). In other examples described herein, the decoupling of card personalization from authentication can be achieved by deriving a shared secret from a master key. In still other examples described herein, the decoupling of card personalization from authentication can be achieved by avoiding the use of a permanent account number (PAN) serial number (PSN) for key derivation.

[0044] For another example, a challenge can be incorporated to advantageously avoid or reduce the risk of pre-play and / or replay attacks. In some examples, a challenge can be generated and linked to a session and then written to the card. The challenge can be used to generate encrypted data (such as a password), and session verification can be added to the verification logic.

[0045] Also for example, additional improvements can be made to data security, authentication and verification. For example, the NFC specification, dormant applet, signed hashes of card product customer identifiers, centralized authenticators and general cryptography can be used advantageously.

[0046] All of the foregoing examples provide many advantages regarding data security, authentication and verification for contactless cards. It should be understood that these and additional advantages may be achieved by a combination of one or more of the foregoing examples.

[0047] 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 a program process 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 sequence of operations that leads to a desired result. These operations are those that require physical manipulation of physical quantities. Typically, 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, these signals are sometimes referred to as bits, values, elements, symbols, characters, items, numbers or the like, which have proven to be convenient. 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 those quantities.

[0048] Further, these manipulations are often referred to in terms such as addition or comparison, which are usually associated with mental operations performed by a human operator. However, in any operation that constitutes part of one or more embodiments described herein, such ability of a human operator is not necessary, or is not desirable in most cases. On the contrary, 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 written according to the teachings herein and / or include devices specially constructed for the desired purpose or digital computers. Various embodiments also relate to devices or systems for performing these operations. These devices can be specially constructed for the desired purpose. The structure required for a variety of these machines will be apparent from the description given.

[0049] 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 can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to facilitate their description. It is intended to cover all modifications, equivalents, and substitutes within the scope of the claims.

[0050] 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 enable functions performed using 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 authentication of a user and tap functions. The tap 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 tap operations.

[0051] System 100 shows a high-level configuration that enables multiple users to use contactless cards issued by one or more issuers to perform operations, including transactions with merchant systems. In the example shown, system 100 includes multiple bank systems 106a, retailer systems 106b, other financial systems 106c, and government systems 106d. These transaction systems can be configured for 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.

[0052] The system 100 may be configured to perform various operations for customers, issuing banks, merchants, etc. These operations may be initiated by a customer using a contactless card, resulting in the exchange of information between the contactless card 102 and other systems of the system 100. Depending on those operations 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 the system 100 to perform their respective operations.

[0053] For example, contactless card 102 can initiate a transaction with one of the merchant systems when tapped on another device (such as mobile device 104), which can also be configured to communicate with one of the other systems (such as an escrow service). 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 tap functions.

[0054] As will be discussed in greater detail, the mobile device 104 can communicate data from the contactless card 102 to another system, such as one or more of the systems 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 switchboard system 108, as will be discussed herein. In an embodiment, the data can be provided in a password.

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

[0056] For example, a customer may wish to perform a transaction for a good or service (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 a switchboard 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 an issuing bank system function to process the transaction, and the unencrypted portion may include data that may be used by the switchboard system 108 to route messages and data to the correct issuing bank system function via an application programming interface and services (such as business services). The switchboard 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, business services, and merchant systems, and enable the transaction to be performed in a secure manner.

[0057] In an embodiment, the switching station system 108 may also include a management service that can be used to onboard card issuers, validators, and merchants to the system to provide contactless card services. In one example, the switching station 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 the unique identifier on each contactless card to provide during transactions and other operations.

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

[0059] In an embodiment, the system 100 may also perform onboarding operations to onboard merchants and merchant systems to operate with the switchboard system 108 environment. In an embodiment, onboarding a merchant may include generating a unique identifier associated with the merchant and providing the unique identifier to the merchant, such as issuing a merchant certificate. The system 100 may also enable merchants and issuers to exchange data, such as key pairs, to perform operations securely without revealing sensitive data to the switchboard 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.

[0060] The system 100 may also perform onboarding operations for card issuers. For example, the system 100 may enable a bank or card issuer to generate a unique identifier, such as 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 issuer to generate and / or distribute key pairs with merchants and other service providers. These and other details will be described in the following description.

[0061] Figure 2 An example of a system 200 according to the embodiments discussed herein is shown. The system 200 includes additional devices and systems that are configured to enable contactless card issuers to provide tap card services. In particular, the system 200 enables any number of issuer systems to provide card services to their customers through the switching fabric (i.e., the switching station system 108) in a safe and secure manner.

[0062] In an embodiment, the switching station system 108 includes one or more nodes 204 configured to perform routing operations. Each switching station node 204 may include a session and nonce generator 206, a message router 208, an authentication 210, an operation data storage 212, and an index storage 214. Further, each of the nodes may be configured to be identical and share configurations, but each switching node 204 may independently process messages and requests and route them to appropriate systems, such as merchant systems and publisher systems. Each of the nodes 204 is configured to act as a trust agent (broker) between, for example, a publisher system, a merchant system 222, and / or a verification system 224. Each switching station node 204 is configured to route each message to a correct publisher system while maintaining data security. For example, a switching station node 204 may route messages between a publisher system and a merchant system, and the node may not obtain access to private data in the message.

[0063] The switchboard system 108 can be configured as a server system, including a collection of hardware, software and 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 those executable on each of the nodes 204. In some instances, each of the server computers can be configured to operate one or more nodes, for example, in a virtual environment. The storage devices are configured to store data accessed by the applications, and the network adapters are used to connect the server computers to the network.

[0064] Each of the server computers can be configured to execute software, including operating systems, 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.

[0065] In some embodiments, node 204 can operate in a cloud-based computing environment, such as enabling the collection of hardware, software and networking components that can deliver cloud computing services. Switchboard node 204 and computing services are delivered via the Internet, and they can be accessed from anywhere in the world using an Internet connection. In an embodiment, client 236 can access switchboard node 204 via domain name system 202 or domain name system (DNS). DNS 202 is a hierarchical and distributed naming system for computers, services and other resources connected to the Internet or other networks. It associates various information with the domain name assigned to each registered participant. In one example, DNS 202 can convert the name known to the software executed on client 236, to route data to one or more switchboard nodes 204 of switchboard system 108. In an embodiment, DNS 202 can be generated as a number, such as an Internet Protocol (IP) address, an address record (A-record) or another host name (C-name record). Figure 3 An example sequence 300 of a user client identifying and resolving an identifier of one of the nodes 204 of the switching station system 108 is shown. At a high level, the domain name system 202 translates known domain names into numeric Internet Protocol (IP) addresses required to locate and identify computer services and devices with underlying network protocols. Clients use the global DNS system to select the best node to use, as discussed in sequence 300.

[0066] 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 function 210 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:

[0067] A CLIENT API KEY can have the following example structure:

[0068] 65535-GReyx5BuEAaE72bWbFZJfHRL8Dbt1Uum, where Table 1 describes the value, name, and meaning:

[0069]

[0070] Table 1

[0071] The switch node 204 may authorize or authenticate the client sdk 236 or the user, and the switch node 204 may utilize additional components such as the session and nonce generator 206 and the message router 208 to perform operations such as FIG. 4A to FIG. 4C As discussed. Note that the validator verification system 224 never interacts with the merchant system 222 and vice versa. The node 204 proxies all communications.

[0072] In an embodiment, the exchange system 108 can utilize Hyperledger Fabric 220 to manage synchronization of shared operational data 212 and membership management across the network. Hyperledger Fabric 220 is a distributed ledger framework with a permissioned network model, where only authorized parties can join the network and access data stored on the ledger.

[0073] In an embodiment, Hyperledger Fabric 220 can be generated by creating one or more peer sets, ordering services, and channels. Once the network is created, the system 200 deploys the chain code to the network or node 204 that has permission to access the Fabric. Chain code is code that runs on the blockchain and executes network control 226 and operational data 212 logic code. Once the chain code is deployed, each of the exchange nodes 204 is configured to call transactions on the blockchain to add data (e.g., operational data) to the blockchain. The exchange 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.

[0074] All nodes 204 maintain independently verifiable logs of their actions, which can be transmitted to a centralized aggregator to build a complete 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, which is aggregated and abstracted to the appropriate level.

[0075] Figure 3 An example sequence 300 is shown for a client to utilize DNS to resolve and communicate with one or more nodes of 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 switch to a default DNS server. {domain}.{tld}.text records may be preconfigured in the client app and / or client sdk. At 304, the DNS 202 returns one or more records. The DNS record structure may include the following:

[0076] ●Root Record:

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

[0078] ○Type: TXT

[0079] ○Analysis:

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

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

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

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

[0084] ■* etc.

[0085] ○Purpose: Determine where active nodes exist

[0086] ●Node record:

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

[0088] ○ Type: A / AAAA or CNAME

[0089] ○ Resolution: actual node host name or IP

[0090] ○Purpose: Communicate with nodes

[0091] In an embodiment, the client 236 may determine the current time zone at 306. For example, the client app or SDK may utilize a get current timezone function, such as in JavaScript:

[0092] Intl.DateTimeFormat().resolvedOptions().timeZone). Embodiments are not limited in this manner, and the app or SDK may determine the time zone via another / different function call. At 308, the client 236 is configured to map the time zone to a region or a 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 zone mappings to regions:

[0093]

[0094] Table 2

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

[0096] At 310, the client may identify or select the DNS record option returned at 304 that is located in the zone. If there are multiple matches, the client may randomly select one. 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 the node is available. For example, sa has no node, but is connected to na-e where a node exists, and therefore na-e is selected. In some embodiments.

[0097] 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. And at 318, the client 236 can communicate with the switch node 204 and begin the process of interacting with the switch.

[0098] FIG. 4A to FIG. 4C An example sequence 400 for performing operations between a contactless card and services provided by a card issuer and / or merchant is shown. The illustrated sequence 400 includes actions and communications performed by the contactless card 102, the client sdk 236 including the client app and the client sdk, the domain name system 202, the switching station system 108, the partner services 232 including merchants and / or validators, and the control service 234 including a client server or system.

[0099] In an embodiment, at 402, the client sdk 236 including the client app can send a request and establish a session with the client server 484 so 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 publisher 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, CLIENT SESSION INFORMATION can be user session identification information specific to the client implementation.

[0100] At 408, the client sdk 236 may initiate a contactless card authentication process with the client sdk 236. 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 to 414, the client may utilize DNS to identify a node and establish communication with the node. In particular, 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 a switch node to communicate with. Figure 3 An example of a more detailed sequence of procedures for establishing communications with a switching station node is shown.

[0101] At 416, the client sdk 236 may send a request for a session to the switch system 108. In an embodiment, the request for a session may be in the format of<FUNCTION REQUEST> In an embodiment, the FUNCTIONREQUEST may be data / function that the customer would like to request once the contactless card has been verified. The function may be used for any of the services discussed herein, such as authenticating a user, performing a transaction, requesting automatic filling of data, etc. At 418, the switching station system 108 may generate a nonce 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:

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

[0103] ●nonce: 8 hexadecimal characters, randomly generated nonce,

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

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

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

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

[0108] ●Scope: The function requested to be performed.

[0109] A nonce can be a unique random byte that is generated to ensure non-repeatability of messages with contactless cards. The nonce is critical to the security and operation of the exchange system. The validity of the nonce is tracked by binding it to a session that can be verified by any member of the platform. As mentioned, a session is a JSON Web Token signed using a node-specific private key issued by the network. These JWTs can be verified by systems with the corresponding public key, they can also be verified by confirming that the public key was issued by us or an approved principal. A signed session token is a token generated by a JWT to establish the validity and expiration of the nonce, as well as to associate the contactless card tap with the current customer session. For example, a signed session token includes <nonce>,<CLIENT SESSION INFO> And use<NODE PRIVATE KEY> Signed<FUNCTION REQUEST> , where NODE PRIVATE KEY is the private key of the switching station system 108. The switching station system 108 may include a NODE PUBLIC / PRIVATE KEY, which is a key pair used to sign and verify the JWT.

[0110] In an embodiment, the switching station system 108 can use a nonce as a challenge to avoid or reduce the risk of pre-play and / or replay attacks. For example, the contactless card 102 can transmit data communications via, for example, NFC, and such communications can be intercepted by other readers (e.g., NFC readers) and replayed at a later time to circumvent security requirements. This can be counteracted by tying the transmissions made by the contactless card (e.g., a password) to a session time (e.g., time and / or device).

[0111] At 420, the switching station system 108 may return session information to the client sdk 236. The session information may include a signed session token (<SIGNED SESSION TOKEN> ), nonce <nonce>, Functional Service Terms<FUNCTION TOS> , and the Terms of Service version<TOS VERSION> FUNCTION TOS may be the terms of service that the user must agree to in order to allow the client to perform the requested function, and TOS VERSION may be the 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 uses<TOS VERSION> exist<CONSENT DATE> Capture and record<FUNCTION TOS> CONSENT DATE can be a timestamp for when the user agreed to the TOS.

[0112] 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 for use during the session to perform functions. 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 NONCE 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.

[0113]

[0114]

[0115] In an embodiment, the updated MAC may be calculated to protect the control indicator. Specifically, MAC M is determined by calculating the MAC within the 10-byte update data U using the updated MAC card key (MCK) as follows:

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

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

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

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

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

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

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

[0123] At 424, the contactless card may generate a message and provide it to a client device including the client sdk 236. The data in the message may be utilized by the systems discussed herein to perform the requested function. Figure 5 An example of such a message, message 600, is shown and discussed in FIG.

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

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

[0126] In an embodiment, the switchboard system 108 is configured to generate secure communications and communicate with the issuer system (e.g., the client server 484 and the authenticator 488). At 432, the switchboard system 108 sends a request for a key 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. Embodiments are not limited in this manner, and alternative key protocols can be utilized, such as super singular isotopic Diffie-Hellman key exchange (SIDH or SIKE), private key / public key pairing (RSA), etc.

[0127] At 434, the client server 484 generates a portion of the key. In some examples, the client server 484 may generate half of an ECDH key for encryption / decryption of the PII. In particular, the client server 484 may use elliptic curve P256 to generate<CLIENT EC PUBLIC KEY> and

[0128] <CLIENT EC PRIVATE KEY> CLIENT EC PUBLIC KEY and CLIENT EC PRIVATE KEY are the first half of ECDH key negotiation.

[0129] At 436, the client server 484 stores the generated key portion in memory. In particular, the client server 484 may store a key portion 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 ephemeral EC public / private key for subsequent ECDH key completion, e.g., to identify the ECDH key portion to generate the entire ECDH key. In one example, the key may be stored in a secure memory location and may be used to determine when PII is received for a session.

[0130] In an embodiment, the client server 484 may return the public key portion with the KEY ID to the switching station system 108 at 438. The switching station system 108 may store the public key portion with the KEY ID for later use, such as generation of ECDH keys. At 440, the switching station system 108 may request verification to be performed by the verifier 488. In one example, the switching station system 108 may request verification as a request for verification. <message>,<SIGNED SESSION TOKEN> ,<CLIENT ECPUBLIC KEY> ,<CONSENT DATE> as well as<TOS VERSION> At 442, the authenticator 488 may make an out-of-band request back to the switch system 108 for a public key authentication session. At 444, the switch system 108 may provide the node's public key, i.e.<NODE PUBLIC KEY> Further, at 446, the verifier 488 may utilize the node's public key to verify the secure session token.

[0131] In an embodiment, the verifier 488 may verify the message at 448. In an embodiment, the verifier 488 may perform multiple verifications, including ensuring that the nonce in the message is correct along with additional information such as the card's unique identifier (pUID) and the counter value (pATC). Fig.13A and Fig. 13B Additional details of the validation process that can be performed are discussed.

[0132] 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>Validator 488 may also generate another portion of the key, such as an ECDH key. For example, validator 488 may use elliptic curve P256 to generate<ISSUER EC PUBLIC KEY> and<ISSUER EC PRIVATE KEY> ISSUER EC PUBLIC KEY and ISSUER ECPRIVATE KEY can be the second half of ECDH key negotiation.

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

[0134] Validator 488 may utilize the ECDH KEY to encrypt data for the function. For example, and in some instances, if validator 488 validates the message, validator 488 may execute the function request to create a function result, and encrypt the result using the ECDH key at 456. For example, validator 488 may execute<FUNCTION REQUEST> To create<FUNCTION RESULT> , and use<ECDH KEY> It is encrypted. The function result can be any result based on the requested function (such as verification of a card).

[0135] At 458, the validator 488 may return the function result to the switch system 108. In some instances, the returned function result is encrypted. For example, the validator 488 may return<ENCRYPTED FUNCTION RESULT> and<ISSUEREC PUBLIC KEY> .

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

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

[0138] In an embodiment, at 478, the switchboard system 108 may return the result of the function to the client sdk 492 whether it was completed successfully. Further, at 480, the client sdk 492 may notify the client app 490 of the result. At 482, the client app 490 may utilize the feature. For example, 482 may communicate with the client server 484 to use<CLIENTSESSION INFO> To extract the edited<FUNCTION RESULT> And continue with this feature.

[0139] In an embodiment, the switching station system 108 can generate a nonce used as a challenge and link the challenge to the session. The challenge can be written to the contactless card 102 (e.g., written to a small application contained in the memory of the contactless card) and can be used by the contactless card in generating and / or calculating a password as described herein. In addition, session verification can be added to the verification logic as part of the verification described herein.

[0140] The use of challenges can provide many advantages, including greatly improved security and the benefits of reducing false positives based on counter values ​​(pATC) problems. In an embodiment, the write challenge can be implemented by changing the configuration of the contactless card. For example, a contactless card (e.g., a small application included in the memory of the contactless card) can be provided with a new internal record, including a new configuration file. The contactless card can be configured to support optional WRITE BINARY and / or UPDATE BINARY to facilitate the transmission of the challenge to the card. The contactless card can be configured to support processes including and excluding the process of the challenge. In addition, the cryptographic method utilized by the contactless card can be configured to support processes including and excluding the process of the challenge.

[0141] In an embodiment, the write challenge can be implemented by changing the configuration of one or more SDKs used by the systems and methods described herein (including by contactless cards, client devices, servers, and other network-enabled computers). For example, the SDK can be updated to implement NDEF reading at the application protocol data unit (APDU) level. The SDK can be updated to determine the process flow by querying the applet function file. In addition, the SDK can be updated to request a challenge to the authenticator.

[0142] In an embodiment, the write challenge can be implemented by changing the configuration of the authenticator. For example, the authenticator can be updated to support the generation and provision of the challenge. The authenticator can be updated to support the generation and configuration of the session. In addition, the verifiability can be updated to support the verification strategy based on the version number (including but not limited to the applet and / or software version number).

[0143] Figure 5 An example of a routine 500 according to embodiments discussed herein is shown. For example, the routine 500 can be performed by the devices and systems described herein, including but not limited to: mobile device 104, client app 490, issuer system 802, personalization system 804, contactless card 102, client device, software development kit (SDK), POS terminal, and personal computer.

[0144] In block 502, an NDEF read may be performed on the contactless card 102. The NDEF read may be performed after the contactless card 102 enters the NFC field of a device (such as the mobile device 104).

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

[0146] In block 506, a capabilities container associated with the selected applet may be read to collect information related to the container and the applet. The collected information may include, but is not limited to, container size, number of files stored in the container, file size of files stored in the container, file names of files stored in the container, read status of files stored in the container, and write status of files stored in the container.

[0147] In block 508, a custom command may be executed. For example, the custom command may be transmitted to the contactless card 102 and may include data and one or more instructions. The custom command may be used to update one or more of the selected applet, function container, and file within the container. For example, the custom command may update the file to include a nonce. For another example, the custom command may be a WRITE BINARY command. For another example, the custom command may be: a command for changing the state of a small application on the contactless card 102 (e.g., a change from a dormant state to an active state, a change from a locked state to an unlocked state, a change from a deactivated state to an activated state; a change from a first version to a second version); a command for changing the format of a message stored on or generated by the contactless card 102; a command for changing one or more parameters used for a calculation performed by the contactless card; a command for changing the form of an authentication operation used by the contactless card 102 (e.g., a cryptographic MAC operation, a signed message with a public key certificate); and / or a command for transmitting one or more certificates (e.g., a digital certificate, such as a public key certificate, a code signing certificate, a client certificate, a user certificate). It should be understood that the custom command may be other commands and instructions, and the custom command is not limited to these examples.

[0148] In block 510, a second command may be given, and a password may be calculated in response to the second command. The password may be calculated according to the embodiments described herein, and the nonce may be used in the calculation of the password. In an embodiment, the second command may be a READ BINARY command. In an embodiment, the second command may indicate that the nonce is used in the calculation of the password.

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

[0150] In an embodiment, message 600 includes applet version 602 field, issuer autonomous indicator field 604, issuer identifier 606 field, pKey ID 608 field, pUID 610 field, pATC 612 field, nonce 614 field, and encrypted password 616 field.

[0151] In an embodiment, the field can be plain text or encrypted. For example, the applet version 602 field can include the applet version under plain text. The applet version is used to indicate which applet version is installed on the contactless card 102 and can be used by other systems to determine how to handle message 600 when communicating. For example, different applet versions require different verification logics, such as older messages can be routed through the issuer system to perform various operations for verification, and newer messages can be routed through the switchboard system to perform various operations including verification. For another example, different applet versions require different personalized logics.

[0152] In an embodiment, the message 600 includes an issuer autonomous indicator 604 field, which may include issuer data and is set at the time of personalization. In addition, the message 600 includes an issuer identifier 606 field, which may include a unique ID assigned to the entity that issued the card (e.g., an issuer or other entity associated with the contactless card). For example, each issuer may be assigned a unique identifier during an onboarding operation when joining the system. The issuer ID may be used by the switchboard system 108 to route the message and its contents to the appropriate service associated with that particular issuer.

[0153] In an embodiment, the message 600 includes a pKey ID 608 field. In some instances, the pKey ID 608 field may include data identifying a master key set for the card issuer. The issuer's master key set may utilize a derived master key or a unique derived key (UDK) set for each card. Further, each card's own master key (UDK) set may be generated during the personalization of the card. 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) that utilizes the pKeyID to identify the issuer's master key to regenerate the session key by the system to perform authentication.

[0154] In an embodiment, each contactless card 102 is given a unique 16-digit decimal digital identity (pUID) when personalized. The derivation of the unique key for the card applet using the pUID is performed off-card. The resulting application key is injected during the personalization of the card. In an embodiment, the application key of the card is the same as the derived master key or UDK of the card. The process for deriving the application key (UDK) is as follows:

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

[0156] 2. For each card application:

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

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

[0159] 3. For each application key (UDK), create the diversified data as follows:

[0160] 1. Create a 16-bit quantity X from the 16-bit pUID

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

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

[0163] 2. Calculate ZR by XORing X with FFFFFFFFFFFFFFFF and then encrypting the result using the issuer master key.

[0164] 3. Concatenate ZL and ZR to form the application key (UDK key).

[0165] In embodiments, the key derivation process may avoid, or stop using, the PSN. In these embodiments, the need to look up the PSN from a database in order to generate the UDK is eliminated. This results in avoiding reliance on a database and retrieval of information from a database. Thus, personalization and authentication of the device (e.g., card personalization and authentication) may be performed independently.

[0166] In embodiments where the diversified key can be derived from the master key using the 16 digits from the pUID (rather than being derived from the 14 digits from the pUID and the PSN), entropy is not reduced, and further, this change can favorably affect personalization, applets or other software, and authentication. For example, an encryption master key can be used with the 16 digits from the pUID to derive an encryption UDK. For another example, an authentication master key can be used with the 16 digits from the pUID to derive an authentication UDK.

[0167] Message 600 may include a pUID 610 field that includes a card unique identifier assigned to the contactless card at the time of personalization. The pUID 610 field data may be a combination of alphanumeric characters used to uniquely identify each card and associated with a user. In an embodiment, the pUID 610 field may include data related to the user associated with the contactless card and / or an account associated with the user.

[0168] In an embodiment, the inclusion of the pUID 610 field allows for namespaces specific to individual entities. That is, the pUID 610 field may include a namespace for either the issuing entity or the verifier entity to further decouple personalization from verification.

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

[0170] In an embodiment, each time a message 600 is created, a new session key is derived and used to generate one or more parts of the message 600. In particular, the session key is used to compute a cryptographic MAC (Application Cryptography).

[0171] The card applet supports an improved variant of the session key derivation option according to EMV 4.3 Book 2 Annex A1.3.1 to generate a unique cryptographic session key ASK as follows:

[0172] ● By encrypting [ATC[2]||ATC[3]||'F0'||'00'||[ATC[0]||[ATC[1]] using the application key

[0173] ||[ATC[2]||[ATC[3]] to calculate SKL

[0174] ● By encrypting [ATC[2]||ATC[3]||'0F'||'00'||[ATC[0]||[ATC[1]] using the application key

[0175] ||[ATC[2]||[ATC[3]] to calculate SKR

[0176] ● Concatenate SKL and SKR to form the authentication session key

[0177] The authentication session key is used to encrypt the cipher MAC.

[0178] The card applet also supports an improved variant of the session key derivation option according to EMV 4.3 Book 2 Annex A1.3.1 to generate a unique cryptographic session key DESK as follows:

[0179] ● By encrypting [ATC[2]||ATC[3]||'F0'||'00'||'00'||'00'||'00'] using the data encryption key

[0180] ||'00'] to calculate SKL

[0181] ● By encrypting [ATC[2]||ATC[3]||'0F'||'00'||'00'||'00'||]

[0182] '00'||'00'] to calculate SKR

[0183] ● Concatenate SKL and SKR to form a data encryption session key

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

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

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

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

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

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

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

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

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

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

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

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

[0196] Cryptographic encryption is performed using a Data Encipherment Session Key (DESK) which is used for encryption in Cipher Block Chaining (CBC) mode as follows.

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

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

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

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

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

[0202] Use decryption mode to recover:

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

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

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

[0206] In an embodiment, a portion of the data provided in message 600 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 a read operation is being performed). Note that in some instances, the static information may be updateable, but may require the customer and card to undergo a secure update process, which may be controlled by the issuer.

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

[0208] Wireless communication can be based on wireless protocols such as near field communication (NFC), Bluetooth, WiFi and the like. In some instances, messages can be communicated between contactless card 102 and the device via wired means (e.g., via contact pad 904) and according to EMV protocols.

[0209] Message 600 provides multiple benefits. For example, message 600 provides the data communication, data security, card authentication and verification benefits described herein. For another example, the inclusion of the issuer identifier 606 field allows message 600 to be routed to the appropriate issuing entity for verification (or if different from the issuing entity, to the appropriate verifying entity). This allows the issuing entity or the entity that performs personalization of the transmission device (e.g., when the transmission device is a contactless card, the contactless card issuing entity) to be decoupled from the validator entity. Therefore, any validator entity authorized to perform a validator, not just the issuing entity or the entity that performs personalization of the transmission device can be identified in the issuer identifier 606 field. In addition, such routing can be scalable across many messages, many issuing entities, and many validator entities.

[0210] As another example, the inclusion of pKey ID 608 may replace the requirement for a database lookup when a data payload is received. This supports decoupling authentication from the database and the requirement to access the database to perform authentication.

[0211] Figure 7 An example of a routine 700 according to embodiments discussed herein is shown. In block 702, the routine 700 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 performed at least in part using a contactless card. In some instances, the node may be one of a plurality of nodes of a switching station system. The node may have been previously selected by a sending device via a DNS operation performed.

[0212] In block 704, the routine 700 includes: generating, by the node, session information corresponding to a session for performing a function, wherein the session information includes a nonce and a signed session token. The nonce and / or the signed session token can be utilized by the system to perform the functions described herein while ensuring that the node for routing data is authenticated, messages from contactless cards are authenticated, and keeping track of sessions for the function.

[0213] In block 706, routine 700 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 examples, the client device may send a nonce from the node to the contactless card. When generating the message, the contactless card may utilize the nonce to communicate back to the client device and ultimately the node, for example, to incorporate it into an encrypted portion of the message (see Figure 6 ).

[0214] In block 708, the routine 700 receives, by the node, a message from a contactless card via a client device. The message may be generated by the contactless card. Figure 6 An example of message 600 is shown.

[0215] In block 710, the routine 700 extracts, by the node, an issuer identifier from the message, the issuer identifier being associated with an issuer of the contactless card. In some examples, the issuer identifier may be in a plain text format.

[0216] In block 712, the routine 700 identifies, by the node, a device associated with the publisher identifier. For example, the node may perform a lookup to determine a server associated with the publisher identifier and the function to be performed.

[0217] In block 714, the routine 700 communicates with the device by the node to securely perform the function.

[0218] Fig. 8A and Figure 8B An example of a system 800 configured according to the embodiments discussed herein is shown. In some instances, the system 800 may be a more detailed view of the system 100 and its components. The illustrated system 800 includes one or more systems to support processing transactions, performing verification functions, and other functions related to contactless cards issued in a multi-issuer environment. In an embodiment, the system 800 includes one or more issuer systems 202, a personalization system 804, one or more merchant systems 806, and a switchboard system 830. The switchboard system 830 may include additional systems that provide functionality to multiple issuer systems, which may include switchboard nodes configured to route messages and communicate with other systems.

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

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

[0221] In one example, to issue a card, the issuer system 802 may generate card unique identifiers (pUIDs), each of which may be associated with a cardholder and a contactless card when issued. For example, the pUIDs may be used as part of a verification process, and the issuer system 802 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 804 to physically generate and issue the contactless cards. In some instances, the pUIDs may be delivered to the personalization system 804 in a batch or batch file. For example, the issuer system 802 may include a process to generate a batch of pUIDs, and functionality to deliver the batch (e.g., an imprint file batch) to the personalization system 804. The personalization system 804 may be configured to physically generate and issue the contactless cards, as will be discussed in more detail below.

[0222] In some embodiments, the issuer system 802 may provide additional functionality. In some instances, the issuer system 802 may maintain at least a portion of the functionality to perform verification operations for a customer once a contactless card has been issued. For example, the issuer system 802 may include functions and APIs that a device such as a mobile device executing an issuer mobile app 810 may use to verify information initially received from a contactless card. The device may pass data from the contactless card to the issuer system 802 via one or more APIs (such as those provided by the MFA service 814), and the issuer system 802 may verify the information based on information stored in a database. The issuer system 802 may return the result to the device.

[0223] In some instances, publisher network 802 includes one or more commerce APIs configured to provide commerce services, such as providing PII during a transaction, providing PII to automatically fill out a form, providing a VCN to perform a transaction, or automatically fill out a form, etc. In some instances, these commerce APIs may be hosted outside of publisher network 802 by a third-party service, such as provided under service 834.

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

[0225] In an embodiment, the system 800 includes a personalization system 804 to perform operations on contactless cards so that they can be issued to customers. For example, the personalization system 804 can obtain and / or generate data that can be copied to each contactless card used for each customer. The data can be unique to each customer and include information such as account number, customer name, expiration date, card verification value (CVV), etc. In an embodiment, the personalization system 804 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 802 and / or service 834 so that they can perform contactless card operations such as verification, authentication, tapping, etc.

[0226] The personalization system 804 may also generate a unique key for each contactless card. 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 transfer data in a secure manner. The unique key for each card may be based on and / or associated with an issuer bank. In addition, the issuer system 802 and / or the switchboard system 830 may have a unique key set 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.

[0227] The personalization system 804 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 (including data for performing card verification and transactions). In some instances, the personalization system 804 may install applet programs to perform functions and include applet program version numbers. System versioning may be required so that other systems can operate accordingly. The system version specifies the applet program version to be embedded into the card by the personalization system 804 and the verification logic. For example, a first-party system may operate under version 0100, and the utilization 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.

[0228] The personalization system 804 may also include additional applets to perform additional functions. For example, each card may include an applet that is configured to communicate with other devices wired and / or wirelessly. In some instances, 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.

[0229] The system 800 also includes a switching station system 830 and a service system 834 to enable multiple banks or issuers to provide contactless card tap-to-go functionality, such as authentication, transactions, etc., while maintaining a high level of data security and separation between each issuer's data. For example, the switching station system 830 and the service system 834 provide a set of functions and APIs that are configured to provide services to multiple issuers to perform authentication, transactions, and other contactless card operations. In some examples, the switching station system 830 can be maintained and provided by a central system that is owned and operated by an entity separate from any card issuer.

[0230] In an embodiment, switchboard system 830 may include multiple components and systems, including routing services, workflow services, management services, authentication services, usage services, analytics services, and administration services 818 .

[0231] In an embodiment, the switching station system 830 and the service are configured to enable multiple issuers to operate together. For example, the switching station system 830 is configured to route messages and data from devices and contactless cards to corresponding services of card issuers, such as service 834. For example, Bank A may issue contactless cards and provide Service A, and the switching station system 830 is configured to process messages and data from the contactless cards issued by Bank A to Service A. In an embodiment, the switching station system 830 can use information in the messages and data to determine where to send them.

[0232] The switchboard system 830 and services also enable the merchant system 806 to process transactions for multiple different issuers. For example, the switchboard system 830 may include an API that can be used by a merchant backend to obtain PII associated with a cardholder to perform a transaction. The switchboard system 830 may also include an API configured to initiate a session, such as 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.

[0233] The switchboard system 830 also includes a verification function and a verification API, such as a verification service 820, to perform verification operations. The switchboard system 830 may also be coupled with a message verification service 824, which is configured to communicate with the verification function / API to provide a cryptographic verification service 826. The cryptographic verification service 826 includes a tap algorithm and is coupled with a verification HSM 828 to perform verification operations. The following description will discuss each of the APIs in more detail.

[0234] In an embodiment, the system 800 includes multiple systems to provide functionality and services using a contactless card. At least a portion of these services can be performed using 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 apps that can be configured to operate using the functions and APIs provided by the system 800. In one example, one or more apps can be developed using a software development kit (including instructions and functions that operate with the functions and APIs). Mobile apps can include publisher mobile apps 810 (such as bank apps) and merchant mobile apps 812. However, embodiments are not limited to this approach, and other applications such as web browsers, mini or micro applications (e.g., app clips), operating systems, etc. can be configured to operate and utilize the functionality provided by the system 800.

[0235] System 800 provides many benefits. For example, under certain exemplary applet or application versions, verification may require access to a database, and a new contactless card may be added to the database when personalized. In some examples, such as when the personalization and verification functions are performed by different actors and / or entities, this dependency between personalization and verification may be undesirable. Utilizing system 800, under other exemplary applet or application versions, verification does not require access to a database, but only uses data from a data payload and / or another message. In these embodiments, personalization and verification can be decoupled, and the dependency mentioned above can be eliminated.

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

[0237] Deriving a shared secret from a master key can yield several advantages, including that it can eliminate the need to store card-level secrets in a database. This can further eliminate the need to communicate shared secrets between devices (e.g., between a contactless card and a client device). Additionally, this can protect secrets in request data (e.g., contactless card request data) passed between devices.

[0238] In an embodiment, the shared secret can be derived from a third key. The third key can be a key previously used to perform operations relative to the contactless card and / or client device, or the third key can be a key that has not been previously used. In some examples, the shared secret can be personalized to the applet or other software application upon completion, which can result in avoiding the need to change the applet or other software application. The shared secret can be encrypted before including the contactless card to minimize exposure to potential attacks.

[0239] Thus, embodiments of system 800 have the benefits of personalization and authentication operating independently.

[0240] Fig. 9 An example configuration of a contactless card 102 according to embodiments discussed herein is shown. The contactless card 102 may include a contactless card, a payment card, such as a credit card, a debit card, or a gift card, issued by a service provider or issuer as displayed on the front or back of the contactless card 102 as a service provider mark 902. 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, the transaction card may include a dual-interface contactless payment card, a reward card, etc. The contactless card 102 may include a substrate 908, which 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 the contactless card 102 according to the present disclosure may have different characteristics, and the present disclosure does not require that the transaction card be implemented in a payment card.

[0241] The contactless card 102 may also include identification information 906 displayed on the front and / or back of the card and a contact pad 904. The contact pad 904 may include one or more pads and is configured to establish contact with another client device (such as an ATM, user device, smart phone, laptop, desktop, mobile device or tablet computer) via a transaction card. The contact pad may be designed according to one or more standards such as the ISO / IEC 7816 standard and enable communication 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.10 8. These components may be located behind the contact pad 904 or elsewhere on the substrate 908, such as in different layers of the substrate 908, and may be electrically and physically coupled to the contact pad 904. The contactless card 102 may also include a magnetic stripe or tape that may be located on the back of the card (not shown in FIG. 8). The contactless card 102 may also include a near-field communication (NFC) device coupled to an antenna that is capable of communicating via the NFC protocol. The embodiments are not limited in this manner.

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

[0243] Memory 1004 can be a read-only memory, a write-once read-many memory, or a read / write memory, such as RAM, ROM, and EEPROM, and contactless card 102 can include one or more of these memories. Read-only memory can be programmable by the manufacturer to be read-only or one-time programmable. One-time programmability provides the opportunity to write once and then read multiple times. Write-once / read-many memory can be programmed at a certain point in time after the memory chip has been shipped. Once the memory is programmed, it cannot be rewritten, but can be read multiple times. Read / write memory can be programmed and reprogrammed multiple times after shipping. Read / write memory can also be read multiple times after shipping. In some instances, memory 1004 can be an encrypted memory that utilizes an encryption algorithm executed by processor 1002 to encrypted data. In some embodiments, at least a portion of the memory can be implemented as a part of an HSM to store secret data, such as a master key of a card.

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

[0245] The one or more applets 1008 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 1008 is not limited to Java Card applet, but can be any software application that can operate on contactless card or other equipment with limited memory. One or more counters 1010 can include a digital counter that is sufficient to store integers. Customer identifier 1014 can include a unique alphanumeric identifier assigned to the user of contactless card 102, and the identifier can distinguish the contactless card user from other contactless card users. In some examples, customer identifier 1014 can identify both the customer and the account assigned to the customer, and can also identify the contactless card 102 associated with the customer account.

[0246] As previously described, the accounts 1012 may include thousands of one-time use virtual accounts associated with the contactless card 102. The applet 1008 of the contactless card 102 may be configured to manage the accounts 1012 (e.g., configured to select an account 1012, mark the selected account 1012 as used), and transmit the account 1012 to the mobile device for automatic filling by the auto-fill service.

[0247] The processor 1002 and memory elements of the aforementioned exemplary embodiments are described with reference to the contact pads, but the present disclosure is not limited thereto. It should be understood that these elements may be implemented outside the contact pads 904 or completely separated therefrom, or implemented as other elements other than the processor 1002 and memory 1004 elements located within the contact pads 904.

[0248] In some examples, contactless card 102 may include one or more antennas 1018. One or more antennas 1018 may be placed within contactless card 102 and around processing circuitry 1016 of contact pad 904. For example, one or more antennas 1018 may be integral with processing circuitry 1016, and one or more antennas 1018 may be used with an external booster coil. For another example, one or more antennas 1018 may be external to contact pad 904 and processing circuitry 1016.

[0249] In an embodiment, the coil of the contactless card 102 can act as the secondary coil of an air-core transformer. The terminal can communicate with the contactless card 102 by cutting off the power supply or amplitude modulation. The contactless card 102 can use the gap in the power connection of the contactless card to infer the data transmitted from the terminal, which can be functionally maintained by one or more capacitors. The contactless card 102 can perform reverse communication by switching the load or load modulation on the coil of the contactless card. The load modulation can be detected in the coil of the terminal by interference. More generally, using the antenna 1018, the processor 1002 and / or the memory 1004, the contactless card 102 provides a communication interface to communicate via NFC, Bluetooth and / or Wi-Fi communication.

[0250] As explained 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. An applet 1008 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 1008 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 6 Examples of messages that may be generated and communicated by contactless card 102 to perform authentication and transaction operations are shown.

[0251] One example of an NDEF OTP is an NDEF short record layout (SR=1). In such an example, one or more applets 1008 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. Applet 1008 may be configured to add one or more static tag records in addition to the OTP record.

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

[0253] In some examples, the contactless card 102 and the issuer server 802 and / or the switchboard system 830 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). The counter 1010 may be configured to increment each time a read operation occurs. In some examples, each time data from the contactless card 102 is read (e.g., by a mobile device), the counter 1010 is transmitted to the server for verification, and it is determined whether the counter 1010 is equal to (as part of the verification) the server's counter.

[0254] One or more counters 1010 can be configured to prevent replay attacks. For example, if a password has been obtained and replayed, the password is immediately rejected if the counter 1010 has been read or used or otherwise ignored. If the counter 1010 has not been used, it can be replayed. In some examples, the counter incremented on the contactless card 102 is different from the counter incremented for the transaction. The contactless card 102 cannot determine the application transaction counter 1010 because there is no communication between the small application programs 1008 on the contactless card 102.

[0255] In some examples, counter 1010 may become out of sync. In some examples, counter 1010 may be incremented to handle unexpected reads that initiate a transaction, such as reading at an angle, but the application does not process counter 1010. 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 take action in response to the read.

[0256] In order to keep the counter 1010 synchronized, an application (such as a background application) can be executed, which will be configured to detect when the mobile device 110 wakes up, and synchronize with the publisher system 802 and / or the switchboard system 830 to indicate the reading that occurred due to the detection, and then move the counter 1010 forward. In other examples, a hashed one-time password can be utilized so that an unsynchronized window can be accepted. For example, if within a threshold of 10, the counter 1010 can be configured to move forward. But if within a different threshold number, such as within 10 or 1000, a request for performing a resynchronization can be processed, which requests the user to tap, gesture or otherwise indicate one or more times via the user device via one or more applications. If the counter 1010 increases in the appropriate order, it is possible to know that the user has done so.

[0257] The key diversification technique described herein with reference to the counter 1010, the master key and the diversification key 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.

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

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

[0260] Further, the increments for each card may be unique and assigned either by personalization or algorithmically through some identifying information. For example, odd cards may increment by 2 and even cards may increment by 5. In some examples, the increments may also vary in sequential reading, such that a card may increment by 1, 3, 5, 2, 2, ... repeatedly. The specific sequence or algorithmic sequence may be defined at personalization, or in one or more processes derived from a unique identifier. This can make it more difficult for a replay attacker to generalize from a small number of card instances.

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

[0262] Fig.11 11 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. Sequential flow 1100 may include communication between a contactless card 102 and a client device 1102. The client device 1102 may include an application 1104 and a processor 1106. In an embodiment, the application 1104 may be a bank or issuer application. Other examples of applications may include merchant applications, web browsers, game applications, etc. In an embodiment, the client device 1102 may include any number of applications, and the embodiments are not limited in this manner. In an embodiment, the client device 1102 may be a mobile device, a point of sale terminal, a personal computer, etc. Further, the client device 1102 may include additional components, such as additional apps, a memory for storing instructions processed by the processor 1106, an interface, etc.

[0263] At line 1108, the application 1104 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 against the surface of the device to ensure that the card is within the wireless communication range of the card. The communication between the application 1104 and the contactless card 102 may involve the contactless card 102 being brought into close proximity with a card reader (not shown) of the client device 1102 to enable NFC data transfer between the application 1104 and the contactless card 102. In some instances, the communication between the application 1104 and the contactless card 102 may be performed via an operating system that supports a wireless protocol (e.g., NFC, Bluetooth, WiFi, etc.) and utilizes a wireless interface.

[0264] At line 1110, after communication has been established between client device 1102 and contactless card 102, contactless card 102 generates a message authentication code (MAC) password, such as message 600. In some examples, this can occur when contactless card 102 is read by client device. Specifically, this can occur when reading (such as NFC reading) of near field data exchange (NDEF) tags, which can be created according to NFC data exchange format. For example, a reader application (such as application 1104) can transmit a message (such as a small application selection message) having a small application ID of a small application that generates NDEF. After confirmation of the selection, a selection file message sequence followed by a read file message can be transmitted. For example, the sequence can include "select function file", "read function file" and "select NDEF file". At this point, a counter value maintained by contactless card 102 can be updated or incremented, which can be followed by "read NDEF file". At this point, a message such as message 600 can be generated, which can include a header and a shared secret. A session key can then be generated. A MAC password may be created for the message, which may include a header and a shared secret. 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 using a session key. Thereafter, the password and header may be concatenated and encoded as ASCII hexadecimal and returned in an NDEF message format (in response to a "read NDEF file" message). In some instances, as discussed herein, a message delivered to the client device 1102 may include an encrypted portion and an unencrypted portion.

[0265] In some examples, the MAC password can be transmitted as an NDEF tag, and in other examples, the MAC password can be included with a link or uniform resource indicator (e.g., as a formatted string). In some examples, application 1104 can be configured to transmit a request to contactless card 102, the request including instructions for generating a MAC password. In some examples, the MAC password can be included with a link or uniform resource indicator (e.g., as a formatted string). Figure 6 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 applet version and / or issuer identifier may be used by the switchboard system 118 to determine where to route the message.

[0266] At line 1112, the contactless card 102 sends a message including the MAC password to the application 1104. 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 may occur via Bluetooth, Wi-Fi, or other wireless data communication means. At line 1114, the application 1104 passes the message including the MAC password to the processor 1106.

[0267] In the sequence shown, at line 1116, a client device 1102 including a processor 1106 can verify a message including content (such as a MAC password) according to instructions from an application 1104. For example, the MAC password can be verified, as explained below, for example, by processing by a switchboard system 118 and a verification service. In some examples, verifying the MAC password can be performed by the client device 1102 or another device (such as a server of a bank system, an issuer system 802, a switchboard system 118, etc.) that performs data communication with the client device 1102. For example, the processor 1106 can output a message including a MAC password for transmission to a server of an issuer system or a switchboard system 118, which can verify the data in the message including the MAC password, a shared secret, and a counter. In some examples, for the purpose of verification, the MAC password can be used as a digital signature. Other digital signature algorithms, such as a public key asymmetric algorithm (e.g., a digital signature algorithm and an RSA algorithm) or a zero-knowledge protocol can be used to perform the verification.

[0268] In an embodiment, an exchange between the contactless card 102 and the client device 1102 may be performed to perform any number of functions discussed herein. As discussed, embodiments include utilizing the contactless card 102 and tapping the card against a device to perform a verification operation, such as MFA. In another example, the contactless card 102 may be used to perform a transaction for a good or service. There are also other taps to perform functions, including tapping to automatically fill in one or more fields, tapping to start 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, etc. Embodiments are not limited to these instances. One or more operations discussed relative to the sequence flow 1100 may be performed as part of a tap function operation.

[0269] As mentioned, the systems described herein are configured to support any number of tap functions using contactless cards, such as authentication / verification, performing transactions, automatically filling in fields, etc. Fig.12 An example of a routine 1200 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 (e.g., 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 authenticated. In some instances, such as in Fig.14 As discussed in more detail in routine 1400, the verification token can be used to perform additional functions, such as executing a transaction. Other functions may include opening a door, obtaining information, automatically filling in fields, launching an application, providing multi-factor authentication, etc.

[0270] In block 1202, routine 1200 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 switchboard system 1808 via a post to an API. In particular, the switchboard system 1808 may include an API set 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 extensions. Below is an example format of a request.

[0271]

[0272] Note that embodiments are not limited to this example. In embodiments, the encrypted portion of the message may be used by the switchboard system 1808 for authentication, and the decrypted or unencrypted portion may be used by the switchboard system 1808 to route the message to the appropriate process to perform authentication. Figure 6 An example of a message 600 is shown. In an embodiment, the unencrypted portion may be utilized by the system to determine at least where to route the message to perform authentication.

[0273] In some instances, it may first be necessary to establish a client session between the device and the system to obtain a verification token. In these instances, the device may send a request or post to a session initialization API, which 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 issuing a post to the API with information such as a merchant identifier, a reader identifier, and client information including one or more of an Internet Protocol (IP) address, a geolocation, a device identifier, a user agent, and a host name. The post used to establish a session to perform a transaction may have the following format, but is not limited to this approach:

[0274]

[0275] In an embodiment, the exchange system 1808 can process the post 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:

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

[0277] "valid":true,

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

[0279] Further, the session token JWT signed by the session API may include the following embedded details:

[0280]

[0281] As mentioned, the session token may also be included in the request for a validity token. In some instances, the session token may be included in the first request for a validity token, but is not required for future requests. In an embodiment, the post and response used to establish a session may include different usage information based on what the session is being established for. For example, if the session is to perform verification or authentication, the post 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 an auto-fill process, and the post may include usage information such as the website receiving the data, the data being requested. The session is being established as part of an auto-fill process, and the post may include usage information such as the website receiving the data, the data being requested, etc. The embodiments are not limited in this manner.

[0282] In block 1204, the routine 1200 includes determining, by the system, a verification service associated with the contactless card issuer based on information in the unencrypted portion of the message. For example, the switching station system 1808 may determine the contactless card issuer based on an issuer identifier included with the message. The verification service may include a plurality of processes and / or functions that may be performed to verify the information in the encrypted portion of the message.

[0283] In block 1206, routine 1200 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 is able to access security data associated with that particular issuer, but not any other issuer. Therefore, the information for each issuing bank can be isolated to increase data security.

[0284] In an embodiment, the verification service is configured to verify information in the message, such as a MAC password, a counter value, etc. The verification service can send the message, or at least a portion of the message (e.g., an encrypted portion) to the message verification service 824 and the password verification service 826 to perform verification, such as Fig.13A and Fig. 13B shown and discussed.

[0285] In an embodiment, the verification service can determine the result of the verification operation performed by the message verification service 824 and the password verification service 826, and return the result. In some instances, 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.

[0286] In block 1208, the routine 1200 includes generating a verification token based on the verification service successfully verifying the information in the encrypted portion of the message. The verification token can be in a JWT format, such as:

[0287]

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

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

[0290] "valid":true,

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

[0292] Note that if the verification operation fails, the routine 1100 can return a failure indication to the requesting device.

[0293] Fig.12 Included are routines performed by the switchboard system 1808 and a device, such as a mobile device, to verify the contactless card information through the switchboard system 1808. However, in some instances, the device may send a request including a message directly to the issuer system 802, and the issuer system 802 may route the message through the verification service of the switchboard system 1808 to perform verification and receive a validity token. In other instances, the issuer system 802 may perform the verification itself and return an indication as to whether the contactless card is valid.

[0294] Fig.13A A detailed view of a verification system 1304 is shown, which can perform one or more operations to verify information and can be part of a switching station system 1808.

[0295] In some example embodiments, the verification system 1304 includes a message verification service 824 configured to receive an incoming verification request, such as a message generated by a contactless card when performing a tap or NFC read, or at least an encrypted portion of the message. In one example, the request may be directed to the message verification service 824 based on processing performed by the switching station system 1808 (e.g., via a switching station node) on an issuer identifier in an unencrypted portion of the message, such as FIG. 4A to FIG. 4C In some instances, the message may be received from another system (such as publisher system 802).

[0296] In an embodiment, the message verification service 824 may perform one or more services to perform an initial verification of the message. For example, the message verification service 824 may parse the message fields to determine a unique identifier of the card, such as a pUID. The message verification service 824 may use the unique identifier as a key to retrieve the associated card record data stored in a database (such as the card database 1302), and perform basic verification using the record data. For example, the message verification service 824 may verify the information in the message against the information in the record (e.g., app version, publisher ID, pKeyID, pUID, pATC, nonce, and / or pSHSEC). The additional information in the message may include account information, customer data, and / or card information, and the message verification service 824 may verify that it matches the stored data for the card.

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

[0298] In some instances, the card database 1302 may also store an index or key identifier for retrieving a cryptographic key from the verification HSM 828, as well as the expected counter value. The cryptographic key may be used to decrypt the encrypted portion of the message. In other instances, the key identifier or index may be provided in a field in the message itself. If the card record is found in the card database 1302, the message verification service 824 also verifies and checks whether the counter value is in sequence.

[0299] In response to the initial verification being successful, the message verification service 824 records the verification request in the card database 1302 and requests the password verification service 826 to verify the password and the information in the password.

[0300] In an embodiment, the message authentication service 824 may also compare the counter value in the message with the counter value maintained in the card database 1302. In some instances, the counter value on the card (pATC) may become out of sync with the stored counter value, such as an unregistered read. In these instances, the message authentication service 824 may ensure that the card counter value is within an acceptable range of the stored counter value. In some instances, the card counter value exceeds the acceptable range of the stored counter value or is less than the stored counter value, then the message authentication service 824 may determine that fraud has occurred.

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

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

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

[0304] In some embodiments, the system 800 can utilize a verification HSM 828 (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, and 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 1306, such as Fig. 13B As shown, it follows the same steps but uses an open source cryptographic library. The embodiments are not limited in this manner.

[0305] Fig.14 An example sequence diagram 1400 is shown in accordance with embodiments discussed herein. The sequence diagram 1400 shows high-level steps that may be performed to utilize a switching station system 1406 to authenticate a user and their contactless card. Fig.14 One possible sequence is shown, and the embodiments are not limited to this sequence.In some instances, one or more steps may occur before other steps and / or in parallel with each other.

[0306] At 1412, client device 1404 receives a request for performing verification of a user. For example, a mobile app (such as a merchant app) can generate a request for verifying a user of client device 1404 to perform a transaction. In another example, as part of a multi-factor authentication sequence, the app can request verification of the user. In a third example, as part of a login sequence, the app can request verification of the user. Embodiments are not limited in this manner. In some instances, the request can be generated by the user himself (e.g., via a user interface) or by an external system (such as a POS transaction system).

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

[0308] At 1416, the client device 1404 may conduct a communication exchange with the contactless card 1402. For example, in response to the user bringing the contactless card 1402 within the range of the client device 1404, a wireless communication exchange may occur between the client device 1404 and the contactless card 1402. The wireless exchange may be based on wireless protocols such as Bluetooth, NFC, WiFi, etc. In some instances, the exchange may be a "wired" exchange based on the client device 1404 contacting a contact of the contactless card 1402. In an embodiment, the exchange may be based on EMV, wherein the message is modified, as discussed herein. In some instances, the client device 1404 may read and / or receive a message from the contactless card 1402. In addition, the client device 1404 may also write and / or send data to the card, such as a nonce, which may be merged back into the data read by the client device 1404.

[0309] In an embodiment, the client device 1404 may receive data (e.g., in a message) as part of the exchange from the contactless card 1402. The message may include, for example, an encrypted portion and an unencrypted portion of the password. Figure 6 An example of a message 600 is shown.

[0310] At 1418, the client device 1404 may send a request for authentication to the switching station system 1406. The request may include a message. Fig.11 As discussed, the request may be a post to an API of the switching station network 1408. At 1420, the switching station network 1408 may determine where to route the request and what authentication service to perform the authentication. In particular, the switching station network 1408 may utilize the issuer identifier in the unencrypted portion of the message to determine the issuer and its authentication service.

[0311] At 1422, the backbone network 1408 may send the message to the verification system 1410 for verification. The verification system 1410 may process the message using services specifically assigned to the publisher and / or using data associated with the publisher. At 1424, the verification system 1410 may perform one or more verifications, such as those described in reference to FIG. Fig.13A and Fig. 13B discussed.

[0312] At 1426, the verification system 1410 can return the result of the verification to the switching station network 1408, and at 1428, the switching station network 1408 can forward the result to the client device 1404. 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 for the user to log into an app. 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 gain access to a door or room. As will be described in Fig.15 As discussed in more detail in , a verification token can be determined and then provided to the merchant system to perform the transaction.

[0313] In embodiments, system 800 may be used to perform additional functions, such as conducting transactions between cardholders, issuers, and merchants. Fig.15 One example routine 1500 is shown that may be performed by the system 800 including the switchboard system 1808 to process a transaction for a merchant. In some examples, the transaction may be initiated on a device such as a mobile device or a POS terminal.

[0314] In block 1502, routine 1500 includes receiving a request for contactless card holder information, which may include one or more indicators, a verification token, and encryption parameters. A request for information may be required to perform a transaction. One or more indicators may indicate what information the merchant system is requesting to perform a transaction, such as fields. The information may include customer name (first, middle, and last name), date of birth, social security number, address, account number, contactless card information (account number, cvv, expiration date), etc.

[0315] In an embodiment, the verification token may be a token provided by the system, which may be used to perform the following operations: Fig.12 , Fig.13A , Fig. 13B and Fig.14 Functionality discussed. The verification token indicates that the contactless card is authenticated by the system. In some instances, the contactless card may have been authenticated previously or as part of a transaction process.

[0316] The encryption parameters may include a merchant certificate that has 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 together with the merchant can be used to verify the public key.

[0317] In an embodiment, the request may be a post to the API interface of the switching station system 830. 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.

[0318]

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

[0320]

[0321] 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 instances, the system 800 may send a confirmation request to the device, for example, via the publisher's mobile app. If the consent is successfully given, the system 800 may return a success response to the consent sharing request. The following is an example response.

[0322] 700 OK

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

[0324] "success":true}

[0325] In block 1504, routine 1500 includes determining a business service associated with the contactless card issuer. For example, the switching station system 830 can perform a lookup based on the information in the cardholder information request to determine which issuer is associated with the contactless card. In a specific example, the switching station system 830 can utilize a validity token to determine the issuer. As discussed, the validity token includes information such as an issuer or distributor, and the switching station system 830 can utilize this information to determine an associated business service that can further process the request.

[0326] In box 1506, routine 1500 includes: sending at least a portion of the request to a business service. The business service can be part of the switchboard system 1808, such as a "merchant / business api", and perform one or more operations. In particular, the business service can verify the validity token and the information in the validity token. In an embodiment, the validity token can be passed to the business service encrypted via a public key obtained by the merchant. The business service can include an associated private key and perform decryption before verifying the information within the token.

[0327] The business service 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.

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

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

[0330] In one example, the issuer system 802 can generate an Elliptic Curve Diffie-Hellman (ECDH) secret and encrypt the requested cardholder data. The issuer system 802 can return the encrypted data and the contactless card issuer certificate to the business services and switchboard system 830. Further, and at block 908, the routine 1500 includes: receiving the contactless card holder information and the contactless card issuer certificate, for example, from the issuer system 802.

[0331] At box 1510, routine 1500 includes sending a response to the request for contactless cardholder information to the merchant system. The response may include encrypted cardholder information. Therefore, the information can be securely transmitted between the issuer system 802 and the merchant system 806. The response may include additional information, such as a request identifier (see box 1502) that identifies the associated request, an indication of whether the request is successful, and encryption parameters. The encryption parameters may include a public key, an issuer certificate, and a public key signature to verify the public key using the issuer certificate. The public key, the public key signature, or both may be encrypted using the merchant's public key so that only the merchant system 806 can decrypt the public key and signature. The unencrypted public key may be used to encrypt information to be sent to the issuer system 802, and the issuer system 802 may decrypt the information using the issuer's private key.

[0332] The merchant system 806 can verify the issuer certificate based on the information exchanged between the merchant system 806 and the issuer system 802 during the onboarding process. The merchant system 806 can decrypt the public key and signature using the merchant's private key to obtain the key and signature. The signature using 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 to this approach, and the response can be in a different format.

[0333]

[0334]

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

[0336] Fig.16 An example of a sequence diagram 1600 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 for performing a transaction by a merchant.

[0337] At 1614, the client device 1602 may send a request to the merchant system 1604 to perform a transaction. The transaction may be for a purchase of goods or services, and the embodiments are not limited in this manner. In an embodiment, the request may include information about the transaction, an identifier, items for purchase, customer information, etc. In an embodiment, the request may also include a verification token that may be used by the merchant system 1604 to perform a transaction with a backend banking system (e.g., a switchboard system 1606 and an issuer system 1612). The verification token may be previously obtained according to the previously described process flow and sequence.

[0338] At 1616, merchant system 1604 may send a request for information used to perform the transaction to exchange node 1608 of exchange system 1606. The request may be an API POST and include the requested information (fields), a verification token, and a list of encryption information that may be used to encrypt the requested information.

[0339] Fig.14 An example API POST format according to an embodiment is discussed at block 1402 .

[0340] At 1618, the clearinghouse system 1608 may utilize the information in the request to determine the issuer and / or merchant system associated with the transaction. For example, the clearinghouse system 1608 may utilize the verification token to determine the associated issuer bank and the corresponding merchant system.

[0341] At 1620, the exchange system 1608 may send a request to the determined merchant system 1610 to process the request and determine the information. Further, at 1622, the merchant system 1610 may send a request for the requested information to the issuer system 1612. The request may include encryption information that may be used by the issuer system 1612 to encrypt the requested information so that the data remains secure and unidentifiable until the merchant system 1604 receives and decrypts the information, such as Fig.14 discussed.

[0342] At 1624, the issuer system 1612 may determine information based on the request and encrypt the information. At 1626, the encrypted information may be returned to the commerce system 1610. At 1628, the commerce system 1610 may send the encrypted information to the exchange system 1808. The encrypted information may remain secure, and none of the systems exchange system 1606 has the ability to decrypt the information. And the information remains secure until it is decrypted by the merchant system 1604. At 1630, the exchange system 1808 may send the encrypted information to the merchant system 1604. At 1632, the merchant system 1604 may decrypt the information and use the information to complete the transaction.

[0343] Fig.17 An example of a simplified process flow 1700 that may be performed according to an embodiment is shown. In particular, the process flow 1700 may be performed in an environment utilizing a switching station system 108 / 208 to provide processing and communications in a multi-bank issuing system environment. The process flow 1700 is an example of a process for performing a transaction between a merchant and a customer utilizing a contactless card issued by one of multiple issuing banks, and includes obtaining a verification token (such as in, for example, Figure 7 , Fig. 8A and Figure 8B ) and obtaining transaction information (as discussed in e.g. Fig.10 and Fig.11 Both of these are discussed in .

[0344] At line 1702, the user may tap their contactless card on the mobile device 104. In one example, the user may tap their contactless card on the device in response to a mobile app presenting a prompt 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 switching station system 1708. The data may include encrypted and unencrypted data in a message, such as message 900b.

[0345] At line 1704, the switching station system 1708 can use the data in the message to determine the card validator, such as a verification service. For example, the switching station system 1708 can use the unencrypted data (such as the issuer ID) to perform a lookup to determine the verification service 820 for routing the message.

[0346] The switching station system 1708 can send the message to the corresponding authentication service 820, which includes an authentication API configured to process the message including the encrypted portion. In particular, the corresponding authentication service 820 can decrypt the encrypted portion and authenticate the data, for example, Fig.13A or Fig. 13B As described.

[0347] At line 1706, the verification service 820 may transmit the validity token back to the exchange system 1708 and the mobile device 104. At line 1710, the merchant system 806 requests user / consumer information from the exchange system 1708, which includes a request for cardholder information, including the validity token and other data, such as Fig.14 As discussed. The interchange system 1708 may perform a lookup with the corresponding card issuer based on the information received from the merchant system 806 (eg, the validity token).

[0348] The switchboard system 1808 communicates with the issuer network and the corresponding card issuer's commerce service and receives the encrypted user / consumer information at line 1714. The switchboard system 1808 may return the encrypted user / consumer to the merchant system 806, and the merchant system 806 will decrypt the information to perform the transaction or another function.

[0349] Fig.18 A simplified example of an encryption process 1800 is shown, which can be performed according to the embodiments discussed herein to ensure that data communicated between an issuer system and a destination system (such as a merchant system 1814) is secure. At 1802, a merchant 1814 requests cardholder information from a switchboard system 1816, such as in a request message through an API. At 1804, the encryption process 1800 includes the switchboard system 1816 performing a lookup to determine the card issuer to determine which business API 1818 to route the data to. The data is passed to the associated business API service. At 1806, the certificate authority 1820 verifies the merchant certificate and / or returns a result. At 1808, the process includes the service 1818 generating an ECDH secret (or public / private key pair) and encrypting the cardholder data. At 1808, the cardholder data is transmitted to the merchant 1814. At 1810, the encryption process 1800 includes the merchant system verifying the certificate. Further, at 1812, the encryption process 1800 includes the merchant generating an ECDH secret and decrypting the cardholder data.

[0350] Fig.19 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 1902, an API 1904, a network 1906, a distributed ledger node 1910, a mapping 1912, and a client device 1914. Fig.19 A single instance of a component is shown, but system 1900 may include any number of components.

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

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

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

[0354] API 1904 can be provided in the form of a library including routines, data structures, object classes, and specifications of 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 some RESTful practices) is a specification of remote calls exposed to API consumers (e.g., by executing a remote call to a REST API, an application executed on a client computing device can be a consumer of the REST API). REST services generally refer to a software architecture for coordinating components, connectors, and / or other elements within a distributed system (e.g., a distributed hypermedia system).

[0355] The client node 1902 may communicate with one or more other components of the system 1900 directly or via a network 1906. The network 1906 may include one or more of a wireless network, a wired network, or any combination of a wireless network and a wired network, and may be configured to connect the components of the system 1900. Fig.19 Communications between components of system 1900 are shown via network 1906 , but it should be understood that any component of system 1900 may communicate directly with another component of system 1900 , such as without involving network 1906 .

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

[0357] In some examples, verification node 1908 may execute one or more applications, such as software applications, that enable, for example, network communications with one or more components of system 1900, sending and / or receiving data, and performing the functions and processes described herein.

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

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

[0360] In some examples, distributed ledger node 1910 may execute one or more applications, such as software applications, that enable, for example, network communications with one or more components of system 1900, sending and / or receiving data, and performing the functions and processes described herein.

[0361] The distributed ledger node 1910 may include a mapping 1912. In some examples, the mapping 1912 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. The one or more databases may be centralized or distributed. The one or more databases may be hosted internally by any component of the system 1900, or the one or more databases may be hosted externally by any component of the system 1900. In some examples, the one or more databases may be included in the distributed ledger node 1910, and in other examples, the one or more databases may be stored outside the distributed ledger node 1910 but communicate data with the distributed ledger node 1910. The 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 made to one or more databases may be implemented in the same database programming language used to implement the one or more databases. 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 in 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 reflect the specific information to be queried.

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

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

[0364] In some examples, an iteration of a mapping described herein, such as mapping 1912, 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.

[0365] In some examples, client nodes 1902 and distributed ledger nodes 1910 may be licensed (e.g., allowed to join the network) by means of certificates and / or cryptographic authentication mechanisms (e.g., non-replaceable tokens). Certificates and / or cryptographic authentication mechanisms may be issued, for example, by a federation or other administrative entity associated with the distributed network. If appropriate permissions are granted, distributed ledger node 1910 may update mapping 1912 to reflect, for example, different associations between routing numbers, verification node addresses, and verification nodes. In some examples, permission levels may be issued. For example, if the function of client node 1902 is to route data to verification node 1908 (or other verification nodes), client node 1902 may be given a certain level of permission. As another example, if distributed ledger node 1910 is to have the ability to update mapping 1912, distributed ledger node 1910 may have a different, higher level of permission.

[0366] System 1900 may include client device 1914, which may be a network-enabled computer as described herein. In some examples, distributed ledger node 1914 may be a server, which may be a dedicated server computer, a blade server, or may be a personal computer, a laptop computer, a notebook computer, a palmtop computer, a network computer, a mobile device, a wearable device, or any processor-controlled device capable of supporting system 1900. Client device 1914 may also be a mobile device; for example, a mobile device may include a iPhone, iPod, iPad or running Any other mobile device running the iOS operating system, Microsoft's Any device running a mobile operating system like Google Any device running an operating system and / or any other smartphone, tablet, or similar wearable mobile device. In some examples, client device 1914 may be connected to Fig.19 The computer may communicate data with another network-enabled computer not shown, such as a smart card (eg, a contactless card or a contact-based card).

[0367] In some examples, client device 1914 may execute one or more applications, such as software applications, that enable, for example, network communications with one or more components of system 1900 , sending and / or receiving data, and performing the functions and processes described herein.

[0368] In some examples, upon receiving the authentication request, the client device 1914 may call (e.g., via an API) the client node 1902. The call may include a routing number and / or an applet or software version number, and the client node 1902 may query the distributed ledger node 1910 and the mapping 1912. Once the query returns the identification of the verification node (e.g., verification node 1908) and / or the verification node address associated with the routing number and / or applet or software version, the client node 1902 may reply to the client device 1914. The client device 1914 may then authenticate with the verification node. The authentication may be performed, for example, by the systems and methods described herein, for example, by the generation, encryption, transmission, decryption, and verification of the passwords described herein.

[0369] In some examples, the client node 1902 can be symbiotic with the verification node 1908. In these examples, the client node 1902 can handle authentication in a single call from the client device 1914. In some examples, this is acceptable only if it is allowed to send a fully authenticated transmission (e.g., a password as described herein) to a client node that does not participate in authentication.

[0370] In some examples, if client node 1902 receives a routing number that is not processed by its location from client device 1914, client node 1902 can return a code indicating that the routing number is not processed and the verification node address of the responsible verification node. Client device 1914 can then send a full verification transmission to verification node 1908 using the received verification node address.

[0371] In some examples, client node 1902 may enter the distributed network with different permissions. For example, client node 1902 may be a read-only router for data. As another example, client node 1902 may have permission to send a message to distributed ledger node 1910 to update one or more routing paths of one or more routing numbers. However, client node 1902 will be blocked from updating one or more routing paths for one or more routing numbers of other entities that control other routing numbers that are not associated with client node 1902 or have not been granted the permission. As another example, distributed ledger node 1910 may contain contracts and / or records that can verify the permission of a specific entity to change a specific routing record based on its digital signature. As another example, a federation or other management entity that controls a distributed network may have additional privileges to, but not limited to, add new members (e.g., client nodes, distributed ledger nodes, verification nodes, and / or client devices), add new signing certificates, add new keys, add new certificates, and also revoke any of the foregoing. In some examples, the aforementioned permissions may be delegated to client node 1902, distributed ledger node 1910, and / or validation node 1908 if security, legal, and / or financial conditions are met, however, delegation is not required.

[0372] In some examples, one or more APIs can facilitate communication between components of system 1900 via network 1906. In other examples, one or more APIs are not 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 non-designated entities. This can further promote data security and avoid detection of data traffic patterns by non-designated entities.

[0373] In some examples, an entity may establish standards for nodes with APIs based on the expected functions 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. For another example, a routing API, a mapping API, and a verification API may be established that may allow the same device or hardware configuration to perform these functions. However, the use of keys, including secret keys authenticated by verification node 1908, may require that the keys be stored in one or more HSMs to facilitate key security and ensure that the keys are never entered into memory.

[0374] Fig. 20 A method 2000 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 another distributed network authentication system.

[0375] In block 2002, the client device may transmit 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.

[0376] After receiving the authentication request, the client node may transmit a query to the distributed ledger node (e.g., via an API call) in block 2004. The distributed ledger node contains a mapping, and the distributed ledger node may submit the query to the mapping.

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

[0378] In block 2008, the client node may transmit the identification to the client device. After receiving the identification, in block 2010, the client device may proceed with authentication using the identified verification node and / or verification node address.

[0379] Fig.21 A routine 2100 for card personalization according to an example embodiment is shown. For example, the routine 2100 can be performed by the devices and systems described herein, including but not limited to: the issuer system 802 and the personalization system 804.

[0380] In box 2102, contactless card 102 may be initially configured with one or more applets stored in memory, which are in at least one selected from a group of a dormant state, a deactivated state, a locked state, and a versioned state (e.g., a first version state or a second version state). One or more applets may be configured for the execution of a specific function. For example, a first applet in one or more applets may be configured to perform a payment transaction, such as an EMV transaction. For another example, a second applet in one or more applets may be configured to perform an authentication operation, such as the authentication operation described herein. One or more applets are configured to be in a dormant state before reaching an agreement with a card issuing entity to activate or otherwise start a transaction.

[0381] In block 2104 , the contactless card 102 may be further configured with a unique identifier, such as a pUID 610 .

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

[0383] In box 2108, upon successful verification, the first applet may be activated or otherwise change state. Once it is activated or its state is changed, the first applet can no longer be in a dormant state, a deactivated state, a locked state, and / or a first version state. Instead, the first applet may be in a non-dormant state, an activated state, an unlocked state, and / or a second version state. The first applet may then conduct a payment transaction.

[0384] In box 2110, upon successful verification, the second applet may be activated or otherwise change state. Once it is activated or its state is changed, the second applet can no longer be in a dormant state, a deactivated state, a locked state, and / or a first version state. On the contrary, the second applet may be in a non-dormant state, an activated state, an unlocked state, and / or a second version state. The second applet may then perform an authentication operation.

[0385] In an embodiment, routine 2100 may be performed when the card is activated and / or when the card is used for the first time. Once activated, the first applet and the second applet may perform payment transactions and authentication operations, respectively, and communicate with each other. The first applet and the second applet may also communicate externally to identify the contactless card.

[0386] The systems and methods described herein can provide additional improvements to data security, authentication, and verification. For example, the use of customized NFC specifications can improve performance and simplify the NFC protocol. The use of signed hashes of card product customer identifiers can simplify policy decisions, which can enable confirmation that an instance is owned by the appropriate customer without a mapping file that relates an identifier (e.g., a unique identification number) to a customer number. The use of a centralized authenticator (such as a key in a hub) can enable a light-touch deployment model for issuing entities (e.g., for pilots). In addition, the use of general cryptography (e.g., a root of trust) can enable deployment on a general cloud hardware security module (HSM).

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

[0388] As used in this application, the terms "system" and "component" are intended to refer to computer-related entities: hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing computer architecture 2200. 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 (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 components can be located on a computer and / or distributed between two or more computers. Further, 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 through a communication medium. Information can be implemented as a signal assigned to various signal lines. In such an assignment, each message is a signal. However, a further example can alternatively employ a data message. Such a data message can be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0389] The computing architecture 2200 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 2200.

[0390] like Fig. 22 As shown, computing architecture 2200 includes processor 2212, system memory 2204, and system bus 2206. Processor 2212 may be any of a variety of commercially available computer processors.

[0391] The system bus 2206 provides an interface for system components, including but not limited to the system memory 2204 to the processor 2212. The system bus 2206 can be any of a variety of types of bus structures, which can also use any of a variety of commercially available bus architectures to interconnect with a memory bus (whether or not having a memory controller), a peripheral bus, and a local bus. An interface adapter can be connected to the system bus 2206 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), NuBus, peripheral component interconnect (PCI), PCI (extended) (PCI (X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA) and similar architectures.

[0392] The computing architecture 2200 may include or implement various articles of manufacture. Articles of manufacture may include a computer-readable storage medium for storing logic. Examples of computer-readable storage media may include any tangible medium capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, 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.

[0393] The system memory 2204 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, Austenite 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. 22 In the illustrative embodiment shown, system memory 2204 may include non-volatile 2208 and / or volatile 2210. A basic input / output system (BIOS) may be stored in non-volatile 2208.

[0394] The computer 2202 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 2230, a disk drive 2216 that reads from or writes to a removable disk 2220, and an optical drive 2228 that reads from or writes to a removable optical disk 2232 (e.g., a CD-ROM or DVD). The hard disk drive 2230, the disk drive 2216, and the optical drive 2228 may be connected to the system bus 2206 via a HDD interface 2214, an FDD interface 2218, and an optical drive interface 2234, respectively. The HDD interface 2214 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

[0395] The drives and associated computer-readable media provide volatile storage 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 2208 and volatile 2210, including an operating system 2222, one or more applications 2242, other program modules 2224, and program data 2226. In one embodiment, one or more applications 2242, other program modules 2224, and program data 2226 may include, for example, various applications and / or components of the systems discussed herein.

[0396] A user may enter commands and information into the computer 2202 through one or more wired / wireless input devices (e.g., a keyboard 2250 and a pointing device such as a mouse 2252). 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, and the like. These and other input devices are typically connected to the processor 2212 through an input device interface 2236 coupled to the system bus 2206, but may also be connected by other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, and the like.

[0397] A monitor 2244 or other type of display device is also connected to the system bus 2206 via an interface, such as a video adapter 2246. The monitor 2244 may be internal or external to the computing architecture 2200. In addition to the monitor 2244, computers typically include other peripheral output devices, such as speakers, printers, and the like.

[0398] The computer 2202 can operate in a networked environment using logical connections via wired and / or wireless communications with one or more remote computers, such as remote computer(s) 2248. The remote computer(s) 2248 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment appliance, peer device, or other public network node, and typically includes many or all of the elements described relative to the computer 2202, although only a memory / storage device 2258 is shown for purposes of simplicity. The depicted logical connections include wired / wireless connections to a local area network 2256 and / or a larger network, such as a wide area network 2254. 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 communications network, such as the Internet.

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

[0400] When used in a wide area network 2254 networking environment, the computer 2202 may include a modem 2240, or be connected to a communication server on the wide area network 2254, or have other means for establishing communications over the wide area network 2254, such as by means of the Internet. The modem 2240 may be an internal or external wired and / or wireless device, connected to the system bus 2206 via the input device interface 2236. In a networked environment, program modules or portions thereof depicted relative to the computer 2202 may be stored in the remote memory / storage device 2258. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

[0401] The computer 2202 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 IEEE 802.11 (a, b, g, n, ac, ax, 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).

[0402] Various elements of the device as previously described herein 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, applications, 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 can vary depending on any number of 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, as desired for a given implementation.

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

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

[0405] like Fig.23 As shown, the communication architecture 2300 includes one or more clients 2302 and servers 2304. The server 2304 can implement one or more functions and embodiments discussed herein. The client 2302 and the server 2304 are operably connected to one or more corresponding client data stores 2306 and server data stores 2308, which can be used to store information local to the corresponding client 2302 and server 2304, such as cookies and / or associated context information.

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

[0407] The communication framework 2310 can implement various network interfaces, which are arranged to receive, transmit 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 (such as thick, thin, twisted pair 10 / 100 / 1000BaseT, etc.), token ring, wireless network interface, cellular network interface, IEEE 802.7ax network interface, IEEE 802.16 network interface, IEEE 802.20 network interface and similar protocols. Further, multiple network interfaces can be used to participate in various communication network types. For example, multiple network interfaces can be used to allow communication through broadcast, multicast and unicast networks. If the processing requirements specify a greater speed and capacity, a distributed network controller architecture can be similarly adopted to aggregate, load balance and otherwise increase the communication bandwidth required by the client 2302 and the server 2304. The communication network can be any type and combination of wired and / or wireless networks, including but not limited to direct interconnection, secure customized connection, private network (such as corporate intranet), public network (such as the Internet), personal area network (PAN), local area network (LAN), metropolitan area network (MAN), mission operating as a node on the Internet (OMNI), wide area network (WAN), wireless network, cellular network and other communication networks.

[0408] In some aspects, the technology described herein relates to a computer-implemented method, comprising: reading, by a computing device, a contactless card after the contactless card enters a communication field; selecting, by the computing device, an applet stored in a memory of the contactless card based on the reading of the contactless card; transmitting, by the computing device, a first command to the contactless card; and transmitting, by the computing device, a second command to the contactless card.

[0409] In some aspects, the technology described herein relates to a computer-implemented method in which the first command comprises a custom command.

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

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

[0412] In some aspects, the technology described herein relates to a computer-implemented method, wherein the custom command includes at least one selected from the group consisting of: a command to change the format of a message stored on the contactless card and a command to change the format of a message generated by the contactless card.

[0413] In some aspects, the technology described herein relates to a computer-implemented method, wherein the custom command includes at least one selected from the group consisting of: a command to change a parameter for a calculation performed by the contactless card and a command to transfer a credential.

[0414] In some aspects, the technology described herein relates to a computer-implemented method, wherein the custom command includes at least one selected from the group consisting of: a command to change a form of authentication operation used by the contactless card.

[0415] In some aspects, the technology described herein relates to a computer-implemented method wherein the form of authentication includes at least one selected from the group consisting of: a cryptographic message authentication code (MAC) operation and a signed message with a public key certificate.

[0416] In some aspects, the technology described herein relates to a computer-implemented method wherein the second command comprises a command for the contactless card to calculate a cryptogram.

[0417] In some aspects, the techniques described herein relate to a computer-implemented method in which the computation of the password utilizes the nonce.

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

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

[0420] In some aspects, the technology described herein relates to a computing system wherein the second command includes a command for the contactless card to calculate a password.

[0421] In some aspects, the technology described herein relates to a computing system further comprising: the contactless card, wherein the contactless card uses the nonce to calculate the password.

[0422] In some aspects, the technology described herein relates to a computing system wherein: the instructions further cause the processor to read a capability container stored in a memory of the contactless card, and the capability container is associated with the selected applet.

[0423] In some aspects, the techniques described herein relate to a computing system wherein reading the capability container collects information including at least one selected from the group of a size of the capability container and a number of files stored in the capability container.

[0424] In some aspects, the technology described herein relates to a computing system, wherein the information also includes at least one selected from the group of the following items: the file size of the file stored in the functional container, the file name of the file stored in the functional container, the read status of the file stored in the functional container, and the write status of the file stored in the functional container.

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

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

[0427] In some aspects, the technology described herein relates to a non-transitory computer-readable storage medium, wherein the second command includes a command for the contactless card to calculate a cryptogram using the nonce.

[0428] The present disclosure is not limited to the specific embodiments described in this application, which are intended to be illustrative of various aspects. Without departing from its spirit and scope, many modifications and variations can be made, as may be apparent. In addition to those listed herein, functionally equivalent methods and devices within the scope of the present disclosure can be apparent from the aforementioned representative descriptions. The steps described herein do not need to be performed in the same order discussed or with the same degree of separation. Similarly, each step can be omitted, repeated or combined as needed to achieve the same or similar purpose. Such modifications and variations are intended to fall within the scope of the attached representative claims. The present disclosure is limited only by the attached representative claims and the full range of equivalents enjoyed by such representative claims. It should be understood that the terms used herein are only for the purpose of describing specific embodiments and are not intended to be restrictive.

[0429] In the foregoing description, various preferred embodiments have been described with reference to the accompanying drawings. However, it will be apparent that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the following claims. Accordingly, the description and drawings should be regarded as illustrative rather than restrictive.< / jwt> < / puid> < / message> < / nonce> < / nonce>

Claims

1. A computer-implemented method comprising: reading the contactless card by a computing device after the contactless card enters the communication field; selecting, by the computing device, an applet stored in a memory of the contactless card based on reading the contactless card; transmitting, by the computing device, a first command to the contactless card; as well as A second command is transmitted by the computing device to the contactless card.

2. The computer-implemented method of claim 1 , wherein: The first command includes a custom command.

3. The computer-implemented method of claim 2, wherein: The custom commands include a command to update a file stored by the contactless card to include a nonce.

4. The computer-implemented method of claim 2, wherein: The custom commands include commands to change the state of the applet.

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

6. The computer-implemented method of claim 2, wherein: The custom command includes at least one selected from the group consisting of: a command to change a parameter for a calculation performed by the contactless card, and a command to transfer a certificate.

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

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

9. The computer-implemented method of claim 2, wherein: The second command includes a command for the contactless card to calculate a password.

10. The computer-implemented method of claim 9, wherein: The calculation of the password utilizes the nonce.

11. A computing system comprising: A computing device comprising a processor and a memory, The memory stores instructions which, when executed by the processor, cause the processor to: reading the contactless card after the contactless card enters the communication field, selecting an applet stored in a memory of the contactless card based on reading the contactless card, transmitting a first command to the contactless card, and A second command is transmitted to the contactless card.

12. The computing system of claim 11, wherein: The first command comprises a command to update a file stored by the contactless card to include a nonce.

13. The computing system of claim 11, wherein: The second command includes: a command for the contactless card to calculate a password.

14. The computing system of claim 13, further comprising: The contactless card, The contactless card uses the nonce to calculate the password.

15. The computing system of claim 11, wherein: The instructions further cause the processor to read a capabilities container stored in a memory of the contactless card, and The capability container is associated with the selected applet.

16. The computing system of claim 15, wherein: Reading the capability container collects information including at least one selected from the group of a size of the capability container and a number of files stored in the capability container.

17. The computing system of claim 16, wherein: The information also includes at least one selected from the group of the following items: the file size of the file stored in the functional container, the file name of the file stored in the functional container, the read status of the file stored in the functional container, and the write status of the file stored in the functional container.

18. A non-transitory computer-readable storage medium storing instructions that, when executed by a computing device, cause the computing device to perform a process comprising: reading the contactless card; selecting an applet stored in a memory of the contactless card based on reading the contactless card; transmitting a first command to the contactless card; as well as A second command is transmitted to the contactless card.

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

20. The non-transitory computer-readable storage medium of claim 19, wherein: The second command includes a command for the contactless card to calculate a password using the nonce.

Images