Patent Description:
Authentication may be the act of proving or verifying an assertion, such as an identity of a user of a computing device. The ways in which the user is authenticated may fall into three categories based on what are known as the factors of authentication: something that the user knows, something the user has, and something the user is. Each authentication factor may cover a range of elements used to authenticate or verify the user's identity prior to being granted access, approving a request, signing a document or other work product, granting authority to others, establishing chain of authority, etc..

<CIT> describes providing continuous authentication to a digital service when a contactless card is positioned proximate a computing device.

<CIT> describes a system and method for pre-authentication of customer support calls.

<CIT> describes user authentication via device characteristics.

Various embodiments are generally directed to performing an authentication persistence check and, based on the check, allowing a previously successful authentication to persist on a user apparatus. The check may involve a stability check on the user apparatus. If the user apparatus is stable, device fingerprinting on the apparatus may be performed, the result of which may be compared to a snapshot of apparatus taken at the time of successful authentication. If the comparison reveals changes or drifts that are within a predetermined threshold, then the persistence of the authentication may be allowed.

According to a first aspect of the present disclosure there is provided an apparatus according to claim <NUM>.

According to a second aspect of the present disclosure there is provided a method according to claim <NUM>.

According to a third aspect of the present disclosure there is provided a non-transitory computer-readable storage medium according to claim <NUM>.

Various embodiments are generally directed to performing an authentication persistence check on a user apparatus (e.g., mobile computing device), and based on a positive persistence check, allowing a previously successful authentication (e.g., first factor authentication, second factor authentication) to persist for a predetermined period of time. For example, the authentication persistence check may be triggered or caused by one or more factors, such as a passing of a specific amount of time after a first instance of the authentication or when an authentication event occurs, which may include any action or instance that would typically require an authentication to be performed or processed, e.g., high-risk action or behavior, risk level of user action.

According to embodiments, the authentication persistence check may be considered positive if: (i) the user apparatus is stable based on a stability check and (ii) device settings of the user apparatus and/or behavioral biometrics associated with the user are within a predetermined drift threshold. Based on a positive persistence check, the previously successful authentication may persist for the predetermined period of time, and thus, does not require the user to reauthenticate. If, however, the persistence check is negative, the user would be required to reauthenticate.

After the predetermined period of time has passed since the positive authentication persistence check or when a subsequent authentication event occurs, a subsequent persistence check may be performed to determine if the authentication can continue to persist. In some instances, the number of consecutive positive persistence checks may be limited, and thus, the user may be required to reauthenticate after that limit has been reached.

According to embodiments, the types of authentication that can persist may include first factor authentication and second factor authentication, where the first factor and second factor authentications may be different from each other. For instance, the first factor authentication process may require the authenticating user to know something, such as a login ID and password. The second factor authentication may require the authenticating user to possess and utilize something, such as a contactless smart card.

In examples, the second factor authentication may involve the user tapping a contactless card to the user apparatus such that near field communication (NFC) is established between the apparatus and the contactless card. The user apparatus may receive encrypted authentication information from the contactless card via an NFC reader, send the authentication information to one or more remote authentication servers, and receive from the authentication servers an indication that the user is verified and authenticated.

At time of successful authentication, one or more device settings of the user apparatus and/or one or more user behavioral biometrics associated with the use of or interaction with the user apparatus may be determined. This may be referred to or described herein as taking a "snapshot" of a "constellation" of the various device settings and user behavioral biometrics. As will be further described below, the snapshot may be used as a reference point for determining how much the device settings and/or user behavioral biometrics have drifted, deviated, or changed at the time of the authentication persistence check. The allotted degree of drift, deviation, or change may be referred to herein as the predetermined drift threshold.

When the authentication persistence check is triggered, a stability check may be performed on the user apparatus. For example, the stability check may be a mobile network operator (MNO) verification, which may involve verifying or checking with the appropriate MNO(s) that the user apparatus has not substantially changed (e.g., has not changed SIM cards, has not changed phone numbers, has not changed owners, etc.) so as to at least confirm that the user apparatus still belongs to and is associated with the user.

In response to the user apparatus having passed the stability check or otherwise being stable, a device fingerprinting of the user apparatus may be performed. Device fingerprinting may be process in which a current constellation of the device settings and/or user behavioral biometrics corresponding to the user apparatus is determined. In at least that regard, device fingerprinting may be similar to the process of taking the snapshot at the time of successful authentication, as described above.

According to further embodiments, it may be determined whether the current constellation of the device settings and/or user behavioral biometrics provided by the device fingerprinting is within the predetermined drift threshold. If within the drift threshold, the authentication may be allowed to persist. If outside the drift threshold, the user may be required to reauthenticate, and in some examples, reauthenticate via both the first and second factor authentications.

In previous solutions, each instance of authentication required the user to manually perform authentication-related acts to complete the authentication process, which would cause user annoyance and friction between the user and platform. The embodiments and examples described herein are advantageous over conventional solutions in various ways. For example, authentication may be allowed to automatically persist based on a positive authentication persistence check in a highly secure manner, which makes the authentication process convenient for the user and improves overall quality of user experience.

Reference is now made to the drawings, where like reference numerals are used to refer to like elements throughout. In the following description, for the purpose of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. It may be evident, however, that the novel embodiments can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to facilitate a description thereof. The intention is to cover all modification, equivalents, and alternatives within the scope of the claims.

<FIG> illustrates an example data transmission system according to one or more embodiments. As further discussed below, system <NUM> may include contactless card <NUM>, client device <NUM>, network <NUM>, and server <NUM>. Although <FIG> illustrates single instances of the components, system <NUM> may include any number of components.

System <NUM> may include one or more contactless cards <NUM>, which are further explained below with reference to <FIG> and <FIG>. In some embodiments, contactless card <NUM> may be in wireless communication, utilizing NFC in an example, with client device <NUM>.

System <NUM> may include client device <NUM>, which may be a network-enabled computer. As referred to herein, a network-enabled computer may include, but is not limited to a computer device, or communications device including, e.g., a server, a network appliance, a personal computer, a workstation, a phone, a smartphone, a handheld PC, a personal digital assistant, a thin client, a fat client, an Internet browser, or other device. Client device <NUM> also may be a mobile computing device, for example, an iPhone, iPod, iPad from Applet or any other suitable device running Apple's iOS® operating system, any device running Microsoft's Windows® Mobile operating system, any device running Google's Android® operating system, and/or any other suitable mobile computing device, such as a smartphone, a tablet, or like wearable mobile device.

The client device <NUM> device can include a processor and a memory, and it is understood that the processing circuitry may contain additional components, including processors, memories, error and parity/CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives and tamper-proofing hardware, as necessary to perform the functions described herein. The client device <NUM> may further include a display and input devices. The display may be any type of device for presenting visual information such as a computer monitor, a flat panel display, and a mobile device screen, including liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays. The input devices may include any device for entering information into the user's device that is available and supported by the user's device, such as a touchscreen, keyboard, mouse, cursor-control device, touchscreen, microphone, digital camera, video recorder or camcorder. These devices may be used to enter information and interact with the software and other devices described herein.

In some examples, client device <NUM> of system <NUM> may execute one or more applications, such as software applications, that enable, for example, network communications with one or more components of system <NUM> and transmit and/or receive data.

Client device <NUM> may be in communication with one or more servers <NUM> via one or more networks <NUM> and may operate as a respective front-end to back-end pair with server <NUM>. Client device <NUM> may transmit, for example from a mobile device application executing on client device <NUM>, one or more requests to server <NUM>. The one or more requests may be associated with retrieving data from server <NUM>. Server <NUM> may receive the one or more requests from client device <NUM>. Based on the one or more requests from client device <NUM>, server <NUM> may be configured to retrieve the requested data from one or more databases (not shown). Based on receipt of the requested data from the one or more databases, server <NUM> may be configured to transmit the received data to client device <NUM>, the received data being responsive to one or more requests.

System <NUM> may include one or more networks <NUM>. In some examples, network <NUM> may be one or more of a wireless network, a wired network or any combination of wireless network and wired network and may be configured to connect client device <NUM> to server <NUM>. For example, network <NUM> may include one or more of a fiber optics network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless local area network (LAN), a Global System for Mobile Communication, a Personal Communication Service, a Personal Area Network, Wireless Application Protocol, Multimedia Messaging Service, Enhanced Messaging Service, Short Message Service, Time Division Multiplexing based systems, Code Division Multiple Access based systems, D-AMPS, Wi-Fi, Fixed Wireless Data, IEEE <NUM>. 11b, <NUM>. <NUM>, <NUM>. 11n and <NUM>, Bluetooth, NFC, Radio Frequency Identification (RFID), Wi-Fi, and/or the like.

In addition, network <NUM> may include, without limitation, telephone lines, fiber optics, IEEE Ethernet <NUM>, a wide area network, a wireless personal area network, a LAN, or a global network such as the Internet. In addition, network <NUM> may support an Internet network, a wireless communication network, a cellular network, or the like, or any combination thereof. Network <NUM> may further include one network, or any number of the exemplary types of networks mentioned above, operating as a stand-alone network or in cooperation with each other. Network <NUM> may utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network <NUM> may translate to or from other protocols to one or more protocols of network devices. Although network <NUM> is depicted as a single network, it should be appreciated that according to one or more examples, network <NUM> may include a plurality of interconnected networks, such as, for example, the Internet, a service provider's network, a cable television network, corporate networks, such as credit card association networks, and home networks.

System <NUM> may include one or more servers <NUM>. In some examples, server <NUM> may include one or more processors, which are coupled to memory. Server <NUM> may be configured as a central system, server or platform to control and call various data at different times to execute a plurality of workflow actions. Server <NUM> may be configured to connect to the one or more databases. Server <NUM> may be connected to at least one client device <NUM>.

<FIG> illustrates an example sequence diagram for providing authenticated access according to one or more embodiments. The diagram may include contactless card <NUM> and client device <NUM>, which may include an application <NUM> and processor <NUM>. <FIG> may reference similar components as illustrated in <FIG>.

At step <NUM>, the application <NUM> communicates with the contactless card <NUM> (e.g., after being brought near the contactless card <NUM>). Communication between the application <NUM> and the contactless card <NUM> may involve the contactless card <NUM> being sufficiently close to a card reader (not shown) of the client device <NUM> to enable NFC data transfer between the application <NUM> and the contactless card <NUM>.

At step <NUM>, after communication has been established between client device <NUM> and contactless card <NUM>, the contactless card <NUM> generates a message authentication code (MAC) cryptogram. In some examples, this may occur when the contactless card <NUM> is read by the application <NUM>. In particular, this may occur upon a read, such as an NFC read, of a near field data exchange (NDEF) tag, which may be created in accordance with the NFC Data Exchange Format.

For example, a reader, such as application <NUM>, may transmit a message, such as an applet select message, with the applet ID of an NDEF producing applet. Upon confirmation of the selection, a sequence of select file messages followed by read file messages may be transmitted. For example, the sequence may include "Select Capabilities file," "Read Capabilities file," and "Select NDEF file. " At this point, a counter value maintained by the contactless card <NUM> may be updated or incremented, which may be followed by "Read NDEF file. " At this point, the message may be generated which may include a header and a shared secret. Session keys may then be generated. The MAC cryptogram may be created from the message, which may include the header and the shared secret. The MAC cryptogram may then be concatenated with one or more blocks of random data, and the MAC cryptogram and a random number (RND) may be encrypted with the session key. Thereafter, the cryptogram and the header may be concatenated, and encoded as ASCII hex and returned in NDEF message format (responsive to the "Read NDEF file" message).

In some examples, the MAC cryptogram may be transmitted as an NDEF tag, and in other examples the MAC cryptogram may be included with a uniform resource indicator (e.g., as a formatted string).

In some examples, application <NUM> may be configured to transmit a request to contactless card <NUM>, the request comprising an instruction to generate a MAC cryptogram.

At step <NUM>, the contactless card <NUM> sends the MAC cryptogram to the application <NUM>. In some examples, the transmission of the MAC cryptogram occurs via NFC, however, the present disclosure is not limited thereto. In other examples, this communication may occur via Bluetooth, Wi-Fi, or other means of wireless data communication.

At step <NUM>, the application <NUM> communicates the MAC cryptogram to the processor <NUM>. At step <NUM>, the processor <NUM> verifies the MAC cryptogram pursuant to an instruction from the application <NUM>. For example, the MAC cryptogram may be verified, as explained below.

In some examples, verifying the MAC cryptogram may be performed by a device other than client device <NUM>, such as a server <NUM> in data communication with the client device <NUM> (as shown in <FIG>). For example, processor <NUM> may output the MAC cryptogram for transmission to server <NUM>, which may verify the MAC cryptogram.

In some examples, the MAC cryptogram may function as a digital signature for purposes of verification. Other digital signature algorithms, such as public key asymmetric algorithms, e.g., the Digital Signature Algorithm and the RSA algorithm, or zero knowledge protocols, may be used to perform this verification.

It may be understood that in some examples, the contactless card <NUM> may initiate communication after the contactless card is brought near the client device <NUM>. By way of example, the contactless card <NUM> may send the client device <NUM> a message, for instance, indicating that the contactless card has established communication. Thereafter, the application <NUM> of client device <NUM> may proceed to communicate with the contactless card at step <NUM>, as described above.

<FIG> illustrates an example system <NUM> using a contactless card. System <NUM> may include a contactless card <NUM>, one or more client devices <NUM>, network <NUM>, servers <NUM>, <NUM>, one or more hardware security modules <NUM>, and a database <NUM>. Although <FIG> illustrates single instances of the components, system <NUM> may include any number of components.

System <NUM> may include one or more contactless cards <NUM>, which are further explained below with respect to <FIG> and <FIG>. In some examples, contactless card <NUM> may be in wireless communication, for example NFC, with client device <NUM>. For example, contactless card <NUM> may include one or more chips, such as a radio frequency identification chip, configured to communication via NFC or other short-range protocols. In other embodiments, contactless card <NUM> may communicate with client device <NUM> through other means including, but not limited to, Bluetooth, satellite, Wi-Fi, wired communications, and/or any combination of wireless and wired connections. According to some embodiments, contactless card <NUM> may be configured to communicate with card reader <NUM> (which may otherwise be referred to herein as NFC reader, NFC card reader, or reader) of client device <NUM> through NFC when contactless card <NUM> is within range of card reader <NUM>. In other examples, communications with contactless card <NUM> may be accomplished through a physical interface, e.g., a universal serial bus interface or a card swipe interface.

System <NUM> may include client device <NUM>, which may be a network-enabled computer. As referred to herein, a network-enabled computer may include, but is not limited to: e.g., a computer device, or communications device including, e.g., a server, a network appliance, a personal computer, a workstation, a mobile device, a phone, a handheld PC, a personal digital assistant, a thin client, a fat client, an Internet browser, or other device. One or more client devices <NUM> also may be a mobile device; for example, a mobile device may include an iPhone, iPod, iPad from Apple® or any other mobile device running Apple's iOS® operating system, any device running Microsoft's Windows® Mobile operating system, any device running Google's Android® operating system, and/or any other smartphone or like wearable mobile device. In some examples, the client device <NUM> may be the same as, or similar to, a client device <NUM> as described with reference to <FIG> or <FIG>.

Client device <NUM> may be in communication with one or more servers <NUM> and <NUM> via one or more networks <NUM>. Client device <NUM> may transmit, for example from an application <NUM> executing on client device <NUM>, one or more requests to one or more servers <NUM> and <NUM>. The one or more requests may be associated with retrieving data from one or more servers <NUM> and <NUM>. Servers <NUM> and <NUM> may receive the one or more requests from client device <NUM>. Based on the one or more requests from client device <NUM>, one or more servers <NUM> and <NUM> may be configured to retrieve the requested data from one or more databases <NUM>. Based on receipt of the requested data from the one or more databases <NUM>, one or more servers <NUM> and <NUM> may be configured to transmit the received data to client device <NUM>, the received data being responsive to one or more requests.

System <NUM> may include one or more hardware security modules (HSM) <NUM>. For example, one or more HSMs <NUM> may be configured to perform one or more cryptographic operations as disclosed herein. In some examples, one or more HSMs <NUM> may be configured as special purpose security devices that are configured to perform the one or more cryptographic operations. The HSMs <NUM> may be configured such that keys are never revealed outside the HSM <NUM>, and instead are maintained within the HSM <NUM>. For example, one or more HSMs <NUM> may be configured to perform at least one of key derivations, decryption, and MAC operations. The one or more HSMs <NUM> may be contained within, or may be in data communication with, servers <NUM> and <NUM>.

System <NUM> may include one or more networks <NUM>. In some examples, network <NUM> may be one or more of a wireless network, a wired network or any combination of wireless network and wired network, and may be configured to connect client device <NUM> to servers <NUM> and/or <NUM>. For example, network <NUM> may include one or more of a fiber optics network, a passive optical network, a cable network, a cellular network, an Internet network, a satellite network, a wireless LAN, a Global System for Mobile Communication, a Personal Communication Service, a Personal Area Network, Wireless Application Protocol, Multimedia Messaging Service, Enhanced Messaging Service, Short Message Service, Time Division Multiplexing based systems, Code Division Multiple Access based systems, D-AMPS, Wi-Fi, Fixed Wireless Data, IEEE <NUM>. 11b, <NUM>. <NUM>, <NUM>. 11n and <NUM>, Bluetooth, NFC, RFID, Wi-Fi, and/or any combination of networks thereof. As a non-limiting example, communications from contactless card <NUM> and client device <NUM> may include NFC-based communication, cellular network between client device <NUM> and a carrier, and Internet between the carrier and a backend.

In addition, network <NUM> may include, without limitation, telephone lines, fiber optics, IEEE Ethernet <NUM>, a wide area network, a wireless personal area network, a local area network, or a global network such as the Internet. In addition, network <NUM> may support an Internet network, a wireless communication network, a cellular network, or the like, or any combination thereof. Network <NUM> may further include one network, or any number of the exemplary types of networks mentioned above, operating as a stand-alone network or in cooperation with each other. Network <NUM> may utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network <NUM> may translate to or from other protocols to one or more protocols of network devices. Although network <NUM> is depicted as a single network, it should be appreciated that according to one or more examples, network <NUM> may include a plurality of interconnected networks, such as, for example, the Internet, a service provider's network, a cable television network, corporate networks, such as credit card association networks, and home networks.

In various examples according to the present disclosure, client device <NUM> of system <NUM> may execute one or more applications <NUM>, and include one or more processors <NUM>, and one or more card readers <NUM>. For example, one or more applications <NUM>, such as software applications, may be configured to enable, for example, network communications with one or more components of system <NUM> and transmit and/or receive data. It is understood that although only single instances of the components of client device <NUM> are illustrated in <FIG>, any number of devices <NUM> may be used. Card reader <NUM> may be configured to read from and/or communicate with contactless card <NUM>. In conjunction with the one or more applications <NUM>, card reader <NUM> may communicate with contactless card <NUM>. In examples, the card reader <NUM> may include circuitry or circuitry components, e.g., NFC reader coil, that generates a magnetic field to allow communication between the client device <NUM> and the contactless card <NUM>.

The application <NUM> of any of client device <NUM> may communicate with the contactless card <NUM> using short-range wireless communication (e.g., NFC). The application <NUM> may be configured to interface with a card reader <NUM> of client device <NUM> configured to communicate with a contactless card <NUM>. As should be noted, those skilled in the art would understand that a distance of less than twenty centimeters is consistent with NFC range.

In some embodiments, the application <NUM> communicates through an associated reader (e.g., card reader <NUM>) with the contactless card <NUM>.

In some embodiments, card activation may occur without user authentication. For example, a contactless card <NUM> may communicate with the application <NUM> through the card reader <NUM> of the client device <NUM> through NFC. The communication (e.g., a tap of the card proximate the card reader <NUM> of the client device <NUM>) allows the application <NUM> to read the data associated with the card and perform an activation. In some cases, the tap may activate or launch application <NUM> and then initiate one or more actions or communications with an account server <NUM> to activate the card for subsequent use. In some cases, if the application <NUM> is not installed on client device <NUM>, a tap of the card against the card reader <NUM> may initiate a download of the application <NUM> (e.g., navigation to an application download page). Subsequent to installation, a tap of the card may activate or launch the application <NUM>, and then initiate (e.g., via the application or other back-end communication) activation of the card. After activation, the card may be used in various transactions including commercial transactions.

According to some embodiments, the contactless card <NUM> may include a virtual payment card. In those embodiments, the application <NUM> may retrieve information associated with the contactless card <NUM> by accessing a digital wallet implemented on the client device <NUM>, wherein the digital wallet includes the virtual payment card. In some examples, virtual payment card data may include one or more static or dynamically generated virtual card numbers.

Server <NUM> may include a web server in communication with database <NUM>. Server <NUM> may include an account server. In some examples, server <NUM> may be configured to validate one or more credentials from contactless card <NUM> and/or client device <NUM> by comparison with one or more credentials in database <NUM>. Server <NUM> may be configured to authorize one or more requests, such as payment and transaction, from contactless card <NUM> and/or client device <NUM>.

<FIG> illustrates one or more contactless cards <NUM>, which may include a payment card, such as a credit card, debit card, or gift card, issued by a service provider <NUM> displayed on the front or back of the card <NUM>. In some examples, the contactless card <NUM> is not related to a payment card, and may include, without limitation, an identification card. In some examples, the payment card may include a dual interface contactless payment card. The contactless card <NUM> may include a substrate <NUM>, which may include a single layer, or one or more laminated layers composed of plastics, metals, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyesters, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card <NUM> may have physical characteristics compliant with the ID-<NUM> format of the ISO/IEC <NUM> standard, and the contactless card may otherwise be compliant with the ISO/IEC <NUM> standard. However, it is understood that the contactless card <NUM> according to the present disclosure may have different characteristics, and the present disclosure does not require a contactless card to be implemented in a payment card.

The contactless card <NUM> may also include identification information <NUM> displayed on the front and/or back of the card, and a contact pad <NUM>. The contact pad <NUM> may be configured to establish contact with another communication device, such as a user device, smart phone, laptop, desktop, or tablet computer. The contactless card <NUM> may also include processing circuitry, antenna and other components not shown in <FIG>. These components may be located behind the contact pad <NUM> or elsewhere on the substrate <NUM>. The contactless card <NUM> may also include a magnetic strip or tape, which may be located on the back of the card (not shown in <FIG>).

As illustrated in <FIG>, the contact pad <NUM> of <FIG> may include processing circuitry <NUM> for storing and processing information, including a microprocessor <NUM> and a memory <NUM>. It is understood that the processing circuitry <NUM> may contain additional components, including processors, memories, error and parity/CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives and tamper-proofing hardware, as necessary to perform the functions described herein.

The memory <NUM> may be a read-only memory, write-once read-multiple memory or read/write memory, e.g., RAM, ROM, and EEPROM, and the contactless card <NUM> may include one or more of these memories. A read-only memory may be factory programmable as read-only or one-time programmable. One-time programmability provides the opportunity to write once then read many times. A write once/read-multiple memory may be programmed at a point in time after the memory chip has left the factory. Once the memory is programmed, it may not be rewritten, but it may be read many times. A read/write memory may be programmed and re-programed many times after leaving the factory. It may also be read many times.

The memory <NUM> may be configured to store one or more applets <NUM>, one or more counters <NUM>, one or more diversified keys <NUM>, one or more customer identifiers <NUM>, and other types of suitable data or information. The one or more applets <NUM> may include one or more software applications configured to execute on one or more contactless cards, such as Java Card applet. However, it is understood that applets <NUM> are not limited to Java Card applets, and instead may be any software application operable on contactless cards or other devices having limited memory. The one or more counters <NUM> may include a numeric counter sufficient to store an integer. As will be further described below, the one or more diversified keys <NUM> may be used to encrypt various information, such as information about the user or customer (e.g., customer identifier <NUM>) to generate cryptogram(s) that can be sent to, for example, a mobile device for at least authentication purposes. The customer identifier <NUM> may include a unique alphanumeric identifier assigned to a user of the contactless card <NUM>, and the identifier may distinguish the user of the contactless card from other contactless card users. In some examples, the customer identifier <NUM> may identify both a customer and an account assigned to that customer and may further identify the contactless card associated with the customer's account.

The processor and memory elements of the foregoing exemplary embodiments are described with reference to the contact pad, but the present disclosure is not limited thereto. It is understood that these elements may be implemented outside of the pad <NUM> or entirely separate from it, or as further elements in addition to microprocessor <NUM> and memory <NUM> elements located within the contact pad <NUM>.

In some examples, the contactless card <NUM> may include one or more antennas <NUM>. The one or more antennas <NUM> may be placed within the contactless card <NUM> and around the processing circuitry <NUM> of the contact pad <NUM>. For example, the one or more antennas <NUM> may be integral with the processing circuitry <NUM> and the one or more antennas <NUM> may be used with an external booster coil. As another example, the one or more antennas <NUM> may be external to the contact pad <NUM> and the processing circuitry <NUM>.

In an embodiment, the coil of contactless card <NUM> may act as the secondary of an air core transformer. The terminal may communicate with the contactless card <NUM> by cutting power or amplitude modulation. The contactless card <NUM> may infer the data transmitted from the terminal using the gaps in the contactless card's power connection, which may be functionally maintained through one or more capacitors. The contactless card <NUM> may communicate back by switching a load on the contactless card's coil or load modulation. Load modulation may be detected in the terminal's coil through interference.

As explained above, the contactless cards <NUM> may be built on a software platform operable on smart cards or other devices having limited memory, such as JavaCard, and one or more or more applications or applets may be securely executed. Applets may be added to contactless cards to provide a one-time password (OTP) for multifactor authentication (MFA) in various mobile application-based use cases. Applets may 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, and produce an NDEF message that includes a cryptographically secure OTP encoded as an NDEF text tag.

In examples, when preparing to send data (e.g., to a mobile device, to a server, etc.), the contactless card <NUM> may increment a counter value of a counter of the one or more counters <NUM>. The contactless card <NUM> may then provide a master key, which may be a distinct key stored on the card <NUM>, and the counter value as input to a cryptographic algorithm, which may also be stored on the card <NUM> and produces a diversified key as output, which may be one of the diversified keys <NUM>. It is understood that the master key and the counter value is also securely stored in memory of a device or component receiving data from the contactless card <NUM> so as to decrypt the data using the diversified key that was used by the card to encrypt the transmitted data. The cryptographic algorithm may include encryption algorithms, hash-based message authentication code (HMAC) algorithms, cipher-based message authentication code (CMAC) algorithms, and the like. Non-limiting examples of the cryptographic algorithm may include a symmetric encryption algorithm such as 3DES or AES128; a symmetric HMAC algorithm, such as HMAC-SHA-<NUM>; and a symmetric CMAC algorithm such as AES-CMAC. The contactless card <NUM> may then encrypt the data (e.g., the customer identifier <NUM> and any other data) using the diversified key in the form of one or more cryptograms that can be sent to a mobile device, for example, as NFC data exchange format (NDEF) messages. The contactless card <NUM> may then transmit the encrypted data (e.g., cryptograms) to the mobile device, which can then decrypt the cryptograms using the diversified key (e.g., the diversified key generated by the mobile device using the counter value and the master key stored in memory thereof).

<FIG> illustrates an example timing diagram <NUM> according to one or more embodiments. The timing diagram <NUM> shows at least the various timing-related features associated with an authentication persistence check and the communication between a user apparatus (e.g., user mobile computing device such as a smartphone, laptop, etc.) and one or more remote backend computing devices (e.g., servers). In examples, the authentication persistence check may be for the second factor authentication, which may otherwise be referred to as a second factor authentication persistence check.

As shown, at time <NUM> a first factor authentication may be required and performed. As will be further described in detail below, the first factor authentication may involve user ID-password authentication. For example, a user may enter a user ID and password, which may be provided to the backend servers to verify that the entered user ID and password are correct.

At time <NUM>, after successful first factor authentication, a second factor authentication may be required and performed. The second factor authentication may be different type of authentication than the first factor authentication. For example, the second factor authentication may involve the user tapping a contactless card to the user apparatus, which may otherwise be known as one-tap or single tap authentication. The user apparatus, via NFC, receives encrypted user authentication information from the contactless card, e.g., one or more cryptograms containing a user identifier, authentication identifier, etc. The user apparatus may send the cryptogram(s) to remote computing devices, which may be the backed servers, where those servers decrypt the cryptograms to verify whether the user identifier contained therein corresponds to or matches the user. The remote computing devices may then send back an indication to the user apparatus that the user has been successfully authenticated.

At the time of successful second factor authentication (time <NUM>) or near that time, a snapshot of the one or more device settings (e.g., number of apps installed on the phone, types of apps, of the user apparatus and information on one or more user behavioral biometrics (e.g., unique behaviors or patterns related to the use of or interactions with the user apparatus by the user) may be captured. The captured result may be considered a constellation of the device settings and the user behavioral biometrics. The snapshot may be sent or shared with the one or more backend servers for later comparisons to device fingerprints during future persistence checks. While <FIG> shows snapshot occurring after the second factor authentication of time <NUM>, it may be understood that the snapshot may occur at the same time or near the same time as second factor authentication. The snapshot may be provided to the one or more remote backend computing devices at time <NUM>.

Thereafter, the second factor authentication persistence check may be performed. The check may be triggered by one of at least: a passage of a specific amount of time or a specific second factor authentication event. The specific amount of time may be predetermined or preset, e.g., a maximum of time that can pass before the user is required to perform the second factor authentication again. The second factor authentication event may be any action or event, either caused or triggered by the user, that requires the second factor authentication, such as high-risk transactions.

At time <NUM>, a stability check or verification on the user apparatus may be performed. The user apparatus may request and cause the one or more backend remote computing devices to conduct the stability check by communicating with one or more mobile operator servers associated with a mobile operator network (MNO), e.g., via application programming interface (API) calls. In other instances, the one or more remote backend servers automatically initiate or may be automatically caused to perform the stability check in response to the second factor authentication persistence check, an indication of which may be provided to the remote backend servers by the user apparatus. One example of the stability check is an MNO stability check, which involves the backend computing devices to request and receive indication from the mobile operator servers that the user apparatus has not substantially changed, e.g., the SIM card of the user apparatus remains the same, the telephone number associated with the user apparatus remains the same, etc..

At time <NUM>, in response to a determination that the user apparatus is stable, the one or more backed computing devices may request that the user apparatus perform device fingerprinting. Alternatively, at time <NUM>, in response to a determination that the user apparatus is unstable, the one or more backend servers may return a negative result for the persistence check and require that the user to reauthenticate via the second factor authentication (not shown).

At time <NUM>, the user apparatus may perform device fingerprinting. As will be further described below, device fingerprinting may be a process in which a current constellation of the device settings of the user apparatus and the one or more user behavioral biometrics associated with the use or interaction with the user apparatus is determined. The current constellation may be provided to the one or more backend computing devices at time <NUM>.

At time <NUM>, the backend computing devices may perform a drift analysis. For example, the drift analysis may involve at least determining whether the current constellation of the user apparatus that was provided at time <NUM> is within a predetermined drift threshold relative to the snapshot taken at time <NUM>. As will be further described in detail below, the drift threshold is a maximum amount of deviation or drift between the current constellation and the snapshot that can be allowed. If the current constellation is within the predetermined drift threshold, the backend computing devices may provide indication at time <NUM> to the user apparatus that the second factor authentication may be allowed to persist. If the current constellation is outside the drift threshold, the backend computing devices may return a negative persistence check result and the user would be required to reauthenticate via the second factor authentication.

<FIG> illustrates example first factor and second factor authentications according to one or more embodiments. As shown, an example of the first factor authentication <NUM> may involve a user inputting a user ID and password. As further shown, an example of the second factor authentication <NUM> may involve a user placing or tapping a contactless card to the user apparatus, which may be referred to as single tap or one-tap contactless card authentication.

In examples, a user may be required to authenticate via the first factor authentication to login to a transaction app. The user may open transaction app interface <NUM>, which displays a welcome screen <NUM> and login icon <NUM>. When the login icon <NUM> is selected, fields for the user ID and password are presented to the user for user ID and password entry. The interface may also display an icon <NUM> for logging in to the transaction app via biometric authentication, such as user fingerprint authentication.

When the login ID and password are entered by the user, the user apparatus may send the login information to one or more remote computing devices (e.g., backend authentication servers) that are at least configured to determine and verify that the login ID and password combination is valid and associated with the user. If valid, the user may gain access to the transaction app <NUM>. It may be understood that the first factor authentication may be any type of authentication, such as biometric, passcode, PIN, etc., and not limited to just user ID and password authentication.

Once the user has logged in to the transaction app <NUM>, the user may want to perform a specific transaction, e.g., transfer money to an account. The sum of money being transferred may be large enough to trigger a high-risk indication or warning by the transaction app <NUM>. As described above, this high-risk indication or warning may be considered the authentication event (specifically, in this example, may be considered the second factor authentication event since high-risk fund transfers may require second factor authentication).

As shown, for example, the user may select the fund transfer icon <NUM> to initiate and perform the transfer. Thereafter, a graphic <NUM> may display that the user is required to perform single tap or one-tap authentication. The transaction app <NUM> may display a dashed box <NUM> indicating where the user should place or tap the user's contactless card <NUM> to the user apparatus. When the contactless card <NUM> is brought near the user apparatus to a requisite communication distance, NFC may be established and the NFC reader of the user apparatus may read or receive at least one or more cryptograms from the card <NUM>. The cryptograms may contain various types of encrypted information, such as user authentication information, which may be any indicator or identifier (e.g., unique alphanumeric identifier, code, personally identifiable information, etc.) or the unique customer identifier described above with respect to <FIG> that identifies the authorized user of the card.

In embodiments, the user apparatus may receive and send the one or more cryptograms to the one or more remote computing devices, such as backend authentication servers. On the backend server side, the server computers may decrypt the cryptogram(s) and determine whether the user authentication information contained therein actually corresponds to the user. One example of this matching process may involve the backend servers correlating the information of user that has logged into the transaction app to the user authentication information contained in the cryptograms. Thereafter, the backend server computers may send the user apparatus indication of successful authentication. In other instances, it may be understood that one or more cryptograms from the contactless card may be decrypted on the user apparatus side to determine whether the user is an authorized user of the contactless card.

<FIG> illustrates an example snapshot <NUM> of the device settings and user behavioral biometrics at time of second factor authentication according to one or more embodiments. At the time of successful second factor authentication or near such time, a snapshot of a constellation of the device settings of the user apparatus and the user behavioral biometrics. It may be understood that the snapshot <NUM> may include only the device settings, only the user behavioral biometrics or biometric data, or both the device settings and the behavioral biometrics.

In examples, the one or more device settings may include: (i) one or more applications installed on the apparatus, (ii) one or more wireless devices connected to the apparatus via wireless connection, (iii) a list of saved wireless devices connectable to the apparatus, (iv) a network that the apparatus is connected to, (v) a list of saved networks the apparatus is connectable to, (vi) version of an operating system on the apparatus, (vii) one or more setting preferences, etc..

As shown, sub-constellation <NUM> indicates that, at the time of successful second factor authentication, the device settings were that there were eight apps installed, three of which were social media apps, three were entertainment apps, one was a food app, and one was a map app. Moreover, there were two wireless devices connected to the user apparatus (e.g., wireless earbuds, smartwatch) and that there were five different types of devices saved to the wireless device connection list. The user apparatus was not connected to Wi-Fi at the time of snapshot, but there were four different types of wireless networks saved to the Wi-Fi network list. Further, the version of the operating system was <NUM> and the display setting was set such that hibernation mode kicks in after three minutes and the notification setting was set at vibration.

In further examples, the one or more user behavioral biometrics or data may be received via one or more sensors (e.g., gyroscope, accelerometer, camera, microphone, etc.) or one or more interfaces of the user apparatus and may be analyzed by the user apparatus. The one or more user behavioral biometrics or biometric data may include: (i) how the user physically holds the apparatus, (ii) how the user swipes or interacts with a display interface, (iii) how the user uses keyboard or gestural shortcuts, (iv) how the user types words, (v) a duration of time for the user to type words, (vi) how the user transitions between two or more icons, (vii) typing speed of user, (viii) typing cadence of user, etc..

As illustrated, sub-constellation <NUM> indicates that, at the time of successful second factor authentication, various aspects the user's unique behavior or interaction with the user apparatus are that the user rarely holds the user apparatus horizontally, always swipes left to right, has no gestural shortcuts, types approximately <NUM> words per minute on the user apparatus, the user presses the home button to transition between apps and rarely uses the app tabs to transition, and selects app <NUM> before app <NUM> a majority of the time.

It may be understood that user behavioral biometrics broadly refers to identifying an individual based on the unique way(s) the individual interacts or uses with a computing device, such as measuring how the user holds the device, how the individual swipes the screen, which keyboard or gestural shortcuts are used, and building a unique behavioral profile of the individual, etc. The user behavioral biometrics are based on human behavioral patterns consisting of a variety of distinctive actions or behaviors (or semi-behaviors) that make up the individual and may reflect that individual's observable habits and micro-habits.

<FIG> illustrates an example stability check <NUM> of a user apparatus according to one or more embodiments. As described above, the stability check of the user apparatus may be performed to at least confirm that the user associated with the user apparatus has not changed. In examples, the stability check may be a mobile network operator (MNO) verification.

In embodiments, the user apparatus <NUM> may cause the MNO verification to be initiated. The MNO verification may be initiated or triggered (may otherwise be referred to as a "MNO verification trigger"), for example, when the first instance of the second factor authentication has been performed and (i) when an authentication event occurs or is requested (e.g., high-risk transaction, high amount transfer in the transaction app) or (ii) if a specific amount of time has passed after the first instance of the second factor authentication, e.g., which can be based on or adjusted in accordance with various backend security procedures or protocols.

As shown, the user apparatus <NUM> may communicate or provide information to the one or more backend servers <NUM> via network <NUM> that MNO verification is to be performed based on the above described MNO verification trigger. The backend servers <NUM> may then establish communication and communicate with one or more MNO computing devices <NUM>, e.g., MNO servers, which may be wirelessly communicating with one or more cell towers <NUM> or any type of wireless communication devices (e.g., base stations). Because the user apparatus <NUM> may also be connected to and wireless communicating with the one or more cell towers <NUM>, the MNO computing devices <NUM> may receive various types of mobile-network-based information about the user apparatus <NUM> via the cell towers <NUM>, such as what (e.g., model number, identifier) subscriber identity (or identification) module (SIM) card of the user apparatus <NUM> is being used to communicate with the cell towers <NUM>, whether the SIM card has been changed or replaced, phone number(s) or any other user information associated with the SIM card, whether the phone number(s) or the other user information has changed, etc..

The one or more MNO computing devices <NUM> may provide these types of information back to the backend servers <NUM>, which may determine based on this information, whether the user apparatus <NUM> is "stable" and remains unchanged in terms of the MNO-based characteristics. If the SIM card has been changed or replaced, or if the phone number has changed, etc., it is presumed that the user apparatus <NUM> has changed users, and thus, the backend servers <NUM> may determine that the user apparatus <NUM> is unstable. The result of the stability check is then sent to the user apparatus <NUM> so that the user apparatus can perform device fingerprinting.

It may be understood that the MNO computing devices <NUM> and cell towers <NUM> are components external to the system in which the backend servers <NUM> reside and may be owned or operated by a third-party mobile network operator. A mobile network operator may be understood to be a wireless service provider, carrier, cellular company, mobile network carrier, etc. that provides wireless communications services and may own or control all elements necessary to sell and deliver services to end users including radio spectrum allocation, wireless network infrastructure, back haul infrastructure, etc..

<FIG> illustrates an example device fingerprinting according to one or more embodiments. As described above, a user apparatus may receive a request or an indication from one or more backend servers to conduct device fingerprinting. Device fingerprinting involves the user apparatus capturing the current constellation <NUM> of the device settings of the user apparatus and the user behavior biometrics. It may be understood that device fingerprinting and capturing the current constellation <NUM> may be similar to the process of taking the snapshot <NUM> described above with respect to <FIG>.

As shown, sub-constellation <NUM> indicates that, at the time of device fingerprinting, the device settings were that there were ten apps installed, three of which were social media apps, three were entertainment apps, one was a food app, one was a map app, one was a TV app, and one was a photo app. Moreover, there was one wireless device connected to the user apparatus (e.g., smartwatch) and that there were six different types of devices saved to the wireless device connection list. The user apparatus was not connected to Wi-Fi at the time of device fingerprinting, but there were five different types of wireless networks saved to the Wi-Fi network list. Further, the version of the operating system was <NUM> and the display setting was set such that hibernation mode kicks in after three minutes and the notification setting was set at silent.

As further shown, sub-constellation <NUM> indicates that, at the time of device fingerprinting, various aspects the user's unique behavior or interaction with the user apparatus are that the user rarely holds the user apparatus horizontally, always swipes left to right, has no gestural shortcuts, types approximately <NUM> words per minute on the user apparatus, the user presses the home button to transition between apps and rarely uses the app tabs to transition, selects app <NUM> before app <NUM> a majority of the time and similarly selects app <NUM> before app <NUM>. As described above, the captured constellation <NUM> of the device fingerprinting may be provided to the one or more backend servers for drift analysis.

<FIG> illustrates an example drift analysis <NUM> according to one or more embodiments. For example, the drift analysis <NUM> may involve at least (i) comparing the captured result of the current constellation <NUM> at the time of device fingerprinting and the snapshot <NUM> taken at the time of the successful second factor authentication and (ii) determining whether the differences between the current constellation <NUM> and the snapshot <NUM> are within predetermined drift threshold(s). The predetermined drift threshold limit may be a threshold deviation limit of the one or more device settings and/or the one or more user behavioral biometrics from the time of the second factor authentication to the time the device fingerprinting, e.g., a limit on how much of the device settings and/or user behavioral biometrics can change or deviate within that time span.

According to embodiments, examples of the types of deviations analyzed may include change(s) in the number of apps, change in the types of apps, change in the number of wireless devices connected to the user apparatus, change in the types of wireless devices connected to the user apparatus, change in which network the user apparatus is connected to, change in the saved list of networks that the apparatus can connect to, change in the version of the operating system, change in display settings, change in notification settings, etc..

For example, the predetermined drift threshold may set such that the difference in the number of changed apps cannot exceed three, the difference in the number of changed connected devices cannot exceed three, the difference in the number of changed wireless networks that the user apparatus can connect to cannot exceed three, the version of the operating system cannot change. Other factors may also be analyzed, such as, if the types of the apps that have been added, removed, modified or if the changed display, notification, or other settings are completely or vastly different from snapshot <NUM> to the current constellation <NUM>, then such differences may exceed and violate the predetermined drift threshold. A similar type of analysis may be applied to the differences in the user behavioral biometrics. For instance, if the types of behavior remain similar or substantially the same, then the changes would fall within the predetermined drift threshold. It may be understood that a machine learning model or neural network may be used to perform the drift analysis, where the machine learning model or neural network may be trained using training data or datasets that contain examples of various drift violations or examples of acceptable drift, etc..

As illustrated, the device setting changes between the snapshot <NUM> and current constellation <NUM> are shown in underline in current constellation <NUM>, e.g., the number of apps increased from eight to ten (difference of two), the number of wireless devices connected to the user apparatus decreased from two to one (difference of one), the number of wireless devices saved to the wireless device list increased from five to six (difference of one), the number of saved Wi-Fi networks increased from four to five (difference of one), and the notification setting changed from vibration to silent.

Moreover, the user behavioral changes between snapshot <NUM> and current constellation <NUM> are shown in underline, e.g., typing speed decreased from <NUM> words per minute to <NUM> words per minute, and that the user selects app <NUM> before selecting app <NUM>, which is a new behavior metric. The drift analysis <NUM> may reveal that all device setting changes are within the above-defined drift thresholds. Importantly, the version of the operating system remained the same. The analysis may further reveal that all user behavior changes remain substantially unchanged and that the addition of the new behavior is similar or in line with the behavior previously observed.

Accordingly, based on the drift analysis <NUM>, it may be determined that the changes between the snapshot <NUM> and the current constellation <NUM> are within the predetermined drift threshold. Thus, the second factor authentication described above (e.g., the single tap or one-tap authentication) may be allowed to persist for a predetermined duration of time until a subsequent authentication persistence check.

It may be understood that deviations in user behavior may be given more weight than deviations in device settings when determining drift violations. For example, if the user always swipes from the left to right direction (e.g., <NUM> percent of the time), but now more often swipes right to left, that may indicate that the user may not be the originally authenticated user. In other situations, changes in device settings may be given more weight, e.g., if the apps completely change in type (apps that are majority non-social media change to mostly social media apps). It may further be understood that the predetermined drift threshold may be dependent on at least the risk level of the user action, e.g., higher risk level may warrant more stringent or tighter thresholds, lower risk level may warrant lax or loose thresholds.

<FIG> illustrates an example flow diagram <NUM> according to one or more embodiments. The flow diagram <NUM> is related to at least performing an authentication persistence check and, based on the check, either allowing or disallowing a previously successful authentication to persist. It may be understood that the blocks of the flow diagram <NUM> and the features described therein are not required to be performed in any particular order. Moreover, it may be understood that the flow diagram <NUM> and the features described therein may be executed by one or more processors or any suitable computing device or computing architecture described herein.

At block <NUM>, first and second factor authentications may be performed. The first factor authentication may be based on something the user knows, e.g., ID and password input. The second factor authentication may be triggered by a second factor authentication event, such as the transfer of a large amount of money. The second factor authentication may be the single or one tap of the user's contactless smart card, as described above.

At block <NUM>, a snapshot of the constellation of the device settings of the user apparatus and/or one or more user behavioral biometrics may be taken at the time of successful second factor authentication (or first factor authentication depending on which authentication will persist) at block <NUM>. The snapshot may be provided to one or more remote backend computing devices (e.g., backend servers associated with a transaction app platform), which may be later used by the backend computing devices as a reference point for determining how much the device settings and behavioral metrics have changed.

At block <NUM>, a stability check on the user apparatus may be caused to be performed. The check may be caused by the apparatus or may be automatically initiated by the backend computing devices. The stability check may be triggered: when a specific period of time has passed since the first instance of successful authentication or based on the occurrence of an authentication event (e.g., requesting to transfer a large amount of funds via the transaction app). The stability check may be an MNO verification, which involves an MNO providing verification that the user apparatus has not significantly changed, e.g., SIM card has not changed. The result of the MNO verification may be provided to the one or more backend computing devices.

At block <NUM>, in response to a successful stability check, the backend computing devices may request the user apparatus to perform device fingerprinting. As described above, device fingerprinting may be similar to the snapshot taken at block <NUM>, except it is done at the time of the device fingerprinting. The result of the device fingerprinting is a current constellation of the device settings of the user apparatus and/or the one or more user behavioral biometrics. The current constellation may be provided to the backend computing devices for drift analysis, as described in detail above.

At block <NUM>, the user apparatus may receive the result of the drift analysis from the backend computing devices, which indicates that the authentication (e.g., second factor authentication) can or cannot persist. If it can persist, the user is not required to perform the single tap or one tap authentication again and the transfer of the funds can proceed. If it cannot persist, the user is asked to reauthenticate via the single tap or one tape authentication.

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

At least one computer-readable storage medium may include instructions that, when executed, cause a system to perform any of the computer-implemented methods described herein.

Some embodiments may be described using the expression "one embodiment" or "an embodiment" along with their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Moreover, unless otherwise noted the features described above are recognized to be usable together in any combination. Thus, any features discussed separately may be employed in combination with each other unless it is noted that the features are incompatible with each other.

With general reference to notations and nomenclature used herein, the detailed descriptions herein may be presented in terms of program procedures executed on a computer or network of computers. These procedural descriptions and representations are used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art.

A procedure is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. These operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It proves convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be noted, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to those quantities.

Further, the manipulations performed are often referred to in terms, such as adding or comparing, which are commonly associated with mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein, which form part of one or more embodiments. Rather, the operations are machine operations.

Various embodiments also relate to apparatus or systems for performing these operations. This apparatus may be specially constructed for the required purpose and may be selectively activated or reconfigured by a computer program stored in the computer. The procedures presented herein are not inherently related to a particular computer or other apparatus. The required structure for a variety of these machines will appear from the description given.

It is emphasized that the Abstract of the Disclosure is provided to allow a reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment. In the appended claims, the terms "including" and "in which" are used as the plain-English equivalents of the respective terms "comprising" and "wherein," respectively. Moreover, the terms "first," "second," "third," and so forth, are used merely as labels, and are not intended to impose numerical requirements on their objects.

Claim 1:
An apparatus (<NUM>) comprising:
a near-field communication (NFC) reader (<NUM>);
one or more processors (<NUM>) operable to execute stored instructions that, when executed, cause the one or more processors to:
authenticate a user via first factor authentication;
authenticate the user via second factor authentication different from the first factor authentication, wherein the second factor authentication comprises: a contactless card (<NUM>) being tapped to the apparatus (<NUM>) such that NFC communication is established, receiving user authentication information from the contactless card (<NUM>) via the NFC reader (<NUM>), sending the user authentication information to one or more remote computing devices, and receiving indication from the one or more remote computing devices that the user is authenticated;
determine a snapshot including one or more device settings of the apparatus and one or more user behavioral biometrics at a first time of the second factor authentication;
cause a stability check on the apparatus to be performed: (i) at a second time after the first time or (ii) when an authentication event occurs after the first time;
in response to the apparatus being stable, perform device fingerprinting on the apparatus to determine whether the apparatus is within a predetermined drift threshold from the snapshot;
in response to the apparatus being within the predetermined drift threshold, allow the second factor authentication to persist for a predetermined time period; and
in response to the apparatus not being within the predetermined drift threshold, reauthenticate the user via the second factor authentication.