Systems and methods for providing online and hybrid card interactions

Abstract

Various embodiments generally relate to authenticating a user for non-payment purposes with a payment protocol, a computer device, and a contactless card. The payment protocol can be in compliance with EMV standards. An application can determine that authentication or verification of a user can require access to a non-payment feature of another application associated with the user and the computer device. The application can then receive and / or facilitate the transmission of encrypted data from a communication interface of a contactless card associated with an account and do so with offline or online techniques. The offline or online techniques can include one or more operations that can verify the identity of the user and / or authorize the user to access various aspects of the other application.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Patent Application Serial No. 16 / 503,285, filed July 3, 2019, entitled "Systems and methods for providing online and hybrid card interactions." The contents of the aforementioned patent application are incorporated herein by reference in their entirety.

[0003] Declarations combined by reference

[0004] This application relates to U.S. Patent Application Serial No. 16 / 135,954, filed on September 19, 2018, entitled "Systems and methods for providing card interactions," the entire contents of which are incorporated herein by reference. Technical Field

[0005] The embodiments described herein generally relate to computing platforms, and more specifically, to authenticating users based on authentication communication between contactless transaction cards and user equipment. Background Technology

[0006] Activating many cards, more specifically debit cards (such as credit cards), involves a time-consuming process where the cardholder makes a phone call or visits a website and enters or otherwise provides card information. Furthermore, while the increasing use of chip-based debit cards offers greater security for in-person purchases than previous technologies (such as magnetic stripe cards), account access still typically relies on login credentials (such as username and password) to verify the cardholder's identity. However, if these login credentials are compromised, another person can access that user's account.

[0007] Therefore, there is a need for improved methods for activating cards and improved authentication for account access. Summary of the Invention

[0008] Embodiments disclosed herein provide systems, methods, articles of manufacture, and computer readable media for authenticating a user with a payment protocol for a purpose other than making a payment. According to one example, an application executing on a computer system can initiate a communication to verify a user's identity or to verify a card with a third party device. As part of the communication, the application executing on the system can utilize near field communication (NFC) and a card associated with the user. (In various embodiments, the application can be initiated by tapping a contactless card on a user device (e.g., a mobile device)). The communication can include receiving, by the application, a plurality of inputs (including an application transaction counter (ATC)), and generating a cryptogram based on the plurality of inputs and a symmetric key associated with the contactless card. The application can then transmit the cryptogram and the ATC to an issuer, which can provide a response verifying the user's identity based on the transmitted cryptogram, where the received response is based on a communication involving recreation of the symmetric key and / or the cryptogram as a whole, where the generation of the cryptogram and the received response is based on a payment protocol, and where the verification of the user's identity or the card verification is different from completing a payment related to the payment protocol. In various embodiments, the verification process and any or all operations associated therewith can be initiated by tapping a contactless card on a user device (e.g., a user's mobile device).

[0009] According to another example, a hybrid technique that utilizes offline and online authentication can be employed to authenticate a user. A system or device having memory storing instructions and processor circuitry capable of executing the instructions can employ one or more hybrid verification techniques, including a combination of offline and online. Execution of the instructions can cause the processor circuitry to perform one or more operations. These operations can include receiving, from an application associated with a user device, user credentials (e.g., a password and a username) associated with a user profile. (In various embodiments, the application can be initiated by tapping a contactless card on the user device (e.g., a mobile device)). Another operation can include comparing the received user credentials to second (stored) user credentials (e.g., a stored version of the password / username combination). (In various embodiments, the first comparison can also be initiated by tapping the contactless card on the user device (e.g., a mobile device)). If a match is found, and in response thereto, another operation can include performing i) a plurality of hostless verification operations and ii) a plurality of issuer verification operations. The hostless operations can include: a) communicating, by the application and using near field communication (NFC) with the contactless card, wherein the contactless card can be associated with a user account and cardholder information, b) receiving, by the application and from the card, a public key of a key pair of the card and cardholder identification information of an account holder of the card, c) instructing, by the application, generation of a digital signature by the card using a private key of the key pair of the card, d) receiving, from the card, the digital signature, and f) verifying the digital signature using the public key. In various embodiments, the offline verification techniques can occur before or after a series of online verification operations initiated or performed as a result of the process executing the instructions. The online verification operations can include: a) providing, by the application and from the card to a computer device, a plurality of inputs including an application transaction counter (ATC), b) generating, by the application and from the card, a cryptogram based on the plurality of inputs and a symmetric key associated with the card, c) sending, by the application, the cryptogram and the ATC to an issuer, and d) receiving a response from the issuer verifying the identity of the user based on the sent cryptogram, wherein the received response is based on a communication involving the issuer recreating the symmetric key and / or the cryptogram as a whole in response to receiving the cryptogram. In various embodiments, the online verification operations can be initiated only after a successful comparison for a second match between at least a portion of the user’s identity and at least a portion of the cardholder identification information (where the second comparison can also be initiated by tapping the contactless card on the user device, and where the total communication can involve more than one tap of the contactless card on the user device).

[0010] According to yet another example, a host system (e.g., an issuer's host) is provided, wherein the host system is capable of utilizing a payment protocol to verify a non-payment event of a user. The host system can include a non-transitory computer-readable storage medium storing computer-readable program code executable by a processor to: receive communication data associated with a user authentication communication initiated by i) an application associated with a user and a card and ii) at least one computer device, the communication data including i) an application transaction counter (ATC) and ii) a cryptogram based on a plurality of inputs of the communication and a symmetric key associated with the card, and send a response from the issuer to verify the user's identity based on the received cryptogram, wherein the sent response is based on a communication involving recreation of the symmetric key and / or the cryptogram as a whole, wherein the cryptogram and the response sent from the issuer are based on a payment protocol, and wherein the user authentication and / or card verification is different from completing a payment related to the payment protocol. BRIEF DESCRIPTION OF DRAWINGS

[0011] Figure 1 An embodiment of a system for verifying or authenticating a contactless card according to a payment protocol is shown.

[0012] Figures 2A-2B An embodiment of a tap to verify a contactless card with a payment protocol is shown.

[0013] Figures 3A-3C An embodiment of a tap to verify a contactless card with a payment protocol is shown.

[0014] Figures 4A-4B An example of a contactless card is shown.

[0015] Figure 5 An embodiment of a first logic flow is shown.

[0016] Figure 6 An embodiment of a second logic flow is shown.

[0017] Figure 7A An embodiment of a third logic flow is shown.

[0018] Figure 7B An embodiment of a fourth logic flow is shown.

[0019] Figure 8 An embodiment of a computing architecture is shown. DETAILED DESCRIPTION

[0020] Aspects disclosed include systems, methods, and / or techniques for providing authenticated cardholder access. Generally, various embodiments relate to i) online and / or ii) hybrid online and offline protocols that mimic authentication protocols between a contactless transaction card and a point-of-sale device, except in one or more embodiments of the present disclosure, the authentication protocol is not used to complete a payment event, and can or can not utilize a real-time online connection with an issuer of the transaction card (e.g., an authentication server of the issuer) to facilitate a transaction related to the authentication protocol. Consistent with the disclosed embodiments, systems and methods can utilize one or more computing devices, processors, network servers, account servers, and / or contactless devices (e.g., radio frequency identification (RFID) cards).

[0021] Various embodiments of the present disclosure provide one or more benefits in verifying contactless cards, and in various embodiments, as a result of the verification, a user associated with the contactless card includes enhanced security provided by dynamic authentication techniques (e.g., online and / or online and offline hybrid techniques) associated with payment protocols, but for a purpose other than making or completing a payment. In various embodiments, utilizing online techniques and / or online and offline hybrids improves the efficiency of a computing device (e.g., a mobile phone) by providing a single method for authenticating or verifying a contactless card, and in various embodiments, thereby extends to a user that can span one or more applications, even if a payment is not associated with the application, and / or even if the purpose of one or more applications differs (e.g., a transportation application related to an entertainment application). Moreover, because one or more payment protocols can have enhanced security due to the nature of the authentication associated therewith, e.g., the EMV standard is maintained with high security as a goal to avoid theft of funds, the security benefit transfers to other environments and applications. Thus, in various embodiments, a payment authorization protocol can be used to efficiently and more securely authenticate a contactless card, thereby extending and authenticating a user associated therewith and across different applications and purposes (including wireless communications, transactions, and / or operations that do not involve payments) in accordance with various embodiments associated therewith.

[0022] Further, as opposed to a pure offline method, an online or hybrid method allows for proper synchronization between counters used by the contactless card, such as an application counter (ATC), and counters of the issuer, which can prevent errors during the authentication process when a large number of offline events occur without the issuer side (e.g., server) being notified and updated accordingly. Further, various embodiments that utilize a combination of offline and online techniques (e.g., hybrid techniques) provide additional advantages as proper tools for authentication are available in case of network interruptions, or when additional security is needed. Further, various embodiments provide partial access through the authentication portion of the online technique, and full access once offline verification occurs (or vice versa), which provides further flexibility where some applications (e.g., bank applications that provide access to financial accounts) possess a first level of information (e.g., name, address, etc.) that has a certain level of sensitivity, and a second level of information (account balance, pin information, password or passcode information, etc.) that has a higher level of sensitivity. Accordingly, various embodiments provide the ability to ensure proper security of access to one or more aspects of one or more applications, and / or additionally provide proper synchronization of counter information.

[0023] Figure 1 A schematic diagram of an exemplary system 100 consistent with the disclosed embodiments is depicted. As shown, system 100 includes one or more contactless cards 101, one or more mobile devices 110, and a server 120. Contactless card 101 represents any type of payment card, such as a credit card, a debit card, an ATM card, a gift card, etc. In various embodiments, contactless card 101 or card 101 is a virtual payment card. Contactless card 101 can include one or more chips (not depicted), such as a radio frequency identification (RFID) chip, that are configured to communicate with mobile device 110 via NFC, EMV standards, or other short-range protocols in wireless communication. While NFC is used as an example communication protocol, the present disclosure is equally applicable to other types of wireless communication, such as other suitable communication protocols in compliance with EMV standards, Bluetooth, and / or Wi-Fi. Mobile device 110 represents any type of network-enabled computing device, such as a smartphone, a tablet, a wearable device, a laptop, a portable gaming device, etc. Server 120 represents any type of computing device, such as a server, a workstation, a cluster of computers, a cloud computing platform, a virtualized computing system, etc.

[0024] As shown, the memory 102 of the contactless card includes data storage of card data 103, a counter 104, a master key 105, a diversified key 106, a unique customer identifier 107, and an account number 108. The card data 103 generally includes account-related information such as information for processing payments using the contactless card 101. For example, the card data 103 can include an account number, an expiration date, a billing address, and a card verification value (CVV). The account number can be any type of account number, such as a primary account number (PAN), a virtual account number, and / or a token generated based on a PAN. Other types of account numbers are contemplated, and the use of an account number or other type of card data 103 should not be considered limiting to the present disclosure. The card data 103 can also include a name, a billing address, a shipping address, and other account-related information. The account number 108 stores one-time virtual account numbers with associated expiration dates and CVV values. For example, the account number 108 can include thousands of one-time virtual account numbers, expiration dates, and CVV values.

[0025] As shown, the memory 111 of the mobile device 110 includes an instance of an operating system (OS) 112, and the processor 119 can perform one or more operations associated with applications of the operating system (OS) 112 and / or perform any other suitable operations associated with processor activity, including comparison operations and executing instructions associated with the memory 111. Example operating systems 112 include OS, and operating systems. As shown, the OS 112 includes one or more applications, including an account application 113, an authentication or verification application or service 114 (hereinafter referred to as the “authentication application” for convenience), one or more other applications 115, and / or one or more access applications 116. The account application 113 allows a user to perform various account-related operations, such as viewing an account balance, purchasing items, and processing payments. Initially, the user can authenticate using authentication credentials to access the account application 113. For example, the authentication credentials can include a username and password, a biometric credential, and / or the like.

[0026] The authentication application 114 is generally configured to determine when a contactless card and / or a user associated with a contactless card needs to be authenticated for a transaction, service, event, or accessibility request (including authentication for purposes other than a payment event, wireless communication, service, or request). For example, the authentication application 114 can determine that a user needs to access a particular application other than a payment request, such as the access application 116. In various embodiments, the access application 116 can be associated with a contactless card associated with the user. The access application 116 can be or can include an application configured to authorize access to a particular service associated with a user account, such as a transportation service (e.g., public transportation), a health insurance account, a financial account or financial application containing account balances, brokerage information, or any other suitable financial data, a service application (retail services, delivery services, entertainment services, gaming services, etc.), and any other suitable application that can require user and / or contactless card authentication. In various embodiments, the access application 116 is associated with a first level user account option of a user account, where the first level user account option can include a display of account balances, a display of recent transactions, etc. In various embodiments, the access application 116 can be associated with a payment feature (e.g., a credit or bank account for making or receiving payments), but the authentication communication can still include a non-payment feature for authentication or verification (e.g., credit card or debit card activation). In various embodiments, the authentication application 114 can facilitate the authentication protocol with a separate API interface and a call for access to the access application 116. The authentication application 114 can be configured to verify a contactless card and / or a user associated with a contactless card by utilizing any suitable payment protocol, including one or more of any verification processes utilizing cryptographic techniques (e.g., standards or authentication protocols in compliance with EMV standards). In various embodiments, the authentication application 114 is configured to synchronize a counter 104 associated with a contactless card 101 and a server 120 associated with an issuer capable of communicating with the contactless card 101 and a mobile device (e.g., an authentication server of the issuer) when authenticating the contactless card 101 and / or a user associated with the contactless card 101.

[0027] In various embodiments, the authentication application 114 can coordinate with the server 120 and / or the contactless card 101 to record authorization of non-payment communications (e.g., communications) related to the counter. This log can be a counter log 121 located in the memory 122 of the server 120 or the memory 102 of the contactless card 101. This log can keep a separate count of events as payment events and / or communications and non-payment events and / or communications regardless of the total count of the counter 104 and the server 120 or the contactless card 101. The server 120 and / or the authentication application 114 in communication with the contactless card can utilize the information contained therein to take anti-fraud measures. For example, if the threshold number of non-payment events and / or communications between non-payment events and / or communications and payment events and / or communications is too small (or too large), the authentication application 114 and / or the server 120 can reject the payment event and / or communication or vice versa. In various embodiments, the counter log 121 containing the distinction information (e.g., count) between non-payment and payment communications and / or transactions can be used for any other suitable purpose during online or offline verification protocols.

[0028] In various embodiments, the authentication application 114 is associated with the account application 113. For example, the authentication application 114 can be installed on the mobile device 110 with the account application 113 and prompt the user to enable the authentication application 114 after installation. More generally, each time the account application 113 is opened, the account application 113 can determine whether the authentication application 114 is enabled as the default authentication application for the OS 112. If the authentication application 114 is not enabled as the default authentication application, the account application 113 can prompt the user to enable the authentication application 114 as the default authentication application for the OS 112 and / or enable one or more functions of the authentication application 114. Once enabled as the default authentication application for the OS 112, the authentication application 114 can programmatically identify when an authorized application requires authentication and can utilize payment protocols to enable verification even if the payment is not associated with the verification or authentication. In various embodiments, to initiate an authentication or verification protocol (e.g., at least one operation associated with an online or offline verification technique or protocol), the authentication application 114 can prompt the user to tap the contactless card 101 of the mobile device 110 to initiate the authentication application 114 or one or more operations associated therewith.

[0029] Generally, in various embodiments described herein, an online verification or authentication protocol can include one or more of the following operations: an authentication application can initiate a communication (e.g., a wireless communication) to verify an identity of a contactless card and / or a user associated with the contactless card, where the authentication application can initiate an entire or partial application (e.g., an access application 116) by prompting the user to tap the contactless card 101 on a computer device (e.g., a mobile device 110). The communication can involve NFC communication between a card reader 118 and the contactless card 101, where the contactless card 101 can provide one or more inputs to the mobile device 110, including a latest version of an application transaction counter (ATC), and the contactless card 101 or the mobile device 110 (including any suitable components associated therewith) can generate a suitable cryptogram based on the plurality of inputs, and then the contactless card 101 or the mobile device 110 (including any suitable components associated therewith) can send the cryptogram and the ATC to an issuer of the contactless card 101 (e.g., a server 120 associated with the issuer). The contactless card 101 and / or the user can then be verified and receive access to one or more features associated with the application 116 by receiving a response from the issuer (e.g., an authentication server of the issuer) that verifies or authenticates the contactless card (and by extension, the user associated therewith), where the received response is based on at least one cryptographic operation performed by the issuer (e.g., the server 120) in response to receiving the cryptogram, and where the generation of the cryptogram and the receipt of the response from the issuer (e.g., the authentication server of the issuer) are based on a payment protocol, and where the communication and verification of the contactless card and / or the user identity of the user are distinct from completing a payment related to the payment protocol. As described herein, the protocol can be initiated by one or more taps of the contactless card 101 on the mobile device 110.

[0030] Generally, in various embodiments described herein, an offline verification or authentication protocol can include one or more of the following operations: to provide a user with access to one or more features of an access application 116, a verification application 114 can initiate NFC communication between a mobile device 110 and a contactless card 101, and receive one or more inputs from the contactless card 101, where the communication can utilize a card reader 118. The verification application 114 can facilitate receiving a public key of a key pair and cardholder identification information of an account holder (e.g., a user) of the card from the contactless card 101. An application or component associated with the contactless card 101 and / or the verification application 114 can instruct a component of the card 101 to generate a digital signature by using a private key of the card’s key pair, and the mobile device 110 can receive the digital signature from the card 101 and verify the signature using the public key. As described herein, the protocol can be initiated by one or more taps of the contactless card 101 on the mobile device 110.

[0031] In various embodiments, a hybrid protocol involving one or more operations of an online and offline protocol can be utilized, where the online protocol can be initiated by a first or second tap of the contactless card 101 on the mobile device 110 and / or a first or second user credential comparison, and the offline protocol can be initiated by a first or second tap of the contactless card 101 on the mobile device 110 and / or a first or second user credential comparison, where the combination of offline and online protocols can be part of a single verification or authentication, or where each protocol can be associated with a partial verification or authentication.

[0032] In various embodiments where the contactless card 101 is a virtual payment card, the authentication application 114 can retrieve information associated with the contactless card 101 by accessing a digital wallet implemented on the mobile device 110, where the digital wallet includes the virtual payment card.

[0033] As shown, the server 120 also includes a data store 124 of account data and a memory 122. The account data 124 includes account-related data for a plurality of users and / or accounts. The account data 124 can include at least the master key 105, counters 104 such as an application transaction counter (“ATC”) 104, a customer ID 107, associated contactless cards 101, account holder name, account billing address, one or more shipping addresses, one or more virtual card numbers, and history information for each account. The memory 122 includes instances of the management application 123 and card data 103, counters 104, master key 105, and diversification keys 106 for one or more accounts from the account data 124.

[0034] The system 100 is configured to implement key diversification to protect data, which can be referred to herein as a key diversification technique. The system 100 can implement an online authentication protocol or a hybrid online and offline authentication protocol. Both the online authentication protocol and the hybrid offline and online authentication protocol can utilize one or more operations of the server 120.

[0035] In various embodiments, the authentication application 114 receives a first application user credential associated with a user profile from a user. The first application user credential can include biometric data, an established gesture associated with user identification, a username and password combination, etc. The processor 119 compares the first application user credential to a stored second application user credential. The stored second application user credential can be associated with the user identity, and it can be stored in the memory 111 of the mobile device 110 or in the memory 122 of the server 120. In various embodiments, the stored second application user credential is maintained on the server 120, and the first match is performed by the server 120. In various embodiments, upon determining a first match between the first application user credential and the stored second application user credential, the authentication application can authorize the user to access one or more first level user account options of a user account. The user account can be a financial account, a health insurance account, and / or any other account associated with any service provider (e.g., a transit account, an entertainment account, etc.). Upon determining the first match, the user can access certain first level user account options. The first level user account options of the user account can include a display of an account balance, a display of recent transactions, a display of events, etc. A second level authentication can be required for better access and / or execution of certain account functions (i.e., second level user account options). The second level user account options can include a personal identification number (PIN) change request and an address change request. Various embodiments associated with first level and / or second level access are discussed in more detail below.

[0036] In various embodiments, the first match between the first application user credential and the stored second application user credential serves as a prerequisite to initiate and complete at least one of an online and / or offline verification, and first level access and / or second level access to one or more features of the access application 116 is not authorized until at least one of the online and / or offline verification protocol is completed. In various embodiments, the first match between the first application user credential and the stored second application user credential serves as a prerequisite to begin an online and / or offline protocol, but in response to the first match, access to first level information is authorized, and wherein second level user access requires completion of one or both of the online and / or offline protocol in addition to any other prerequisites (e.g., a second comparison associated with user information as discussed below) to authorize access to second level information.

[0037] In general, the server 120 (or another computing device) and the contactless card 101 can be provisioned with the same master key 105 (also referred to as a master symmetric key). More specifically, each contactless card 101 is programmed with a different master key 105 that has a corresponding counterpart in the server 120. For example, when the contactless card 101 is manufactured, a unique master key 105 can be programmed into the memory 102 of the contactless card 101. Similarly, the unique master key 105 can be stored in the server 120 in the record of the customer associated with the contactless card 101 (and / or in a different secure location). The master key can be kept secret from all parties other than the contactless card 101 and the server 120, thereby enhancing the security of the system 100.

[0038] The master key 105 can be used in conjunction with a counter 104 to enhance security using key diversification. The counter 104 includes a value that is synchronized between the contactless card 101 and the server 120. The counter value 104 can include a number that changes each time data is exchanged between the contactless card 101 and the server 120 (and / or the contactless card 101 and the mobile device 110). To enable NFC data transfer between the contactless card 101 and the mobile device 110, the account application 113 can communicate with the contactless card 101 when the contactless card 101 is in close enough proximity to the card reader 118 of the mobile device 110 (e.g., within NFC range). The card reader 118 can be a digital reader with NFC capabilities (e.g., an NFC reader) and can be configured to read from and / or communicate with the contactless card 101 (e.g., through NFC, Bluetooth, RFID, etc.). Thus, example card readers 118 include NFC communication modules, Bluetooth communication modules, and / or RFID communication modules.

[0039] For example, the contactless card and / or the user associated with the contactless card can need to be authenticated or verified for access to the access application 116. One or more components of the system 100, including the authentication application 114, can initiate communication (e.g., an API call or another suitable mechanism) with the access application 116 to verify or authenticate the contactless card, and / or in various embodiments, the user associated therewith, using one or more payment protocols, even if the particular aspect of the access application 116 or the user of the access application 116 seeking access does not involve making a payment.

[0040] In various embodiments, one or more payment protocols may involve online technologies as discussed elsewhere herein. The authentication application 114 may prompt a user to tap the contactless card 101 against the mobile device 110, thereby bringing the contactless card 101 sufficiently close to the reader 118 of the mobile device 110 to enable NFC data transmission between the contactless card 101 and the reader 118 of the mobile device 110. In various embodiments, the mobile device 110 may trigger the reader 118 via an API call. Furthermore, and / or alternatively, the mobile device 110 may trigger the reader 118 based on periodically polling it. More generally, the mobile device 110 may use any feasible method to trigger the reader 118 for communication.

[0041] In various embodiments, before initiating any communication related to the contactless card 101, the card reader 118, and the mobile device 110, and / or immediately after establishing communication between the contactless card 101 and the card reader 118, the authentication application 114 may receive a first application user credential as a prerequisite for card activation and / or initiating an online authentication protocol. The user may provide the first application user credential after receiving a prompt to enter credentials from the authentication application. As described above, the first application user credential may include biometric data, an established gesture associated with user identification, a username and password combination, facial recognition, etc. As described above, in various embodiments, the authentication application 114 transmits the first application user credential to the processor 119. The processor 119 compares the first application user credential with a stored second application user credential. The stored second application user credential may reside in memory 111 associated with the mobile device 110, memory 102 associated with the contactless card 101, and / or memory 122 associated with the server 120. In various embodiments, a first application user credential is provided to server 120, and server 120 compares the first application user credential with a stored second application user credential. In various embodiments, as described above, processor 119 transmits the comparison result to verification application 114 (e.g., for matching). In various embodiments, the first match may initiate or serve as a prerequisite for one or more of the following: i) initiating the remainder of an online verification protocol for verifying or authenticating a user to access application 116 and / or ii) authorizing the user to access first-level user account options associated with the user account of access application 116 (e.g., display of account balance and / or recent transactions and / or recent communications). Therefore, in various embodiments, in response to finding a first match, the verification and authentication application initiates additional operations (as associated with the online verification process) to verify the user's identity, including but not limited to authenticating a contactless card associated with the user.

[0042] In various embodiments, a second level of verification may be initiated as a further condition for starting or initiating additional operations. For example, processor 119 compares at least a portion of the user's identity with at least a portion of the cardholder identification information. In various embodiments, a second matching authorizes the user to access second-level user account options (e.g., card activation, personal identification number (PIN) change requests, and address change requests). According to various embodiments, second-level user account options represent a more secure feature associated with accessing application 116.

[0043] In various embodiments, as implied above, neither first-level nor second-level authentication is performed, and online authentication can occur directly during the establishment of communication (e.g., NFC communication) with mobile device 110, card reader 118, and contactless card 101. In various embodiments, as discussed herein, when offline authentication is used together with online authentication to authenticate the contactless card and / or the user associated with it (e.g., hybrid online / offline authentication), first-level authentication is associated with either the online or offline portion that initiates the hybrid online / offline authentication, and second-level authentication is associated with the other of the online or offline portions that initiate the hybrid online / offline authentication.

[0044] In various embodiments, a first match between the first application user credential and the stored second application user credential may authorize or not authorize first-level access to the application (e.g., access to application 116), but the first match may in any case serve as a prerequisite for initiating at least one of the online and / or offline protocols. In various embodiments where first-level access is not initially authorized, successful completion of at least one online and / or offline protocol results in authorization of first-level access. In various embodiments, second-level access to application 116 is authorized immediately after completion of at least one online and / or offline verification protocol. In various embodiments, where first-level access is authorized only after completion of at least one online and / or offline protocol, including embodiments where the first match is used or omitted, second-level access is authorized only upon successful completion of the other of at least one online and / or offline protocol, wherein in various embodiments, the other of at least one online and / or offline protocol is initiated only after a suitable component successfully completes a second match (e.g., comparing at least a portion of the user's identity with at least a portion of the cardholder identification information). In various embodiments, the successful completion of the second match itself authorizes access to the second-level features of the access application 116, and serves as a prerequisite for the completion of at least one of the offline and / or online protocols (the one not associated with the first-level access), and the successful completion of the other of the at least one offline and / or online protocols authorizes access to additional features of the access application 116.

[0045] In various embodiments, additional preconditions may be applied as conditions for initiating offline and / or online protocols, for example, as discussed elsewhere herein, offline authentication protocols may only be initiated if a network failure prevents online authentication from occurring.

[0046] In various embodiments, without considering any other preconditions, a first tap on the contactless card 101 on the mobile device 110 initiates one of the online and offline verification protocols, and a second tap (subsequent tap) initiates the other of the online and offline verification protocols.

[0047] In various embodiments, after communication is established between the mobile device 110 and the contactless card 101, the contactless card 101 generates a Message Authentication Code (MAC) cipher, regardless of whether a first-level and / or second-level and / or additional preconditions are applied or occur. In various embodiments, this may occur when the contactless card 101 is read by an account application 113. Specifically, this may occur when reading (such as NFC reading) a Near Field Data Exchange (NDEF) tag, which can be created according to an NFC data exchange format. For example, a reader such as account application 113 and / or reader 118 may transmit a message (such as a mini-program selection message) with a mini-program ID that generates the mini-program's NDEF. In various embodiments, the generated cipher may be an Authentication Request Cipher (ARQC) compliant with the EMV standard.

[0048] In various embodiments, after confirmation of selection, a sequence of selected file messages, followed by a read file message, can be transmitted. For example, the sequence might include "Select function file," "Read function file," and "Select NDEF file." At this point, the counter value 104 maintained by the contactless card 101 can be updated or incremented, followed by "Read NDEF file." A message, including a header and a shared secret, can then be generated. A session key can then be generated. A MAC cipher can be created based on a message that may include a header and a shared secret. The MAC cipher can then be concatenated with one or more random data blocks, and the MAC cipher and the random number (RND) can be encrypted using the session key. Subsequently, the cipher and header can be concatenated, encoded into ASCII hexadecimal, and returned in NDEF message format (in response to the "Read NDEF file" message). In various embodiments, the MAC cipher can be transmitted as an NDEF tag, and in other examples, the MAC cipher can be included along with a Uniform Resource Indicator (e.g., as a formatted string). The contactless card 101 can then transmit the MAC password to the mobile device 110, which can then forward the MAC password to the server 120 for authentication, as explained below. (However, in the various embodiments discussed herein (e.g., in an offline context), the mobile device 110 can authenticate the MAC password.)

[0049] More generally, when ready to send data (e.g., to server 120 and / or mobile device 110), contactless card 101 can increment counter value 104. Contactless card 101 can then provide master key 105 and counter value 104 as input to a cryptographic algorithm that produces a diversity key 106 as output. The cryptographic algorithm can include encryption algorithms, hash-based message authentication code (HMAC) algorithms, cryptographic message authentication code (CMAC) algorithms, etc. Non-limiting examples of cryptographic algorithms can include symmetric encryption algorithms (such as 3DES or AES128), symmetric HMAC algorithms (such as HMAC-SHA-256), symmetric CMAC algorithms (such as AES-CMAC), and / or any other algorithm or technique consistent with any applicable version of ISO / IEC 1833 and / or ISO / IEC 7816. Contactless card 101 can then use diversity key 106 to encrypt data (e.g., customer identifier 107 and any other data). The contactless card 101 can then transmit encrypted data (e.g., encrypted customer ID 109) to the account application 113 of the mobile device 110 (e.g., via NFC connection, Bluetooth connection, etc.). The account application 113 of the mobile device 110 can then transmit the encrypted data to the server 120 via network 130. In at least various embodiments, the contactless card 101 transmits a counter value 104 with encrypted data. In such embodiments, the contactless card 101 can transmit either an encrypted counter value 104 or an unencrypted counter value 104.

[0050] Once the encrypted customer ID 109 is received, the management application 123 of server 120 can perform the same symmetric encryption using counter value 104 as input for encryption and master key 105 as the encryption key. As stated, counter value 104 can be specified in the data received from mobile device 110, or in a counter value 104 maintained by server 120 to implement key diversification for contactless card 101. The encrypted output can be the same diversification key value 106 created by contactless card 101. Management application 123 can then use diversification key 106 to decrypt the encrypted customer ID 109 received via network 130, which reveals the data transmitted by contactless card 101 (e.g., at least customer identifier 107). This allows management application 123 to verify the data transmitted by contactless card 101 via mobile device 110, for example, by comparing the decrypted customer ID 107 with the customer ID in account data 124 of the account.

[0051] While counter 104 (e.g., ATC) is used as an example, other data can be used to secure communication between contactless card 101, mobile device 110, and / or server 120. For example, counter 104 can be replaced by a random number generated each time a new diversity key 106 is needed, the full value of the counter value sent from contactless card 101 and server 120, a portion of the counter value sent from contactless card 101 and server 120, a counter maintained independently by contactless card 101 and server 120 but not sent between them, a one-time passcode exchanged between contactless card 101 and server 120, and a cryptographic hash of the data. In various embodiments, multiple diversity keys 106 can be created by the parties using one or more portions of diversity key 106.

[0052] As shown in the figure, server 120 may include one or more Hardware Security Modules (HSMs) 125. For example, one or more HSMs 125 may be configured to perform one or more cryptographic operations disclosed herein. In various embodiments, one or more HSMs 125 may be configured as dedicated security devices configured to perform one or more cryptographic operations. HSMs 125 may be configured such that keys are never exposed outside of HSMs 125, but instead remain within HSMs 125. For example, one or more HSMs 125 may be configured to perform at least one of key derivation, decryption, and MAC operations. One or more HSMs 125 may be contained within server 120 or may communicate with the server.

[0053] As described above, key diversification techniques can be used to perform secure operations using contactless card 101. For example, once management application 123 uses key diversification to verify the encrypted customer ID 109, management application 123 can send a message to authentication application 114 instructing contactless card 101 and / or the user associated with it to be verified and / or authenticated, and as a result, authentication application 114 can authorize the user to access authentication application 116. In various embodiments, the output sent may include an Authentication Response Cipher (ARPC).

[0054] As inherent in one or more embodiments described herein (including the discussion above), server 120, which can be used for online authentication or verification or a hybrid online and offline operation, can be configured to operate in accordance with EMV standards, including being configured to perform operations utilizing the EMV payment protocol for non-payment purposes. Host server (or system) 120 may be associated with an issuer of a card associated with a user (e.g., the issuer's authentication server), and the host system includes a non-transitory computer-readable storage medium storing computer-readable program code executable by a processor, wherein the processor and storage medium may comprise one or more hardware or software components, including... Figure 8 The host system can be configured to receive transaction or communication data associated with access application 116 and / or contactless card 101. Reception of transaction or communication data can be facilitated as described herein, for example, through authentication application 114 (or other suitable components or applications of mobile device 110) associated with mobile device 110 and user (or other suitable computer device), wherein authentication application 114 can initiate authentication or verification communication with one or more other components (e.g., contactless card 101 and card reader 118). Server 120 receives transaction or communication data from authentication application 114. Transaction or communication data may include i) a counter (e.g., ATC) and a cipher for one or more inputs based on the communication and a symmetric key associated with the card. In various embodiments, the cipher is an Authentication Request Cipher (ARQC).

[0055] In various embodiments, server 120 may have a separate log (e.g., counter log 121) for recording ATC values ​​as associated with non-payment events or communications, wherein one or more inputs provided by mobile device 110 may include a designation that the event or communication is a non-payment event or communication and / or an indication of the nature of access application 116. In various embodiments, server management application 123 of server 120 may be configured to: identify that access application 116 does not have payment characteristics by retrieving designations from memory 122 (e.g., in account data 124) based on the nature of the access application (e.g., described as part of an input for a transaction, event, or communication, such as a gaming application, entertainment application, transportation application, etc.), and / or identify that the payment protocol associated with access application 116 is not used to complete the payment for verifying contactless card 101 and / or the user associated with it. In various embodiments, the same protocol can be used to make payments for accessing application 116, except that additional conditions are imposed for making payments (e.g., a first-level comparison of user credentials with stored information is performed by management application 123 to enable non-payment activities only), and a second-level comparison of user credentials with stored information is performed to enable payment activities for accessing application 116, wherein the first-level and second-level comparisons are respectively initiated by a first tap and a subsequent second tap on the contactless card 101 on mobile device 110.

[0056] In various embodiments, once server 120 receives communication or transaction data, it can send a response (e.g., from the issuer (e.g., the issuer's authentication server)) to the appropriate component of mobile device 110 (e.g., authentication application 114) to verify the identity of contactless card 101 and / or the user associated with it based on the received password. Authentication application 114 can then authorize access to relevant portions or features of access application 116. This access feature can be the first-level and / or second-level information discussed above (e.g., in embodiments where user credential comparison does not occur), and / or any other suitable feature. In various embodiments, verification is based on one or more cryptographic techniques discussed herein, including the re-creation of the symmetric key and / or the entire password (whose generation is based on the use of the symmetric key) by the issuer (e.g., the issuer's authentication server) in response to the received communication or transaction data. Because the operations described with respect to server 120 in various embodiments are associated with payment protocols (including for applications different from access application 116), the passwords and cryptographic techniques, as well as the responses sent, are based on payment protocols. However, because at least one feature associated with access application 116 is associated with a non-payment feature, and a payment protocol is executed to access that feature, contactless card verification (and the user authentication or user certification extended therefrom) is also different from payment protocols and their competition. In various embodiments, only verification received from server 120 (e.g., purely online techniques) can be used to verify or authenticate that a user has received access to one or more features of access application 116.

[0057] In various embodiments, server 120 may utilize counter log 121 to perform anti-fraud measures. In various embodiments, counter log 121 may include a timestamp associated with a counter value linked to one or more non-payment events or communications. In various embodiments, counter log 121 may include a timestamp associated with a counter value linked to one or more payment events or communications. In various embodiments, the counter value of an ATC associated with a specific event or communication (e.g., whether it's a payment event or communication or a non-payment event or communication) may also be logged. Management application 123 may be configured to compare the general number of payment events or communications occurring between non-payment events or communications. If the number of payment events or communications following a non-payment event or communication exceeds a certain threshold, management application 123 may reject the payment event or communication, even if the event or communication could otherwise be completed (e.g., since it is assumed that a user can use payment protocols for both non-payment and payment protocols, an excessive number of payment events or communications following a non-payment event or communication may be considered fraudulent). In various embodiments, the opposite can be implemented; for example, a large number of non-payment events or communications following a payment event or communication exceeding a threshold may cause the management application 123 to reject a non-payment event or communication when verification or authentication occurs. In various embodiments, a threshold related to the time between any event or communication (e.g., payment or non-payment) may cause the management application 123 to reject an authentication or verification operation, with respect to exceeding a minimum or maximum threshold. The counter log 121 can be used to perform any other suitable operations, including performing anti-fraud measures in any other suitable manner.

[0058] In addition to one or more online operations outlined herein and above, system 100 may facilitate one or more offline operations to verify or authenticate contactless cards and / or users offline, wherein, in various embodiments, the offline operations are used in conjunction with online technologies, and wherein, in various embodiments, the offline operations may be used based on preconditions (e.g., if a network failure prevents the use of one or more online operations).

[0059] In various embodiments, in a manner similar to that described herein with respect to online verification technology, verification application 114 receives a first application user credential to access one or more aspects or features of authentication application 116, wherein offline verification or authentication technology may utilize an EMV-compliant payment protocol for purposes other than completing payment events or communications. The user may provide the first application user credential after receiving a prompt from the authentication application. This first application user credential may include biometric data, an established gesture associated with user identification, a username and password combination, facial recognition, etc. In various embodiments, verification application 114 transmits the first application user credential to processor 119. Processor 119 compares the first application user credential with a stored second application user credential. The stored second application user credential may reside in memory 111 associated with mobile device 110 or memory 102 associated with contactless card 101.

[0060] In various embodiments, processor 119 transmits the comparison result to verification application 114 (e.g., for matching). In various embodiments, the first match may authorize the user to access a first-level aspect (e.g., user account options for the user account) associated with authentication application 116 (e.g., display of account balance and / or recent events or communications). In response to finding the first match, verification application 114 initiates verification or authentication of the user's identity with one or more offline actions. For example, authentication application 114 may output a notification displayed on mobile device 110 indicating that contactless card 101 has been brought near mobile device 110. Verification application 114 may then communicate with contactless card 101 (e.g., after being brought near contactless card 101). Communication between verification application 114 and contactless card 101 may involve contactless card 101 being sufficiently close to card reader 118 of mobile device 110 to enable NFC data transmission between verification application 114 and contactless card 101. In various embodiments, contactless card 101 sends the public key of the public / private key pair and cardholder identification information of the card's account holder (e.g., the contactless card and / or user to be verified or authenticated in relation to access application 116) to authentication application 114 or another suitable component or application of mobile device 110. In various embodiments, authentication application 114 may instruct contactless card 101 to generate a digital signature using the private key of the card's key pair. In various embodiments, cardholder identification information may be incorporated into the digital signature or otherwise transmitted along with the digital signature.

[0061] In various embodiments, the contactless card 101 sends a digital signature to an authentication application 114 or another suitable component or application of the mobile device 110. In various embodiments, the authentication application 114 may communicate the digital signature to a processor 119, where the processor 119 may use a public key to verify the digital signature. For example, the contactless card 101 may provide a hash of the card's public key encrypted by a trusted source (e.g., the card provider's private key), and verifying the digital signature may include: decrypting the encrypted hash (e.g., using the card provider's public key); calculating a new hash of the digital signature; and comparing the decrypted original hash with the new hash to find a match, at which point the card provider (e.g., the issuer (e.g., the issuer's authentication server)) and the transaction card can be authenticated.

[0062] In various embodiments, both reading and writing NFC capabilities can be used to perform at least a portion of offline authentication (e.g., offline dynamic data authentication) between the contactless card 101 and the user's mobile device 110. In various embodiments, utilizing NFC reading and writing capabilities offers unique advantages for more reliable (e.g., enhanced security against counterfeiting, card theft, or man-in-the-middle attacks) authentication of the contactless card 101 (and associated user) as a form of authentication when accessing one or more aspects of the access application 116. In various embodiments, in a manner similar to the embodiments described herein regarding online verification, the processor 119 compares at least a portion of the user's identity with at least a portion of the cardholder identification information. In various embodiments, a second matching authorizes the user to access second-level user account options (e.g., card activation, personal identification number (PIN) change request, and address change request) of the user account. In various embodiments, second-level user account options represent a more secure feature for accessing the application 116.

[0063] In various embodiments, as discussed and implied elsewhere herein, when offline authentication is used in conjunction with online authentication to authenticate contactless cards and / or their associated users (e.g., hybrid online / offline authentication), a first-level verification is associated with either the online or offline portion of the hybrid online / offline authentication, and a second-level verification is associated with the other of the online or offline portions of the hybrid online / offline authentication. In various embodiments, additional preconditions (such as those discussed elsewhere herein) may be applied to initiate the offline authentication protocol only if a network failure preventing online authentication from occurring.

[0064] In various embodiments, mobile device 110 and / or contactless card 101 may be configured to perform anti-fraud measures using counter log 121 (not explicitly shown for mobile device 110).

[0065] In various embodiments, for example, when both online and offline technologies are implemented, the verification of the digital signature can be performed by a server (e.g., server 120) connected to (e.g., via network 130) the mobile device 110. For example, processor 119 can output the digital signature to be sent to server 120, and server 120 can verify the digital signature.

[0066] Figure 2A This is schematic diagram 200, which illustrates an example embodiment of a tap to initiate online verification or a hybrid online and offline verification or authentication of a user (and / or their associated contactless card) for purposes other than completing a payment. The graphical user interface (GUI) of the verification application 114 on mobile device 110 may include a prompt 206 for tapping contactless card 101 to initiate authentication or verification to another application (e.g., access application 116), wherein a separate API interface may be provided to transmit the verification or authentication (once completed) to access application 116 via verification application 114. In various embodiments, access application 116 provides prompt 202 as a prerequisite for receiving tap prompt 206, or after the tap occurs but before any additional online or offline verification operation, to enter user credentials for comparison of first-level and / or second-level information access associated with access application 116 (e.g., as referenced). Figure 1 (As described). In various embodiments, the verification application 114 provides an interface or prompt 202 for entering user credentials for accessing application 116 and / or any other application (e.g., other application 115).

[0067] In various embodiments, once the contactless card 101 is touched by the mobile device 110, the authentication application 114 sends an instruction to the contactless card 101 via a card reader 118 (e.g., via NFC, Bluetooth, RFID, etc.). In various embodiments, this instruction may specify the execution of an action regarding... Figure 1One or more encryption technologies are described. In various embodiments, online authentication technology is used, and the verification application 114 receives transaction or communication data 120 from the server. In various embodiments, online and offline authentication technologies are used, and the verification application 114 and contactless card 101 utilize public / private key encryption technology to authenticate contactless card 101 and / or the user associated therewith. In various embodiments, the prompt for sending data between contactless card 101 and mobile device 110 may specify that data is sent to the authentication application 114 via any suitable protocol conforming to the EMV protocol or standard, wherein in various embodiments, the authentication application 114 receives any suitable data directly from contactless card 101 via a protocol conforming to the EMV protocol or standard. In various embodiments, a tap may be associated with one or both of the first and second level information access as described herein, wherein a first tap results in a comparison of first and / or second user and / or additional user credential information before establishing authentication and / or verification technologies (e.g., online and / or online / offline hybrid).

[0068] Figure 2B This is schematic diagram 210, which illustrates an example embodiment of a tap to initiate online verification or hybrid online and offline verification or authentication of a user using a payment protocol for purposes other than completing a payment. This includes whether online verification or authentication using server 120 is used to perform verification or authentication of contactless card 101 and / or its associated user; whether offline verification using mobile device 110, contactless card 101, and / or card reader 118 is used to perform user verification or authentication without server 120; and / or whether hybrid offline and online verification using mobile device 110, card reader 118, contactless card 101, and / or server 120 is used to perform authentication or authentication of the contactless card and / or user, mobile device 110. A message 207 indicating that access to application 116 is authorized may appear on the GUI of mobile device 110. In various embodiments, access is authorized without a message prompt.

[0069] Figure 3A This is schematic diagram 300, which illustrates an example embodiment of a tap to initiate online or offline verification or authentication of a user (and / or their associated contactless card) using a payment protocol for purposes other than completing a payment. Typically, Figures 3A-3C Various embodiments are illustrated, in which continuous tapping is used to authorize first-level information associated with an application and second-level information associated with the application, which in turn is associated with a contactless card and / or a user associated with the contactless card and the application.

[0070] For reference Figure 2ASimilarly described, the graphical user interface (GUI) of the authentication application 114 on the mobile device 110 may include a prompt 302 that initiates authentication or verification of another application (e.g., access application 116) by tapping the contactless card 101, wherein a separate API interface may be provided to transmit the authentication or verification to the access application 116 via the authentication application 114 (once completed). In various embodiments, the access application 116 provides a prompt 304 to enter user credentials for comparison of first-level information access associated with the access application 116 (e.g., as referenced) before tapping the prompt 302, as a prerequisite for tapping the prompt 302, or immediately after tapping, but before performing any additional online or offline authentication or verification operations. Figure 1 and Figure 2A (As described). In various embodiments, the authentication application 114 provides an interface or prompt 304 for entering user credentials regarding access to application 116 and / or any other application (e.g., other application 115). Once the contactless card 101 is touched to the mobile device 110, the authentication application 114 sends an instruction to the contactless card 101 via a card reader 118 (via NFC, Bluetooth, RFID, etc.). In various embodiments, this instruction may specify the execution of... Figure 1 and Figure 2A One or more encryption technologies are described. In various embodiments, the prompt 304 is provided by an application (e.g., access application 116 or verification application 114). As described above, the prompt 304 may be initiated in response to tapping a contactless card on the mobile device 110, or as a prerequisite for a valid tap.

[0071] In various embodiments, such as reference Figure 1 and Figure 2ASimilarly, a first application user credential, which may include biometric data, an established gesture associated with user identification, a username and password combination, etc., may be compared with a stored second application user credential by, for example, the processor 119 of mobile device 110. The stored second application user credential may be associated with a user identity and may be stored in the memory 111 of mobile device 110, the memory 102 of a contactless card, or the memory 122 of server 120. In various embodiments, as described above, upon determining a first match between the first application user credential and the stored second application user credential, authentication application 114 may authorize the user to access one or more first-level user account options of the user account. As described above, the user account may be a financial account, a health insurance account, and / or any other account associated with any service provider (e.g., a transit account, an entertainment account, etc.). Once verified, the user can access certain first-level user account options. First-level user account options may include the display of account balance, recent events, or communications, etc. First-level verification may also be a prerequisite for initiating offline or online authentication verification technology.

[0072] In various embodiments, once Level 1 authentication occurs, online or offline authentication as described herein takes place. In various embodiments, online authentication techniques are used, and the authentication application 114 receives event or communication data from the server 120. In various embodiments, offline authentication techniques are used, and the authentication application 114 and contactless card 101 utilize public / private key encryption to authenticate the contactless card and / or the user thereby extended. In various embodiments, the prompt for sending data between the contactless card 101 and the mobile device 110 may specify that data is sent to the authentication application 114 via any suitable protocol conforming to the EMV protocol or standard, wherein in various embodiments, the authentication application 114 receives any suitable data directly from the contactless card 101 via a protocol conforming to the EMV protocol or standard.

[0073] Such as about Figure 3B In more detail, once online or offline authentication or verification is complete, a second tap on the card can be initiated, whereby the second tap triggers another comparison of user credentials to authorize second-level access to the application associated with the user (and / or the contactless card associated with it) and perform a second authentication or verification of the user (and / or the contactless card associated with it) associated with that application, for example, if online verification or authentication was performed with respect to the first tap, then offline verification or authentication is performed with respect to the second tap, and vice versa.

[0074] Figure 3BThis is schematic diagram 310, which illustrates an example embodiment of a tap used to initiate online or offline verification or authentication of a user, for purposes other than completing a payment. In various embodiments, prompts are provided. See reference... Figure 1 , Figure 2A and Figure 3A Similarly described, the graphical user interface (GUI) of the authentication application 114 on the mobile device 110 may include a prompt 306 to initiate authentication or verification of another application (e.g., access application 116) by tapping the contactless card 101, wherein a separate API interface may be provided to transmit the authentication or verification to the access application 116 via the authentication application 114 (once completed). In various embodiments, the prompts 306 and 308 associated with schematic diagram 320 only occur after the first level of authentication has occurred and as described above. Figure 3A The access is available only after one of the online or offline verification or authentication outlined in the diagram has occurred, and the tap associated with schematic 320 will be a second tap on the contactless card 101 on mobile device 110. In various embodiments, access application 116 provides prompt 302 as a prerequisite for receiving the second tap prompt 306, or after the tap has occurred, but before any additional online or offline verification operation, to enter user credentials for comparison of second-level information access associated with access application 116 (e.g., as referenced in [reference]). Figure 1 (As described). The second level of information is in addition to... Figure 3A In addition to the first-level access described herein, additional access to more sensitive information can be provided, as already referenced. Figure 1 , Figure 2A and Figure 3A At least one of them describes the type of information and the application associated with it. In various embodiments, the verification application 114 provides an interface or prompt 308 for entering user credentials for accessing application 116 and / or any other application (e.g., other application 115).

[0075] For reference Figure 1 , Figure 2A and Figure 3A Similarly, once the contactless card 101 is lightly touched to the mobile device 110, the authentication application 114 sends an instruction to the contactless card 101 via a card reader 118 (e.g., via NFC, Bluetooth, RFID, etc.). In various embodiments, this instruction may specify the execution of actions such as... Figure 1 The one or more encryption technologies mentioned herein, in addition to those described in various embodiments, if regarding Figure 3A The online verification technology utilizing server 120 was adopted, regarding... Figure 3BOffline operations are performed, and vice versa. Once authentication is performed based on additional online or offline verification technology associated with the second tap, the user can access certain second-level user account options. In various embodiments, in a manner similar to the discussion related to the embodiments described herein, processor 119 compares at least a portion of the user's identity with at least a portion of cardholder identification information, which may reside in the memory 102 of contactless card 101, the memory 122 of a server, and / or the memory 111 of mobile device 110 (and is accessed and used accordingly depending on whether online or offline technology is employed). In various embodiments, a second matching authorizes the user's access to second-level user account options of the user account (e.g., card activation, personal identification number (PIN) change request, and address change request). In various embodiments, second-level user account options represent a more secure feature for accessing application 116.

[0076] In various embodiments, once the first level of authentication occurs, online or offline authentication occurs as described herein. In various embodiments, online authentication techniques are used, and the verification application 114 receives event or communication data from the server 120. In various embodiments, offline authentication techniques are used, and the verification application 114 and contactless card 101 utilize public / private key encryption to authenticate the contactless card and / or the user associated with it. In various embodiments, the prompt for sending data between the contactless card 101 and the mobile device 110 may specify that data is sent to the authentication application 114 via any suitable protocol conforming to the EMV protocol or standard, wherein in various embodiments, the authentication application 114 receives any suitable data directly from the contactless card 101 via a protocol conforming to the EMV protocol or standard.

[0077] Figure 3C This is schematic diagram 320, which illustrates an example embodiment of a tap to initiate online and offline verification or authentication of a user using a payment protocol for purposes other than completing a payment. Once the online and offline verification technology (which may include utilizing one or more of mobile device 110, card reader 118, contactless card 101, and server 12) is in response to... Figure 3A and Figure 3B If the described first and second taps (and the actions performed in response to comparing user credentials with stored information for first and second level access) are both adopted and completed, then a message 312 indicating that access to application 116, including first and second level information or features, is authorized may appear on the GUI of mobile device 110. In various embodiments, access is authorized without a message prompt.

[0078] Figure 4AA contactless card 101 is shown, which may include a payment card, such as a credit card, debit card, and / or gift card. As shown, the contactless card 101 may be issued by a service provider 405 displayed on the front or back of the card 101. In various embodiments, the contactless card 101 is independent of the payment card and may include, but is not limited to, an identification card. In various embodiments, the payment card may include a dual-interface contactless payment card. The contactless card 101 may include a substrate 410, which may include a single layer or one or more laminates made 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 various embodiments, the contactless card 101 may have physical properties conforming to the ID-1 format of the ISO / IEC 7810 standard, and the contactless card may additionally conform to the ISO / IEC 14443 standard. However, it should be understood that the contactless card 101 according to this disclosure may have different characteristics, and this disclosure does not require the implementation of contactless cards in payment cards.

[0079] The contactless card 101 may also include identification information 415 displayed on the front and / or back of the card, and a contact pad 420. The contact pad 420 may be configured to establish contact with another communication device, such as a mobile device 110, user equipment, smartphone, laptop, desktop computer, or tablet computer. The contactless card 101 may also include a processing circuitry, an antenna, and... Figure 4A Other components not shown. These components may be located behind the contact pad 420 or elsewhere on the base 410. The contactless card 101 may also include components that can be located on the back of the card ( Figure 4A (not shown) magnetic strips or magnetic tapes.

[0080] like Figure 4B As shown, the contact pad 420 of the contactless card 101 may include a processing circuitry system 425 for storing and processing information, which includes a microprocessor 430 and a memory 102. It should be understood that the processing circuitry 425 may include additional components necessary to perform the functions described herein, including a processor, memory, error and parity / CRC checkers, a data encoder, anti-collision algorithms, a controller, a command decoder, security primitives, and tamper-proof hardware.

[0081] Memory 102 can be a read-only memory, a write-once-read-many memory, or a read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 101 can include one or more of these memories. Read-only memory can be factory-programmable or one-time programmable. One-time programmability provides the opportunity to write once and then read many times. Write-once / read-many memory can be programmed at some point after the memory chip has left the factory. Once programmed, the memory may not be rewritten, but it may be read multiple times. Read / write memory can be programmed and reprogrammed multiple times after leaving the factory. Read / write memory can also be read multiple times after leaving the factory.

[0082] Memory 102 may be configured to store one or more applets 440, one or more counters 104, customer identifier 107, and virtual account 108. The one or more applets 440 may include one or more software applications, such as Java card applets, configured to execute on one or more contactless cards. However, it should be understood that applet 440 is not limited to Java card applets and may instead be any software application operable on a contactless card or other device with limited memory. The one or more counters 104 may include numeric counters sufficient to store integers. Customer identifier 107 may include a unique alphanumeric identifier assigned to a user of contactless card 101, and this identifier may distinguish the user of the contactless card from other contactless card users. In various embodiments, customer identifier 107 may identify both a customer and the account assigned to that customer, and may further identify the contactless card associated with that customer's account. As described above, account 108 may include thousands of one-time-use virtual accounts associated with contactless card 101. The applets 440 of contactless card 101 may be configured to manage account 108.

[0083] The processor and storage elements of the foregoing exemplary embodiments have been described with reference to the contact pad, but this disclosure is not limited thereto. It should be understood that these elements may be implemented outside of the pad 420, or completely separated from the pad, or as other elements besides the processor 430 and memory 102 elements located within the contact pad 420.

[0084] In various embodiments, the contactless card 101 may include one or more antennas 455. The one or more antennas 455 may be housed within the contactless card 101 and surrounding the processing circuitry system 425 of the contact pad 420. For example, the one or more antennas 455 may be integrated with the processing circuitry 425, and the one or more antennas 455 may be used in conjunction with an external boost coil. As another example, the one or more antennas 455 may be external to the contact pad 420 and the processing circuitry 425.

[0085] In this embodiment, the coil of the contactless card 101 can act as the secondary coil of an air-core transformer. The terminal can communicate with the contactless card 101 by cutting off power or by amplitude modulation. The contactless card 101 can infer data transmitted from the terminal using gaps in the power connection of the contactless card, which can be functionally maintained by one or more capacitors. The contactless card 101 can communicate by switching the load or load modulation on the coil of the contactless card. Load modulation can be detected in the terminal coil by interference. More generally, using antenna 455, processing circuitry 425, and / or memory 102, the contactless card 101 provides a communication interface for communication via NFC, Bluetooth, and / or Wi-Fi.

[0086] As explained above, the contactless card 101 can be built on a software platform that operates on smart cards or other devices with limited memory (such as JavaCards) and can securely execute one or more applications or applets. An applet 440 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 440 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., mobile device 110) and generate an NDEF message that includes an encrypted and secure OTP encoded as an NDEF text tag.

[0087] An example of NDEF OTP is the NDEF Short Record Layout (SR=1). In such an example, one or more applets 440 can be configured to encode the OTP into a text tag of the known NDEF Type 4 type. In various embodiments, the NDEF message may include one or more records. In addition to the OTP record, applet 440 can be configured to add one or more static tag records.

[0088] In various embodiments, one or more applets 440 can be configured to emulate RFID tags. RFID tags may include one or more polymorphic tags. In various embodiments, different cryptographic data is presented each time a tag is read, which can indicate the authenticity of the contactless card. Based on one or more applications, NFC readings of the tag can be processed, data can be sent to a server such as server 120, and the data can be verified at the server.

[0089] In various embodiments, the contactless card 101 and server 120 may include certain data that allows the card to be correctly identified. The contactless card 101 may include one or more unique identifiers (not shown). A counter 104 may be configured to increment each time a read operation occurs. In various embodiments, each time data is read from the contactless card 101 (e.g., by the mobile device 110), the counter 104 is sent to the server for verification, determining whether the counter values ​​104 are equal (as part of the verification).

[0090] One or more counters 104 can be configured to prevent replay attacks. For example, if a password has been obtained and replayed, the password is immediately rejected if counter 104 has been read, used, or otherwise ignored. If counter 104 has not yet been used, it can be replayed. In various embodiments, the counter incremented on the card differs from a counter incremented for an event or communication. Because there is no communication between the applets 440 on the contactless card 101, the contactless card 101 cannot determine the application of the transaction counter 104. In various embodiments, the contactless card 101 may include a first applet 440-1, which may be a transaction applet, and a second applet 440-2. Each applet 440-1 and 440-2 may include its own counter 104.

[0091] In various embodiments, counter 104 may be out of sync. In various embodiments, counter 104 may be incremented to account for accidental reads (such as reads at an angle) that initiate transactions, events, or communications, but the application does not process counter 104. In various embodiments, NFC may be enabled when mobile device 110 is woken up, and device 110 may be configured to read available tags, but does not take any action in response to a read.

[0092] To keep counter 104 synchronized, an application, such as a background app, can be executed. This app would be configured to detect when mobile device 110 wakes up and synchronizes with server 120, which in turn indicates the reads that occurred due to the detection, and then advance counter 104. In other examples, a hashed one-time password could be used, allowing for a window of acceptable missynchronization. For example, if it's within a threshold of 10, counter 104 could be configured to advance. However, if it's within a different threshold number, such as 10 or 1000, requests for resynchronization could be handled, requesting the user to perform a resynchronization via one or more apps, asking the user to tap, gesture, or otherwise indicate this once or multiple times. If counter 104 increments in the appropriate order, it can be known that the user has done so.

[0093] The key diversification technique described herein with reference to counter 104, master key 105, and diversified key 106 is an example of encryption and / or decryption using key diversification techniques. This example key diversification technique should not be considered a limitation of this disclosure, as this disclosure is equally applicable to other types of key diversification techniques.

[0094] During the creation of the contactless card 101, two unique cryptographic keys can be assigned to each card. These cryptographic keys can include symmetric keys, which can be used for data encryption and decryption. The EMV can use the Triple DES (3DES) algorithm, and it is implemented by hardware within the contactless card 101. By using a key diversification process, one or more keys can be derived from the master key based on the unique identifiable information of each entity requiring a key.

[0095] In various embodiments, to overcome the potential vulnerability of the 3DES algorithm, session keys (e.g., unique keys for each session) can be derived, but instead of using a master key, unique card-derived keys and counters can be used as diversified data. For example, each time the contactless card 101 is used in operation, a different key can be used to create a Message Authentication Code (MAC) and perform encryption. This results in triple encryption. Session keys can be generated by one or more applets and derived using an Application Transaction Counter (ATC) and one or more algorithms (as defined in EMV 4.3, Volume 2, A1.3.1, Public Session Key Derivation).

[0096] Furthermore, the increment for each card can be unique and can be assigned through personalization or by an algorithm based on some identifying information. For example, odd-numbered cards can be incremented by 2, and even-numbered cards by 5. In various embodiments, the increment can also vary during sequential reading, allowing a card to increment sequentially by 1, 3, 5, 2, 2, ... and repeat. Specific sequences or algorithmic sequences can be defined during personalization or from one or more processes derived from a unique identifier. This makes it more difficult for a replay attacker to generalize from a small number of card instances.

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

[0098] Figure 5 An embodiment of logic flow 500 is illustrated. Logic flow 500 may represent some or all of the operations performed by one or more embodiments described herein. For example, logic flow 500 may include some or all of the operations of verifying or authenticating a user using online authentication payment technology, but at least in part for a purpose different from completing an EMV-compliant payment. The embodiments are not limited to this context.

[0099] As shown in the figure, the logic flow 500 begins at block 505, where at least one of the verification application 114, operating system 112, management application 123, and / or any other suitable application can initiate a transaction, event, or communication to verify the contactless card, and in various embodiments, this is thereby extended to verifying the identity of the user associated with the contactless card 101. In various embodiments, verification can be initiated by tapping the contactless card 101 on the mobile device 110. In various embodiments, the access application 116 provides a prompt with preconditions for receiving the tap prompt, or immediately after the tap occurs but before any additional online verification operation, to enter user credentials for comparison with first-level and / or second-level information access associated with the access application 116, wherein the nature of the first-level and / or second-level information and / or features is described elsewhere herein. In various embodiments, the user credentials are associated with a user profile and are entered into an interface provided by the mobile device 110, wherein, as described above, the first application user credentials may include biometric data, an established gesture associated with user identification, a username and password combination, etc. The first application user credential can be sent by the verification application 114 to the management application 123 of the server 120, wherein the first application user credential is compared with the stored second credential.

[0100] At block 510, and according to various embodiments, if a match is found, communication is initiated between mobile device 110 and contactless card 101, wherein this communication utilizes card reader 118 and is based on the NFC protocol. In various embodiments, instead of sending a first application credential for comparison at server 120, a comparison is made between mobile device 110 and contactless card 101, wherein the stored second credential is stored in the memory 102 of the contactless card. In various embodiments, the comparison of user credentials is omitted, and a tap on contactless card 101 on mobile device 110 prompts a selection of which application (e.g., accessing application 116) requires authentication, and NFC communication between contactless card 101 and mobile device 110 initiates online verification or authentication of the user using an EMV-compliant payment protocol, but for purposes including verification or authentication for other purposes beyond simply completing a sale or purchase. In various embodiments, a tap or user credential comparison may be a prerequisite for the occurrence of a tap or user credential comparison, and thus extends to serve as a prerequisite for the remaining processes associated with process 500.

[0101] At block 515, and according to various embodiments, contactless card 101 can provide one or more inputs to mobile device 110 through communication with the card and as part of a transaction, event, or communication. These multiple inputs include an Application Transaction Counter (ATC), and at block 520, contactless card 101 communicating with mobile device 110 can generate a cipher (e.g., ARQC) based on the multiple inputs of the transaction, event, or communication, and a symmetric key associated with the card. In various embodiments, blocks 515 and 520 can be combined into a single or concurrent sequence. In various embodiments, the operations can be performed independently. In various embodiments, mobile device 110 receiving inputs and contactless card generating a cipher may involve one or more operations. This operation may involve authentication application 114 sending an instruction to contactless card 101 via NFC reader 118 specifying the generation and transmission of encrypted data. This operation may also include: in response to receiving an instruction to generate encrypted data, contactless card 101 incrementing a counter value 104 in memory 102. The operation may further include: the contactless card 101 generating a diversified key 106 using a counter value 104 in memory 102, a master key 105, and a cryptographic algorithm. The operation may also include: the contactless card 101 encrypting data (e.g., a customer indicator 107) using the diversified key 106 and the cryptographic algorithm to generate encrypted data (e.g., an encrypted customer ID 109). The operation may further include: the contactless card 101 sending the encrypted data (e.g., using NFC) to an authentication application 114 of the mobile device 110. In various embodiments, the contactless card 101 also includes an indication of the counter value 104 and the encrypted data.

[0102] At block 525, the authentication application 114 of mobile device 110 may send data received from contactless card 101 to the management application 123 of server 120 (as described above, which may be associated with the issuer of contactless card 101). At block 530, mobile device 110 may receive a response from the issuer, based on the sent password (and other sent information), to authenticate the contactless card and / or, as a result, the user identity of the contactless card's user via server 120, wherein the received response is based on the re-creation of the symmetric key and / or the entire password by the issuer (e.g., the issuer's authentication server) in response to the received password (e.g., at server 120 associated with the issuer (generated on one side using the symmetric key)). In various embodiments, one or more operations are associated with block 525. These operations may include server 123 of server 120 generating a diversified key 106 using master key 105 and counter value 104 as input to a cryptographic algorithm. In various embodiments, management application 123 uses counter value 104 provided by contactless card 101. In various embodiments, the management application 123 increments the counter value 104 in memory 122 to synchronize the state of the counter value 104 in memory 122 with the counter value 104 in memory 102 of the contactless card 101. Therefore, in various embodiments, not only is the user (and / or the contactless card) authenticated, but the counter (e.g., ATC) is synchronized between the contactless card 101 and the server 120, which can reduce errors in processing subsequent transactions, events, or communications.

[0103] In various embodiments, with Figure 5 The associated operations and boxes described above are consistent with the EMV standard, and the generated password and the associated received response are part of the payment protocol, except that when initiated by the access authentication application 114, the verification and authentication derived from the execution of the payment protocol are used for purposes other than completing the payment, such as obtaining access to one or more non-payment features of the access application 116.

[0104] Figure 6 An embodiment of logic flow 600 is illustrated. Logic flow 600 may represent some or all of the operations performed by one or more embodiments described herein. For example, logic flow 600 may include operations utilizing... Figure 5 The verification or authentication operation is associated with an updated ATC to perform anti-fraud measures. Examples are not limited to this context.

[0105] As shown in the figure, logic flow 600 is... Figure 5 The process begins after one or more operations are completed, wherein in various embodiments, the process begins at... Figure 5Box 530. At box 610, an updated version of the ATC is stored on a host device (e.g., server 120) associated with the issuer. Therefore, in various embodiments, process 600 is... Figure 5 Associated with at least one embodiment, the ATC is stored in a counter log 121 of server 120, and there is synchronization between the ATC of contactless card 101 and the ATC stored in server 120. At block 615, anti-fraud measures can be performed by server 120 using the ATC. In various embodiments, counter log 121 may include a timestamp associated with a counter value associated with one or more non-payment events or communications, wherein the timestamp may be recorded by an internal counter or timing device of server 120 communicating with management application 123, and wherein management application 123 uses a timing device or clock device to record the timing of events or communications. In various embodiments, counter log 121 may include a timestamp associated with a counter value associated with one or more payment events or communications, wherein the timestamp may also be recorded by an internal counter or timing device communicating with management application 123, and wherein management application 123 uses a timing device or clock device to record the timing of events or communications. In various embodiments, the ATC count value associated with a specific event or communication (e.g., whether it is a paying event or communication or a non-paying event or communication) may also be recorded by the management application 123. In various embodiments, the management application 123 may be configured to identify any event or communication originating from the authentication application 114 as a non-paying event or communication, regardless of its specific nature, and to identify any other event or communication utilizing user credentials as a paying event or communication. Alternatively, the management application 123 may utilize the Level 1 and Level 2 user credential schemes outlined herein as a mechanism for determining when an event or communication is a paying or non-paying event or communication; for example, if the event or communication utilizes the operation of server 120 to perform authentication, and if both Level 1 and Level 2 access are authorized, then it is a paying event or communication; otherwise, it is a non-paying event or communication. Any other suitable techniques may be used to distinguish and record events or communications as paying or non-paying events or communications.

[0106] In various embodiments, as described above, management application 123 can be configured to compare the general number of payment events or communications occurring between non-payment events or communications. If the number of payment events or communications following a non-payment event or communication exceeds a certain threshold, management application 123 can reject the payment event or communication, even if the event or communication could otherwise be completed (e.g., since it is assumed that a user can use payment protocols for both non-payment and payment protocols, an excessive number of payment events or communications following a non-payment event or communication can be considered fraudulent). In various embodiments, the opposite can be implemented; for example, a large number of non-payment events or communications performed after payment events or communications exceeding a threshold may cause management application 123 to reject a non-payment event or communication when verification or authentication occurs. In various embodiments, a threshold related to the time between any event or communication (e.g., payment or non-payment) can cause management application 123 to reject an authentication or verification operation, with respect to exceeding a minimum or maximum threshold. Counter log 121 can be used to perform any other suitable operations, including performing anti-fraud measures in any other suitable manner.

[0107] Figure 7A An embodiment of logic flow 700A is illustrated. Logic flow 700A may represent some or all of the operations performed by one or more embodiments described herein. For example, logic flow 700A may include some or all of the operations of performing online and offline verification and authentication of a user using a payment protocol, but for purposes other than authentication or verification to complete a payment. The embodiments are not limited to this context.

[0108] Typically, in various embodiments, boxes 710-725 correspond to offline verification techniques, while boxes 730-745 correspond to online verification techniques. Either or both of the offline or online verification techniques can be initiated first or second, and each can operate independently of the other; in various embodiments, verification may be performed using one instead of the other.

[0109] As shown in the figure, logic flow 700 begins at block 705, where an application (e.g., authentication application 114 of mobile device 110) communicates with contactless card 101. In various embodiments, authentication application 114 receives a first application user credential associated with a user profile from the user. In various embodiments, communication is initiated by tapping mobile device 110 with contactless card 101. As described above, the user can provide the first application user credential after receiving a prompt from authentication application 114. In various embodiments, as described above, the first application user credential may include biometric data, an established gesture associated with user identification, a username and password combination, etc. In various embodiments, processor 119 compares the first application user credential with a stored second application user credential. The stored second application user credential may be associated with a user identity. User identity may include a personal identification number (PIN), user name, address, date of birth, etc. In various embodiments, after finding a first match, the verification application 114 authorizes access to first-level user account options, including account display, recent transactions, events, communications, etc. In response to finding a match, the mobile device 110 partially verifies the user identity and initiates an offline verification process by proceeding to one or more of boxes 710-725 (or alternatively, initiates an online verification process and proceeds to one or more of boxes 730-745). In various embodiments, user credential comparison is completely skipped (not performed). At box 710, the verification application 114 receives the public key of the public / private key pair of the contactless card 101. In various embodiments, the verification application 114 may also receive card information from the contactless card 108. Card information may include cardholder information, such as a personal identification number (PIN), user name, address, date of birth, etc.

[0110] At box 715, the verification application 114 instructs the contactless card 101 to generate a digital signature using the private key of the card's key pair. The contactless card 101 generates the digital signature, and at box 720, the verification application 114 receives the digital signature from the contactless card 101, and at box 725, the mobile device can verify the digital signature using the public key of the card's key pair (through the operation of the processor 119 and / or by utilizing an application, such as the verification application 114).

[0111] Once offline verification is complete, the online operation associated with boxes 730-745 can occur (or the offline operation can occur if the online operation occurs first). In various embodiments, as a prerequisite for online operation (or the occurrence of offline operation), the processor 119 of the mobile device 110 can compare the card information with the user account (as described above). For example, the processor 119 can compare the user identity with cardholder identification information (as described above). In some embodiments, after verification using the contactless card 101, the verification application 114 authorizes access to second-level user account options, such as card activation, personal identification number (PIN) change requests, address change requests, etc., and / or similar (and as may be described elsewhere herein). Second-level user account options may have higher security requirements than first-level user account options, and in various embodiments, second-level user account options are authorized only after online (or offline) verification, such as only after comparing the user's identity with cardholder information, and after online verification, for example, online (or offline) verification is an additional requirement for granting second-level account options.

[0112] In various embodiments, a first tap on the contactless card 101 serves as a prerequisite for accessing Level 1 information (and / or performing online or offline operations), while a second tap on the contactless card 101 on the mobile device 110 serves as a prerequisite for accessing Level 2 information (and / or performing online or offline operations). The first and second taps can replace any user credential and / or user information comparison, and / or can serve as additional prerequisites for performing online and / or offline operations and / or accessing Level 1 and / or Level 2 information. In various embodiments, user credential and information comparison and tapping can be omitted, and offline and / or online operations can be the basis for accessing Level 1 and / or Level 2 information.

[0113] In various embodiments, boxes 730-745 correspond to operations substantially similar to those described with respect to boxes 515-530. In various embodiments, once verification (e.g., completion of online verification) is received at box 745 from the issuer (e.g., the issuer's authentication server), the ATC 104 associated with the server 120 performing the online verification can be synchronized with the ATC 104 of the contactless card 101 because a single transaction, event, or communication has occurred and the verification application 114 can be instructed, as part of its communication in one or more operations associated with boxes 730-745, that if an upsell transaction occurred when offline verification occurred, no additional upsell transaction is required in the contactless card 101 when running the online operation (and vice versa).

[0114] Figure 7B An embodiment of logic flow 700B is illustrated. Logic flow 700B may represent some or all of the operations performed by one or more embodiments described herein. For example, logic flow 700B may include some or all of the operations of utilizing a payment protocol to perform online and offline verification and authentication of a user, but for purposes other than authentication or verification to complete a payment. The embodiments are not limited to this context.

[0115] At block 750, to authorize user access to application 116 (e.g., access to one or more features), authentication application 114 may transmit a first application user credential to processor 119. In various embodiments, communication is initiated by tapping a contactless card 101 on mobile device 110. In various embodiments, processor 119 compares the first application user credential with a stored second application user credential. The stored second application user credential may reside in memory 111 associated with mobile device 110, memory 102 associated with contactless card 101, and / or memory 122 associated with server 120. In various embodiments, the first application user credential is provided to server 120, and server 120 compares the first application user credential with the stored second application user credential. In various embodiments, as described above, processor 119 transmits the comparison result to authentication application 114 (e.g., for matching). At block 755, once the appropriate components of the mobile device (e.g., processor 119) and / or the appropriate components of the contactless card and / or the appropriate components of server 120 (e.g., management application 123) are available, authentication application 114 may initiate at least one of the following operations: i) one or more hostless (e.g., serverless operation) operations (e.g., offline protocol) and / or ii) one or more authentication server authentication operations (e.g., online protocol or operation associated with the server). In various embodiments, block 750 is omitted, and no matching or comparison is performed with respect to block 750, and the process proceeds directly to block 760. In various embodiments, if a comparison verifies a match between the first user credential and the stored second credential, partial access to one or more features of access application 116 (e.g., first-level access) is authorized. In various embodiments, first-level access is authorized only if at least one of the authentication server or hostless authentication operations is also successfully performed and the contactless card (and / or user) is accordingly verified or authenticated. Both hostless and authentication server verification operations are associated with payment protocols compliant with EMV standards, at least one of which can be used to enable non-payment features, which are different from the payment features associated with completing a payment.

[0116] At box 760, verification application 114 determines whether the authentication server verification protocol can be executed. For example, management application 123 may refuse verification a because the user account has been reserved, where the rejection is sent to the verification application, and / or verification application 114 may determine a network failure. If verification application 114 determines that authentication server verification or the authentication protocol can be executed, process 700B can proceed to box 762, and only issuer verification operations are performed to verify and / or authenticate the contactless card and / or the user associated with it. In various embodiments, the execution at box 762 is related to... Figure 5 One or more associated operations are performed to execute an authentication server verification operation and authenticate the contactless card and / or user associated therewith, including ensuring that the application transaction counter value 104 of server 120 is recent and up-to-date. In various embodiments, after the authentication server verification operation is performed at block 762, and if the contactless card and the thereby extended user associated therewith are successfully verified according to those verification operations, a second level of access is granted to additional features associated with access application 116. In various embodiments, the additional requirement for receiving the second level of access involves the server's management application 123 performing a second comparison, such as comparing at least a portion of the user's identity with at least a portion of cardholder identification information (wherein the cardholder information may be provided from contactless card 101 and / or mobile device). Note that the types of first and / or second level access have already been outlined above with respect to one or more other embodiments of this disclosure. In various embodiments, once the authentication server verification operation and / or the second level user comparison occur, process 700A ends without performing offline (e.g., hostless) operations.

[0117] If the issuer (e.g., an authentication server) or host-based protocol (e.g., an online protocol) may not be executed, process 700B may proceed to box 765. At box 765, a second comparison of the user identity with cardholder identification information is performed as a prerequisite for continuing the process, and a successful second comparison may or may not involve authorizing second-level access because no offline or online verification has occurred at this stage of the process. In various embodiments, processor 119 compares at least a portion of the user identity with at least a portion of the cardholder identification information, wherein the cardholder identification information is transmitted to mobile device 110 (e.g., processor 119 of mobile device 110) as a result of NFC communication between contactless card 101 and mobile device 110. If no match is found at box 767, verification ends. In various embodiments, as a result of process 700B ending at box 767, access to one or more features of access application 116 is denied, wherein this denial may or may not result in denial of first-level and / or second-level access to access application 116. In various embodiments, the second user credential comparison (and / or the first user credential comparison in box 750) is omitted, and the process proceeds directly from box 760 to box 770.

[0118] If the comparison in box 767 is successful (e.g., a match is determined) and / or if the operation in box 767 is omitted, process 700B can proceed to box 770. At box 770, the verification application 114 determines whether the authentication server protocol or operation is unable to be performed due to a network or technical failure. If the verification application 114 is unable to be performed due to a network or technical failure, process 700A proceeds to box 775 and performs a hostless or offline protocol, wherein the offline protocol may include one or more offline operations outlined herein, including... Figure 7A Operation of boxes 705-725. In various embodiments, box 775 may require a second tap on contactless card 101 before initiating offline operation. In various embodiments, successful completion of offline operation provides second-level access in addition to first-level access already authorized as a result of operation associated with a previous box (e.g., box 750), and / or, if first-level access was not previously authorized, successful completion of offline operation authorizes first-level and / or second-level access with respect to access application 116.

[0119] In various embodiments, process 700B proceeds from block 775 to block 780. At block 780, as a result of completed offline verification or authentication, verification application 114 retrieves an updated ATC value 104 from contactless card 101. The updated ATC value 104 is stored in memory associated with mobile device 110. At block 785, verification application 114 continuously polls the network associated with facilitating communication between server 120 and mobile device 110 to determine when the connection is restored, and / or otherwise determine when the technical fault preventing communication between server 120 and mobile device 110 subsides. Once the network connection is restored, at block 790, the updated ATC value 104 is transmitted from mobile device 110 to server 120 to synchronize data between contactless card 101 and server 120, which can prevent verification or authentication errors from occurring at subsequent times, such as subsequent verifications.

[0120] In various embodiments, if at block 770, the verification application 114 determines that the authentication server operation may not be performed as a result unrelated to a technical failure, then process 700B ends without authorizing access to one or more aspects of the access application 116, including first-level and / or second-level access with respect to the access application 114.

[0121] In various embodiments, the contactless card 101 can be tapped on a device (such as one or more computer kiosks or terminals) to verify identity and receive a transaction item, such as coffee, in response to a purchase. By using the contactless card 101, a secure method for verifying identity in loyalty programs can be established. Secure identity verification can be established in a way that differs from simply scanning a barcode card, for example, to receive rewards, coupons, offers, or benefits. For example, encrypted transactions can occur between the contactless card 101 and a device that can be configured to process one or more tap gestures. As explained above, one or more applications can be configured to verify the user's identity and then enable the user to act or respond to it, for example, through one or more tap gestures. In various embodiments, data such as bonus points, loyalty points, reward points, healthcare information, etc., can be written back to the contactless card.

[0122] In various embodiments, the contactless card 101 can be tapped on a device, such as a mobile device 110. As explained above, the user's identity can be verified by one or more applications, which then grant the user the desired benefits based on the identity verification.

[0123] In various embodiments, the example authentication communication protocol may mimic an offline dynamic data authentication protocol with some modifications to the EMV standard typically performed between a transaction card and a point-of-sale device. For example, because the example authentication protocol itself is not used to complete a payment transaction with the card issuer / payment processor, no data value is required, and authentication can be performed without involving a real-time online connection with the card issuer / payment processor. As is known in the art, a point-of-sale (POS) system submits a transaction, including a transaction value, to the card issuer. Whether the issuer approves or rejects the transaction may be based on whether the issuer recognizes the transaction value. Meanwhile, in some embodiments of this disclosure, transactions originating from mobile devices lack a transaction value associated with the POS system. Therefore, in various embodiments, a spurious transaction value (i.e., a value recognizable by the card issuer and sufficient to allow activation) may be transmitted as part of the example authentication communication protocol. POS-based transactions may also be rejected based on the number of transaction attempts (e.g., a transaction counter). An attempt exceeding a buffer value may result in a soft rejection; a soft rejection requires further verification before accepting the transaction. In some embodiments, the buffer value of the transaction counter may be modified to avoid rejecting legitimate transactions.

[0124] In various embodiments, the contactless card 101 can selectively communicate information based on the receiving device. Upon being tapped, the contactless card 101 can identify the device to which the tap was made, and based on this identification, the contactless card can provide the appropriate data to that device. This advantageously allows the contactless card to transmit only the information necessary to complete an immediate action or transaction, such as payment or card authentication. By limiting data transmission and avoiding unnecessary data transmission, both efficiency and data security can be improved. Information identification and selective communication can be applied to various scenarios, including card activation, balance transfer, account access attempts, commercial transactions, and step-up fraud reduction.

[0125] If the tap of contactless card 101 is aimed at running Apple... For devices with operating systems such as iPhones, iPods, or iPads, contactless cards can be recognized. The operating system transmits appropriate data to communicate with the device. For example, contactless card 101 can provide encrypted identity information required for authenticating the card using an NDEF tag, for example, via NFC. Similarly, if the contactless card is tapped against the operating system... Operating system devices, for example, For smartphones or tablets, contactless cards can be recognized. The operating system transmits appropriate data (such as encrypted identity information required for authentication via the methods described herein) to communicate with this device.

[0126] As another example, a contactless card tap can be targeted at a POS device, including but not limited to kiosks, checkout registers, payment stations, or other terminals. When a tap is performed, the contactless card 101 can identify the POS device and transmit only the information necessary for the action or transaction. For example, after identifying a POS device for completing a commercial transaction, the contactless card 101 can transmit the payment information required to complete the transaction via EMV standard communication.

[0127] In various embodiments, the POS device participating in a transaction can request or specify additional information to be provided by the contactless card, such as device-specific information, location-specific information, and transaction-specific information. For example, once the POS device receives data communication from the contactless card, it can identify the contactless card and request additional information required to complete the action or transaction.

[0128] In various embodiments, the POS device may be attached to an authorized merchant or other entity familiar with or accustomed to performing certain contactless card transactions. However, it should be understood that the implementation of the described methods does not require such an attachment.

[0129] In various embodiments, such as shopping malls, grocery stores, convenience stores, etc., a contactless card 101 can be tapped onto a mobile device without having to open an application to indicate the expectation or intention to cover one or more purchases using reward points, loyalty points, coupons, offers, etc. Thus, the intent behind the purchase is provided.

[0130] In various embodiments, one or more applications may be configured to determine that it is initiated via one or more tap gestures of contactless card 101, such that the initiation occurs at 3:51 pm and the transaction is processed or made at 3:56 pm, in order to verify the user's identity.

[0131] In various embodiments, one or more applications may be configured to control one or more actions in response to one or more tap gestures. For example, one or more actions may include collecting rewards, collecting points, determining the most important purchase, determining the cheapest purchase, and / or reconfiguring to another action in real time.

[0132] In various embodiments, data regarding tapping behavior can be collected for biometric / gesture authentication. For example, a unique identifier that is cryptographically secure and difficult to intercept can be transmitted to one or more backend services. The unique identifier can be configured to look up secondary information about an individual. This secondary information may include personally identifiable information about the user. In various embodiments, this secondary information may be stored on a contactless card.

[0133] In various embodiments, the device may include an application for splitting payments of bills or checks among multiple individuals. For example, each person may have a contactless card and may be a customer of the same issuing financial institution, but this is not required. Each of these individuals can receive push notifications on their device via the application to split purchases. Other contactless cards may be used instead of just one card tap to indicate payment. In various embodiments, individuals with different financial institutions may have contactless cards 101 to provide information to initiate one or more payment requests from the card-tapping individual.

[0134] In various embodiments, this disclosure relates to tapping a contactless card. However, it should be understood that this disclosure is not limited to tapping, and that it includes other gestures (e.g., waving or other movement of the card).

[0135] Figure 8 An embodiment of an exemplary computing architecture 800 including a computing system 802 is illustrated, which can be adapted to implement various embodiments as described above. In various embodiments, the computing architecture 800 may include or be implemented as part of an electronic device. In various embodiments, the computing architecture 800 may represent, for example, a system implementing one or more components of system 100. In various embodiments, the computing system 802 may represent, for example, a mobile device 110 and a server 120 of system 100. The embodiments are not limited thereto. More generally, the computing architecture 800 is configured to implement the embodiments described herein. Figures 1 to 6 The complete logic, application, system, method, device, and function described.

[0136] As used herein, the terms “system,” “component,” and “module” are intended to refer to computer-related entities, hardware, combinations of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture 800. For example, a component can be, but is not limited to, a process running on a computer processor, a computer processor, a hard disk drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable file, an executing thread, a program, and / or a computer. For example, both an application running on a server and the server itself can be components. One or more components may reside in a process and / or an executing thread, and components may reside on a single computer and / or be distributed across two or more computers. Furthermore, components can communicatively couple with each other through various types of communication media to coordinate operations. Coordination may include one-way or two-way information exchange. For example, components may communicate by transmitting information in the form of signals transmitted via a communication medium. This information can be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, alternative embodiments may employ data messages. Such data messages can be sent through various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0137] The computing system 802 includes various common computing elements, such as one or more processors, multi-core processors, coprocessors, processing circuitry, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, sound cards, multimedia input / output (I / O) components, power supplies, and so on. However, embodiments are not limited to those implemented by the computing system 802.

[0138] like Figure 8 As shown, the computing system 802 includes a processor 804, a system memory 806, and a system bus 808. The processor 804 can be any of a variety of commercially available computer processors or computer processing circuits, including but not limited to... and processor; Application, embedded, and security processors; and and Processors; IBM and Cell processor; Core(2) and Processor; and similar processors. Dual microprocessors, multi-core processors, and other multiprocessor architectures can also be used as processor 804. Processor 804 can be configured by associated memory instructions contained in system memory 806 such that when instructions are executed on processor (e.g., processor circuitry) 804, the processor can perform operations similar to...Figures 5-7B Any one or more associated operations and / or any other operations or techniques disclosed herein.

[0139] System bus 808 provides interfaces for system components, including but not limited to the interface between system memory 806 and processor 804. System bus 808 can be any of several types of bus architectures, which can also interconnect to memory buses (with or without memory controllers), peripheral buses, and local buses using any of a variety of commercially available bus architectures. Interface adapters can be connected to system bus 808 via slot architectures. Example slot architectures may include, but are not limited to, Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, PCMCIA, etc.

[0140] System memory 806 may include various types of computer-readable storage media in the form of one or more high-speed memory cells, such as read-only memory (ROM), random access memory (RAM), dynamic random access memory (DRAM), dual data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEROM), flash memory (e.g., one or more flash memory arrays), polymer memory such as ferroelectric polymer memory, bidirectional memory, phase-change or ferroelectric memory, silicon oxide nitride silicon oxide (SONOS) memory, magnetic cards or optical cards, device arrays such as redundant array of independent disks (RAID) drives, solid-state memory devices (e.g., USB memory, solid-state drives (SSDs)), and any other type of storage medium suitable for storing information. Figure 8 In the illustrated embodiment, system memory 806 may include non-volatile memory 810 and / or volatile memory 812. The Basic Input / Output System (BIOS) may be stored in non-volatile memory 810.

[0141] The computing system 802 may include various types of computer-readable storage media in the form of one or more low-speed storage units, including an internal (or external) hard disk drive (HDD) 814, a floppy disk drive (FDD) 816 for reading from or writing to a removable disk 818, and an optical disc drive 820 for reading from or writing to a removable optical disc 822 (e.g., a CD-ROM or DVD). The HDD 814, FDD 816, and optical disc drive 820 may be connected to the system bus 808 via an HDD interface 824, an FDD interface 826, and an optical disc drive interface 828, respectively. The HDD interface 824 for an external drive implementation may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies. The computing system 802 is generally configured to implement the embodiments described herein. Figure 1 All logic, systems, methods, devices, and functions described in Figure 7.

[0142] The drive and associated computer-readable medium provide volatile and / or non-volatile storage for data, data structures, computer-executable instructions, etc. For example, multiple program modules may be stored in the drive and memory units 810, 812, including an operating system 830, one or more applications 832, other program modules 834, and program data 836. In various embodiments, one or more applications 832, other program modules 834, and program data 836 may include, for example, various applications and / or components of system 100, such as OS 112, account application 113, authentication application 114, other applications 115, access application 116, and management application 123.

[0143] Users can input commands and information into the computing system 802 through one or more wired / wireless input devices, such as a keyboard 838 and a pointing device (such as a mouse 840). Other input devices may include microphones, infrared (IR) remote controls, radio frequency (RF) remote controls, game pads, styluses, card readers, dongles, fingerprint readers, gloves, graphics tablets, joysticks, keyboards, retina readers, touchscreens (e.g., capacitive touchscreens, resistive touchscreens, etc.), trackballs, touchpads, sensors, styluses, etc. These and other input devices are typically connected to the processor 804 via an input device interface 842 coupled to the system bus 808, but may also be connected via other interfaces such as parallel ports, IEEE 1394 serial ports, game ports, USB ports, IR interfaces, etc.

[0144] Monitor 844 or other types of display devices are also connected to system bus 808 via an interface such as video adapter 846. Monitor 844 can be internal or external to computing system 802. In addition to monitor 844, computers typically include other peripheral output devices such as speakers, printers, etc.

[0145] Computing system 802 can operate in a networked environment using logical connections to one or more remote computers (e.g., remote computer 848) via wired and / or wireless communications. Remote computer 848 may be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer-to-peer device, or other public network node, and typically includes many or all of the elements described relative to computing system 802, although for simplicity only memory / storage device 850 is shown. The depicted logical connections include wired / wireless connections to a local area network (LAN) 852 and / or a larger network (e.g., a wide area network (WAN) 854). 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 connect to global communication networks, such as the Internet. In embodiments, Figure 1 Network 130 is one or more of LAN 852 and WAN 854.

[0146] When used in a LAN networking environment, the computing system 802 is connected to the LAN 852 via a wired and / or wireless communication network interface or adapter 856. The adapter 856 facilitates wired and / or wireless communication to the LAN 852, which may also include a wireless access point configured thereon for communicating with the wireless functionality of the adapter 856.

[0147] When used in a WAN networking environment, computing system 802 may include a modem 858, or a communication server connected to WAN 854, or other means for establishing communication over WAN 854, such as via the Internet. Modem 858 (which may be internal or external, and wired and / or wireless) is connected to system bus 808 via input device interface 842. In a networked environment, program modules or portions thereof depicted relative to computing system 802 may be stored in remote memory / storage device 850. It should be understood that the network connections shown are exemplary, and other means of establishing communication links between computers may be used.

[0148] The computing system 802 is operable to communicate with wired and wireless devices or entities using the IEEE 802 series of standards, such as operable to configure wireless devices in wireless communication (e.g., IEEE 802.16 air modulation technology). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth wireless technologies. Therefore, communication can be a predefined structure like a regular network, or simply ad hoc communication between at least two devices. Wi-Fi networks use radio technology known as IEEE 802.11x (a, b, g, n, etc.) to provide secure, reliable, and fast wireless connectivity. Wireless networks can be used to interconnect computers, connect to the Internet, and connect to wired networks (which use media and functions associated with IEEE 802.3).

[0149] Various embodiments may be implemented using hardware elements, software elements, or a combination of both. Examples of hardware elements may include processors, microprocessors, circuits, 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), logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software may include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application interfaces (APIs), instruction sets, computational code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an embodiment is implemented using hardware elements and / or software elements can vary depending on many factors, such as desired computational speed, power levels, thermal tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints.

[0150] At least one or more aspects of various embodiments can be implemented by representative instructions stored on a machine-readable medium, representing various logic within a processor, which, when read by a machine, cause the machine-made logic to perform the techniques described herein. Such a representation, referred to as an "IP core," can be stored on a tangible machine-readable medium and supplied to various customers or manufacturing facilities for loading into manufacturing machines that produce logic or processors. Various embodiments can be implemented, for example, using a machine-readable medium or article that can store instructions or a set of instructions that, if executed by a machine, can cause the machine to perform the methods and / or operations according to the embodiments. Such a machine can include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and can be implemented using any suitable combination of hardware and / or software. Machine-readable media or articles may include, for example, any suitable type of memory unit, memory device, memory article, storage medium, storage device, storage article, storage medium and / or storage unit, such as memory, removable or non-removable media, erasable or non-erasable media, writable or rewritable media, digital or analog media, hard disk, floppy disk, optical disc read-only memory (CD-ROM), recordable optical disc (CD-R), rewritable optical disc (CD-RW), optical disc, magnetic media, magneto-optical media, removable memory cards or discs, various types of digital multifunction discs (DVDs), magnetic tape, cassette tape, etc. Instructions may include any suitable type of code implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc.

[0151] The foregoing description of exemplary embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit this disclosure to the precise forms disclosed. Many modifications and variations are possible based on this disclosure. The scope of this disclosure is intended to be limited not by this detailed description, but by the appended claims. Future applications claiming priority to this application may claim protection for the disclosed subject matter in different ways and may generally include any set or more of the limitations disclosed herein or otherwise shown.

Claims

1. A method comprising: An application executing on a processor receives an application transaction counter (ATC), a digital signature, and a public key from a contactless card; the digital signature contains card identification information of the contactless card. The application verifies the digital signature based on the public key; The application receives requests that include non-payment events; The application sends a message to the authentication server including the request and a password, wherein the password is based at least in part on the ATC and the symmetric key associated with the contactless card; The application receives a response from an authentication server that verifies the password, wherein the response is based on a payment protocol, wherein the response reflects the performance of the non-payment event, wherein the response conforms to a payment format, and wherein the authentication server authenticates the non-payment event using the payment protocol, at least in part, based on an instruction to request authentication of the non-payment event using the payment protocol. The application receives the ATC of the authentication server and determines the difference between the ATC of the authentication server and the ATC of the contactless card, wherein the difference indicates the amount by which the ATC of the authentication server and the ATC of the contactless card are out of sync. In response to the difference being greater than zero but less than a first threshold, the application increments the ATC of the contactless card based on verification of the password; and In response to the difference being equal to or greater than the first threshold, the application synchronizes the incremented ATC of the contactless card with the ATC of the authentication server.

2. The method according to claim 1, wherein, The non-payment event includes one or more of the following: (i) activating the contactless card, (ii) modifying the personal identification number (PIN) of the contactless card, or (iii) modifying the address associated with the contactless card.

3. The method according to claim 2, wherein, The response from the authentication server reflects one or more of the following: (i) activation of the contactless card, (ii) modification of the PIN of the contactless card, or (iii) modification of the address associated with the contactless card.

4. The method according to claim 1, wherein, The ATC, the digital signature, and the public key are received using Near Field Communication (NFC).

5. The method according to claim 1, wherein, The password is generated by either the contactless card or the application.

6. The method according to claim 5, wherein, The password is generated by the contactless card and received by the application from the contactless card.

7. The method according to claim 1, wherein, The password is generated based on the payment protocol, wherein the password is an Authentication Request Password (ARQC).

8. The method according to claim 1, wherein, The message includes a predefined transaction value used to mimic the payment protocol to verify the contactless card that performs the non-payment event without completing the payment.

9. The method according to claim 1, wherein, The contactless card is one of a plurality of contactless cards, wherein each contactless card is associated with a different predefined value, and wherein the payment protocol includes Europay, Mastercard and Visa (EMV) protocols.

10. A non-transitory computer-readable storage medium, the computer-readable storage medium comprising instructions that, when executed by a processor, cause the processor to: The application receives an application transaction counter (ATC), a digital signature, and a public key from the contactless card, wherein the digital signature contains the card identification information of the contactless card; The application verifies the digital signature based on the public key; The application receives requests that include non-payment events; The application sends a message including the request and the password to the authentication server, wherein, The password is based at least in part on the ATC and the symmetric key associated with the contactless card; The application receives a response from an authentication server that verifies the password, wherein the response is based on a payment protocol, wherein the response reflects the performance of the non-payment event, wherein the response conforms to a payment format, and wherein the authentication server authenticates the non-payment event using the payment protocol, at least in part, based on an instruction to request authentication of the non-payment event using the payment protocol. The application receives the ATC of the authentication server and determines the difference between the ATC of the authentication server and the ATC of the contactless card, wherein the difference indicates the amount by which the ATC of the authentication server and the ATC of the contactless card are out of sync. In response to the difference being greater than zero but less than a first threshold, the application increments the ATC of the contactless card based on verification of the password; and In response to the difference being equal to or greater than the first threshold, the application synchronizes the incremented ATC of the contactless card with the ATC of the authentication server.

11. The computer-readable storage medium according to claim 10, wherein, The non-payment event includes one or more of the following: (i) activating the contactless card, (ii) modifying the personal identification number (PIN) of the contactless card, or (iii) modifying the address associated with the contactless card.

12. The computer-readable storage medium according to claim 11, wherein, The response from the authentication server reflects one or more of the following: (i) activation of the contactless card, (ii) modification of the PIN of the contactless card, or (iii) modification of the address associated with the contactless card.

13. The computer-readable storage medium according to claim 10, wherein, The ATC, the digital signature, and the public key are received using Near Field Communication (NFC).

14. The computer-readable storage medium according to claim 10, wherein, The password is generated by either the contactless card or the application.

15. The computer-readable storage medium according to claim 14, wherein, The password is generated by the contactless card and received by the application from the contactless card.

16. The computer-readable storage medium of claim 10, wherein, The password is generated based on the payment protocol, wherein the password is an Authentication Request Password (ARQC).

17. The computer-readable storage medium of claim 10, wherein, The message includes a predefined transaction value used to mimic the payment protocol to verify the contactless card that performs the non-payment event without completing the payment, wherein the payment protocol includes Europay, Mastercard, and Visa (EMV) protocols.

18. The computer-readable storage medium according to claim 10, wherein, The contactless card is one of a plurality of contactless cards, wherein each contactless card is associated with a different predefined value.

19. A method comprising: The server receives a message conforming to a payment protocol from an application running on a client device. The message includes: (i) a request to perform a non-payment event associated with the contactless card; (ii) an application transaction counter (ATC) generated by the contactless card; (iii) a digital signature generated by the contactless card; (iv) a password generated based on the ATC and a symmetric key associated with the contactless card; and (v) an instruction to request authentication of the non-payment event using the payment protocol, wherein the digital signature contains card identification information of the contactless card. The server verifies the digital signature based on the public key associated with the contactless card; The server decrypts the password, at least in part, based on the ATC and the symmetric key; The server authenticates the non-payment event using the payment protocol, at least in part based on an instruction in the message to request authentication of the non-payment event using the payment protocol. The server sends a response based on the payment protocol to the application based on the verification of the digital signature and the decryption of the password, wherein the response reflects the performance of the non-payment event and conforms to the payment format; The server determines the difference between the server's ATC and the contactless card's ATC, wherein the difference indicates the amount by which the server's ATC and the contactless card's ATC are out of sync; In response to the difference being greater than zero but less than a first threshold, the server increments the ATC of the contactless card based on verification of the password; and In response to the difference being equal to or greater than the first threshold, the server synchronizes the incremented ATC of the contactless card with the ATC of the server.

20. The method according to claim 19, wherein, The non-payment event includes one or more of the following: (i) activating the contactless card, (ii) modifying the personal identification number (PIN) of the contactless card, or (iii) modifying the address associated with the contactless card.

21. The method according to claim 19, wherein, The password is generated by either the contactless card or the application.

22. The method according to claim 21, wherein, The password is generated by the contactless card and received by the application from the contactless card.

23. The method according to claim 19, wherein, The password is generated based on the payment protocol, wherein the password is an Authentication Request Password (ARQC).

24. The method according to claim 19, wherein, The payment protocols include Europay, Mastercard, and Visa (EMV) protocols.

25. The method according to claim 19, wherein, The message also includes an indication of the type of the application, wherein the server determines, based on the type of the application, that the application does not include payment features or does not use the payment protocol to complete the payment, and wherein, based on the determination that the application does not include payment features or does not use the payment protocol to complete the payment, the server further authenticates the non-payment event using the payment protocol.

Images