System and Method for Cross-Coupling Risk Analysis and One-Time Passcodes

Abstract

Exemplary embodiments provide systems and methods for verifying actions using a physical token, such as a near-field communication (NFC)-enabled chip. A server may receive a request to perform an action and may require verification from the owner of the physical token. The owner of the physical token may log in to an application using login credentials, providing a first layer of authentication. The owner may then scan the physical token with a reader on their mobile device, providing a second layer of authentication. The scan may reveal the value of a counter on the physical token, which may be compared to a counter on the server to verify that the physical token was used as expected. If the server deems appropriate, a third (or more) layer may be required, such as scanning the owner's photo identification.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims priority to U.S. Provisional Application No. 62 / 740,352, filed Oct. 2, 2018, and is a continuation - in - part of U.S. Patent Application No. 16 / 205,119, filed Nov. 29, 2018, which claims priority to U.S. Patent Application No. 16 / 675,172, filed Nov. 5, 2019. The disclosure of which is hereby incorporated by reference in its entirety.

[0002] The present disclosure relates to encryption, and more particularly, to systems and methods for encrypted authentication of contactless cards.

Background Art

[0003] The security of data and the integrity of transactions are of great importance to businesses and consumers. As electronic transactions make up an increasingly large share of commercial activities, this need continues to grow.

[0004] When a suspicious or unusual transaction is processed, transaction verification may be required. Conventionally, this may involve sending a message to the user via email or Short Message Service (SMS) and requesting that the user confirm their intention to participate in the transaction.

[0005] These services are not only cumbersome but also vulnerable to attacks and may not be able to provide a sufficient level of security. Further, if a user keeps their card with their mobile device (e.g., both in a wallet, or the card is often kept in a wallet that is in the same place as the mobile device), an unauthorized attacker may obtain the device used for transaction authentication.

Brief Description of the Drawings

[0006]

Fig. 1A

Fig. 1B

Fig. 1C

Fig. 2A

Fig. 2B

Fig. 2C

Fig. 3

Fig. 4

Fig. 5

Fig. 6

Fig. 7

Fig. 8

Mode for Carrying Out the Invention

[0007] Exemplary embodiments provide techniques for enhancing the security of contactless cards while enabling transactions to be performed in a more efficient and user-friendly manner. Using these embodiments, it is ensured that the card is physically present with the card owner (thereby preventing transactions in case the card is stolen for unauthorized in-person transactions), and it can be ensured that the card owner approves the transaction (which can be used to verify either in-person or remote transactions). Further, the process of verifying the transaction includes an interaction with a physical token on the card. Due to this interaction, it is necessary to approve both in-person and remote transactions using the card, and unauthorized transactions can be quickly identified and rejected.

[0008] More specifically, when a user wants to access their account (e.g., on a mobile device), the system requests approval from the card owner. The card owner is required to sign in to an application running on the mobile device and scan a physical token associated with the card (e.g., a contactless chip capable of wireless communication with the mobile device such as NFC, Bluetooth®, WiFi, etc., or wired communication such as via a USB connection). These procedures confirm that the card is the physical property of the card owner. In theory, only the card owner should be able to sign in to the mobile application, and when the card is scanned by a local NFC reader, it can be confirmed that the card owner owns the card.

[0009] Each time the card is used, the counter value stored in the physical token is incremented and can be sent to a remote server for verification. As part of the scan process to verify a transaction, the counter present on the card can be compared to a remote copy stored on the server. If the counter value read from the card is not the value expected at the server, this may indicate that the card or the owner's account has been used in an unauthorized transaction (either because the card was used and the transaction not recorded due to the card's counter value not being the value expected at the server, or because an attacker is attempting to replay the transaction and replay a previous session that was captured).

[0010] Often, the counter value of the card may not exactly match the counter value stored on the server. For example, in the case of partial reading (which can occur when the user places the card near the phone without actually intending to read the value of the physical token), the token counter can be updated locally, but the remote server cannot be updated with the increased counter value. The degree to which the counter values must match can depend on the risk level of the transaction and / or the current risk profile of the environment (e.g., whether the banking institution is currently under attack). Thus, for low-risk transactions, the counter value of the card needs to match the counter value of the server within a certain predefined range (thereby allowing the system to account for accidental readings of the card). For high-risk transactions, the counter values need to match exactly or be within a narrower predefined range. The range can be determined dynamically based on what is known about the user's regular interactions with the card (e.g., if the user is prone to accidental readings of the token in the past, the range can be set higher compared to a user whose card is normally less affected by such readings). If the system determines that there is a mismatch, the first action can be to request the user to re-verify the card with an application on the mobile device. In this case, the counter value for this additional authentication needs to exceed the value included in the suspicious authentication request. If the system still cannot verify the counter value, or especially in the case of high-risk requests, further verification may be required (e.g., the application can request the user to provide biometric verification, a photo of the user, or a scan of the user's identification. Alternatively, the user can be required to physically appear at a location such as a bank for in-person verification). These actions can adapt the verification process to the risk profile.

[0011] Similarly, the risk profile can be changed based on the information collected during the verification process. For example, if a transaction was originally flagged as low risk but the counter value read during the process indicates that there may have been an illegal act, the risk associated with the transaction can be increased. In other examples, if the verification of the counter value triggers a re-verification process, the risk level associated with this user and / or transaction can increase.

[0012] Furthermore, these two options (adjusting the authentication strength based on the risk profile and adjusting the risk profile based on the authentication result) can be combined and used side by side.

[0013] The following description of the embodiments provides non-limiting representative examples that refer to numbers to specifically illustrate the features and teachings of different aspects of the present invention. It should be recognized that the described embodiments can be implemented separately from or in combination with other embodiments from the description of the embodiments. The description of the embodiments should facilitate the understanding of the present invention to the extent that other embodiments, which are not specifically covered but are within the knowledge of those skilled in the art after reading the description of the embodiments, are understood to be consistent with the application of the present invention.

[0014] FIG. 1A shows a data transmission environment 100 according to an exemplary embodiment. As will be further described below, the system 100 can include a contactless card including a physical token 106, a client device 104, a network 114, and several servers 116, 128. Although FIG. 1A shows a specific configuration of the components, those skilled in the art will understand that other configurations including more or fewer components, or components of other configurations, can be used.

[0015] Environment 100 may include one or more contactless cards, which will be further described below with reference to FIG. 1B. In some examples, the contactless card may communicate wirelessly with client device 104, such as NFC communication. The contactless card may include a physical token 106, such as a contactless chip (see FIG. 1C). The physical token 106 may maintain a copy of the counter value 108 described above, which may be incremented each time the physical token is read by a reader (such as NFC reader 110).

[0016] Environment 100 may include a client device 104, which may be a network-enabled computer. As referred to herein, a network-enabled computer may include, for example, a computer device, or, for example, a server, network appliance, personal computer (PC), workstation, mobile device, telephone, handheld PC, personal digital assistant (PDA), thin client, fat client, Internet browser, or other communication device including, but not limited to, these. Client device 104 may also be a mobile device. For example, the mobile device may include an iPhone (registered trademark), iPod (registered trademark), iPad (registered trademark) of Apple, or any other mobile device running Apple's iOS (registered trademark) operating system, any device running Microsoft's Windows (registered trademark) mobile operating system, and / or any other smartphone or similar wearable mobile device.

[0017] The client device 104 and / or the contactless card including the physical token 106 may be associated with a user 102, who may be the owner of the contactless card. The user 102 may define qualification information for accessing the mobile application of the client device 104, which may be an application associated with the service provider of the contactless card.

[0018] Client device 104 may include a short-range wireless communication reader 110 suitable for communicating with physical token 106. For example, NFC reader 100 may be used to read counter value 108 from physical token 106.

[0019] In various examples according to the present disclosure, client device 104 of environment 100 may execute one or more applications such as a software application. The software application may enable network communication with one or more components of environment 100 and may send and / or receive data. Among other computer-executable logic, client device 104 may include client-side verification logic 112 (such as the logic shown in more detail in connection with FIG. 5).

[0020] Client device 104 may communicate with one or more servers 116, 128 via one or more networks 114 and may operate as a pair from the front end to the back end with each of the transaction verification servers 116. Client device 104 may send one or more requests to server 116, for example, from a mobile device application executed on client device 104. The one or more requests may be associated with obtaining data from server 116. Server 116 may receive one or more requests from client device 104. Based on the one or more requests from client device 104, server 116 may be configured to obtain the requested data from one or more databases (not shown). Based on receiving the requested data from the one or more databases, server 116 may be configured to send the received data to client device 104, and the received data responds to the one or more requests.

[0021] The environment 100 may include one or more servers 116, 128. In some examples, the servers 116, 128 may include one or more processors coupled to memory. The servers 116, 128 may be configured as a central system, server, or platform for controlling and invoking various data at different times to execute a plurality of workflow actions. The servers 116, 128 may be configured to connect to one or more databases. The client device 104 may be connected to at least one of the servers 116, 128.

[0022] In one embodiment, the third-party server 128 may require that a transaction be verified. For example, the third-party server 128 may be a server associated with a vendor selling a product or service, and for this purpose, a purchase request is submitted in the name of the user 102. The third-party server 128 may require that the purchase be verified by the service provider.

[0023] To that end, the third-party server 128 may communicate with the transaction verification server 116 that is partnered with the service provider via the network 114. To verify a transaction, the server 116 may execute server-side verification logic 118 (such as the logic shown in FIG. 6). The logic 118 may maintain a counter window 120 that defines a range of acceptable counter values (this accounts for the accidental reading of the counter value 108 and other unintended increments as described above). The counter window 120 may include several different ranges associated with different risk levels, such as a relatively wide range for low-risk transactions and a relatively narrow range (which may require an exact match) for high-risk transactions.

[0024] The counter value 126 can be stored in the user database 122 and indexed in a record 124 associated with the physical token 106. Logic 118 can apply a counter window 120 when evaluating the counter value 126 stored in the user database 122. For example, when receiving a new counter value 108, logic 118 can compare the new counter value 108 with the stored counter value 126 to check whether the new value 108 exceeds the stored value 126. If so, logic 118 can determine whether the new value 108 exceeds the stored value 126 beyond the maximum window value (e.g., the sum of the stored value 126 and the window 120). If the new value is less than the combination of the stored value 126 and the window 120, the new value 108 can be determined to be acceptable. Otherwise, the new value 108 can be rejected and further action can be taken (as described herein). The user database 122 does not necessarily have to be a database, but can be any data structure suitable for storing the counter value 126 associated with the user 102's physical token 106.

[0025] FIG. 1B shows one or more contactless cards 130, which may comprise a payment card such as a credit card, debit card, or gift card issued by a service provider 132 displayed on the front or back of the card 130. In some examples, the contactless card 130 may comprise an identification card and is not limited thereto, having no relation with the payment card. In some examples, the payment card may comprise a dual interface contactless payment card. The contactless card 130 may comprise a substrate 134 that may include a single layer or one or more laminated layers composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 130 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7810 standard, or otherwise, the contactless card may conform to the ISO / IEC 14443 standard. However, it should be understood that the contactless card 130 according to the present disclosure may have different characteristics, and the present disclosure does not require implementing a contactless card for a payment card.

[0026] The contactless card 130 may also include identification information 136 displayed on the front and / or back of the card, and contact pads 138 representing physical tokens. The contact pads 138 may be configured to establish contact with other communication devices such as user devices, smartphones, laptops, desktops, or tablet computers. The contactless card 130 may also include a processing circuit, an antenna, and other components not shown in FIG. 1C. These components may be located behind the contact pads 138 or in other locations on the substrate 134. The contactless card 130 may also include a magnetic strip or tape that may be located on the back of the card (not shown in FIG. 1B).

[0027] As shown in FIG. 1C, the contact pad 138 of FIG. 1B may include a processing circuit 140 for storing and processing information, including a microprocessor 142 and a memory 144. The processing circuit 140 may include additional components including a processor, a memory, an error and parity / CRC checker, a data encoder, a collision prevention algorithm, a controller, a command decoder, a security primitive, and anti-tampering hardware as necessary to perform the functions described herein.

[0028] The memory 144 can be a read-only memory, a write-once / read-multiple memory, or a read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 130 can include one or more of these memories. The read-only memory can be read-only or once-programmable at the time of factory shipment. With once-programmable, it can be written once and read many times. The write-once / read-multiple memory can be programmed at some point after the memory chip is shipped from the factory. The memory may not be rewritable once programmed, but can be read many times. The read / write memory can be programmed and reprogrammed many times after factory shipment and can be read many times.

[0029] Memory 144 may be configured to store one or more applets 146, one or more counters 108, and a customer identifier 148. The one or more applets 146 may comprise one or more software applications configured to execute on one or more contactless cards, such as Java (registered trademark) card applets. However, it is understood that the applets 146 are not limited to Java card applets and may instead be any software application operable on a contactless card or other device having limited memory. The one or more counters 108 may comprise numeric counters sufficient to store integers. The customer identifier 148 may comprise a unique alphanumeric identifier assigned to a user of the contactless card 130, and the identifier may distinguish the user of the contactless card from other contactless card users. In some examples, the customer identifier 148 may identify both the customer and the account assigned to that customer and may further identify the contactless card associated with the customer's account.

[0030] Although the processor and memory elements of the foregoing exemplary embodiments have been described with reference to contact pads, the present disclosure is not so limited. It is understood that these elements may be implemented as additional elements in addition to the processor 142 and memory 144 elements located outside, or completely separated from, or within the contact pads 138.

[0031] In some examples, the contactless card 130 may comprise one or more antennas 150. The one or more antennas 150 may be disposed within the contactless card 130 and around the processing circuitry 140 of the contact pads 138. For example, the one or more antennas 150 may be integrated with the processing circuitry 140 and the one or more antennas 150 may be used with an external booster coil. As another example, the one or more antennas 150 may be external to the contact pads 138 and the processing circuitry 142.

[0032] In one embodiment, the coil of the contactless card 130 can function as the secondary side of an air-core transformer. The terminal can communicate with the contactless card 130 by cutting off power or amplitude modulation. The contactless card 130 can infer data transmitted from the terminal using a gap in the power connection of the contactless card that can be functionally maintained via one or more capacitors. The contactless card 130 can return communication by switching the load of the coil of the contactless card or load modulation. The load modulation can be detected by the coil of the terminal due to interference.

[0033] As described above, the contactless card 130 can be built on a software platform operable on a smart card with limited memory such as a Java card or other devices, and one or more applications or applets can be securely executed. The applet can be added to the contactless card and provide one-time passwords (OTP) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet can be configured to respond to one or more requests such as a near-field wireless data exchange (NDEF) request from a reader such as a mobile NFC reader, and generate an NDEF message with an encrypted and secure OTP encoded as an NDEF text tag.

[0034] As described above, an exemplary transaction can verify a transaction requested for an account associated with the contactless card via the logic 112 executed on the client device 104. FIGS. 2A-2B show an exemplary interface that can be presented on the client device 104 in response to the logic.

[0035] Before displaying the interface, the user of the client 104 can be notified that the transaction requires verification. For example, the user can receive an SMS message from the service provider, receive a notification via the service provider's application, receive a phone call or an email.

[0036] Upon receiving the notification, the user may log in to the service provider's application. For example, the user may enter a username and password to verify the user's identity. In other embodiments, the user may be verified in other ways, such as via biometric data. In some embodiments, the login may utilize two-factor authentication (2FA).

[0037] When the user logs in to the application, an interface such as interface 200 shown in FIG. 2A may be displayed. In the interface, a message 202 indicating that a suspicious transaction has been received and needs to be verified may be displayed. Message 202 may include details of the transaction, such as the value of the transaction and the name of the vendor attempting to verify the transaction.

[0038] Interface 200 may include an interactive element 204 that allows the user to flag the transaction as fraudulent if the user does not approve the transaction. When the interactive element 204 is selected, the application may send a fraud warning message indicating that the transaction in question has not been approved to the transaction verification server.

[0039] Message 202 may also include instructions for verifying the transaction if the user approves the transaction. In one embodiment, verifying the transaction may include tapping card 130 on a reader on the back of client device 104, as shown in FIG. 2B. The reader may be able to read a counter value from a physical token on card 130 and generate a message 300 (see FIG. 3) that includes counter value 304 and authentication ciphertext 306. Message 300 may be encrypted.

[0040] The counter value 304 may correspond to the most recently read counter value from the card, the authentication ciphertext 306 may be generated based on the encryption key stored in the physical token 138, and may be used to authenticate the card at the transaction verification server and ensure that the message 300 has not been tampered with or damaged.

[0041] The message 300 may also include a token identifier 302 that may identify the card 130 and / or the user associated with the card. For example, the token identifier 302 may correspond to a unique customer identifier 148 stored in the physical token 138.

[0042] Upon receiving the message 300, the transaction verification server decrypts the message 300, verifies the card and the message based on the ciphertext 306, matches the message to the user account based on the token identifier 302, and may retrieve the user record 124 (see FIG. 1A) from the transaction verification server corresponding to the user account. Next, the transaction verification server may compare the counter value 304 to the corresponding counter value 126 stored in the user database 122 to verify that the number of reads or transactions on the card matches the expected counter value stored on the server. This can verify that the user owns the card (i.e., the message 300 has not been forged) and that the number of transactions performed by the user matches the service provider's expectations. If the counter values are not in sync, this may indicate that an unauthorized transaction has been attempted and the current transaction may be rejected (or additional verification actions may be required).

[0043] Those skilled in the art will understand that the message 300 is depicted in a simplified format. In some embodiments, other components may be present in the message, or the depicted components may be combined or modified.

[0044] Figure 2C is a timing diagram showing an exemplary sequence for providing authenticated access according to one or more embodiments of the present disclosure. The system may include a contactless card 130 and a client device 104 that may include an application (which may include logic 112) and a processor.

[0045] At 202, the application communicates with the contactless card 130 (e.g., after being brought close to the contactless card 130). The communication between the application and the contactless card 130 may include a contactless card 130 that is close enough to a card reader (not shown) of the client device 104 to enable NFC data transfer between the application and the contactless card 130.

[0046] In step 204, after communication is established between the client device 104 and the contactless card 130, the contactless card 130 generates a message authentication code (MAC) ciphertext. In some examples, this can occur when the contactless card 130 is read by an application (e.g., on the client 104). In particular, this can occur upon reading of a Near Field Data Exchange (NDEF) tag, which can be created according to the NFC Data Exchange Format, such as an NFC read. For example, a reader such as an application can send a message such as an applet selection message using the applet ID of the NDEF generation applet. When the selection is confirmed, a sequence of selection file messages and subsequent read file messages can be sent. For example, the sequence can include "selection of function file", "reading of function file", and "selection of NDEF file". At this point, the counter value maintained by the contactless card 130 can be updated or incremented, and then "reading of NDEF file" can follow. At this point, a message that can include a header and a shared secret can be generated. Thereafter, a session key can be generated. The MAC ciphertext can be created from the message, which can include the header and the shared secret. Next, the MAC ciphertext can be concatenated with one or more blocks of random data, and the MAC ciphertext and the random number (RND) can be encrypted with the session key. Thereafter, the ciphertext and the header can be concatenated and encoded as ASCII hexadecimal and returned in the NDEF message format (in response to the "reading of NDEF file" message).

[0047] In some examples, the MAC ciphertext can be sent as an NDEF tag, and in other examples, the MAC ciphertext can be included together with a Uniform Resource Indicator (e.g., as a formatted string).

[0048] In some examples, the application can be configured to send a request to the contactless card 130, and the request includes an instruction for generating the MAC ciphertext.

[0049] At 206, the contactless card 130 transmits the MAC ciphertext to the application in response to a command from the client device 104.

[0050] At 208, the application communicates the MAC ciphertext with the processor.

[0051] At 210, the processor verifies the MAC ciphertext. For example, the MAC ciphertext can be decrypted. In some examples, the verification of the MAC ciphertext can be performed by a device other than the client device 104, such as a server connected to the client device 104. For example, the processor outputs the MAC ciphertext for transmission to the server, which can verify the MAC ciphertext.

[0052] FIG. 4 is a timing diagram showing an example of data exchange between an operating system on a client device, an application on the client device, a transaction verification server, and a third-party server that processes transactions.

[0053] At 402, a third-party server (e.g., a server associated with a vendor for which a credit transaction is requested) can submit a transaction request to a transaction verification server associated with a service provider. The transaction request can be generated in response to, for example, a scan of a credit card, an input of a credit card number into the vendor's payment system, an online transaction with the vendor, etc. The service provider can be identified as part of the process of receiving information related to the card.

[0054] Transaction requests can be sent to a transaction verification server, which can apply a risk analysis 404 to the requested transaction. The risk analysis 404 can identify the risk level associated with the transaction. For example, the risk analysis 404 can consider the purchase amount, the place of purchase, the user's previous purchase history, the overall risk environment (including factors such as whether institutions such as the bank that issued the contactless card 130 are currently under attack or whether other institutions have reported an increase in recent fraud) when determining whether the transaction is typical of the user's activities (and thus of low risk) or atypical (and thus of high risk).

[0055] Based on the risk analysis 404, an initial risk score can be assigned to the transaction. A set of risk levels is defined, and each risk level is associated with a range of risk scores and the required verification actions. For example, in the case of a low risk score, the low risk level may not require verification actions. In the case of a medium risk score, the intermediate risk level may require verification by the user by scanning a physical token on the mobile client (in combination with logging into the application on the mobile client). In the case of a high risk score, the high risk level may require additional verification actions in addition to the intermediate level verification actions. If the risk score is very high, the transaction can be completely rejected.

[0056] The initial risk score is compared with the range of risk scores of the risk levels and can be assigned to a specific risk level. Based on the verification actions associated with the risk level, the associated verification actions can be obtained and executed.

[0057] The example of FIG. 4 shows a situation that occurs when the initial risk score is associated with a medium risk (i.e., when it is necessary to scan and verify a physical token). Thus, at 406, a verification request is generated by the server and sent to the client application. The verification request may generate a notification notifying the user that verification of the most recent transaction is required.

[0058] In response to the notification, the user may log in to the client application using any suitable means (e.g., a combination of username / password, biometric authentication, etc.). Next, an interface (such as the one shown in FIG. 2A) is displayed to the user, and the physical token on the card may be scanned. Thus, at 408, the client application may request access from the operating system of the client device to a physical token reader (e.g., an NFC reader). At 410, the client OS may receive a response (e.g., including a counter value) from the reader and transfer the response to the client application. Actions 408 and 410 may include actions similar to those described above in relation to FIG. 2C.

[0059] At 412, the client application may generate a verification response (e.g., message 300) and send the response to the transaction verification server.

[0060] At 414, the transaction verification server may perform a verification analysis. The verification analysis may include verifying the ciphertext included in the verification response 412 and comparing the counter value received from the client with the corresponding counter value stored on the server.

[0061] As described above, the difference between the counter value stored in the physical token and the counter value stored in the transaction verification server may indicate the existence of an unauthorized transaction. However, for legitimate reasons (e.g., partial reads that are not sent to the server, initial reads that occur when the OS starts up, etc.), the counter value stored in the physical token may become out of sync with the counter value stored in the server. The risk hierarchy associated with the risk analysis may define an acceptable dispersion range between the counter value received from the client and the counter value stored in the server. For example, a relatively low-risk hierarchy may provide a relatively wide range of dispersion, while a relatively high-risk hierarchy may provide a relatively narrow range (or no range and complete matching may be required).

[0062] If the counter value is within the acceptable range, the process proceeds directly to 426, and the approval of the transaction may be sent to the third-party server.

[0063] In addition to the acceptable range of counter values, the risk hierarchy may define various escalation ranges. For example, if the counter value is not within the acceptable range but is within a secondary range, additional verification actions may be required to verify the transaction. Alternatively, the initial risk score may be re-evaluated considering the discrepancy between the counter value from the client and the counter value stored in the server, and the transaction may be escalated to a higher risk hierarchy based on the newly calculated risk score.

[0064] If the counter value is outside the secondary range, the transaction may be rejected at 426. If further verification actions are required because the counter value is outside the acceptable range, the dashed-line actions shown in Figure 4 may be executed.

[0065] For this purpose, an escalated verification request may be sent to the client application at 416. The escalated verification request may include the requested verification actions to be performed based on the escalated risk tier or the escalated risk actions required for the verification analysis. For example, the escalated verification actions may include answering security questions, providing biometric authentication, taking a photo of the user's identification, or presenting the person at a defined location.

[0066] In this example, the escalated verification request 416 requests the user to take a photo of identification such as a driver's license. Thus, at 418, the application may request access to the device camera from the client operating system. The photo may be captured and, at 420, the photo may be sent to the client application. Based on the captured photo, an escalated verification response may be generated at 422 and sent to the transaction verification server.

[0067] At 424, the server may perform an escalated verification analysis on the escalated verification response. For example, the server may compare the photo of the user in the identification with the photos stored on the server, compare the signature of the user on the identification with the stored signature, or perform other appropriate actions based on the escalated verification response (e.g., compare the biometric authentication with the biometric authentication stored on the server, receive an indication that the client device has confirmed the biometric authentication, etc.).

[0068] As an option, at 428, the server may update the current risk score based on the information determined during the verification process. For example, if the counter value is such that no additional escalated verification is required, the server may update the risk score to indicate that the risk has decreased. However, if additional escalated verification is required and the additional verification is successful, the risk score may be updated to maintain the current risk level. If authentication fails, the risk level may be updated to indicate that the future risk level will be higher.

[0069] The above actions may be performed by the client-side verification logic 500 (FIG. 5) in cooperation with the server-side verification logic 600 (FIG. 6).

[0070] The client-side verification logic 500 may include, at block 502, logic for authenticating a user to the client-side service provider application. For example, the logic may include instructions such as verification of a combination of username and password, verification of biometric login information, etc.

[0071] At block 504, a verification request may be received from the transaction verification server. The verification request may specify details of the transaction being verified and / or the verification actions required (such as scanning a physical token of a card).

[0072] Blocks 502 and 504 may be executed in reverse so as to receive a verification request prior to authentication to the application.

[0073] In response to the verification request, the client application may, at block 506, invoke a short-range (e.g., NFC) reader of the client device. At block 508, the reader may be used to exchange or read a physical token and information (including a counter value encrypted cryptographically with one or more security keys on the token).

[0074] At block 510, the device may generate a verification response. This may include the encrypted and encoded counter value read from the token at 508. At block 512, the verification response may be sent to the transaction verification server.

[0075] If the server determines that escalated verification is required, at block 514, the client may receive the escalated verification request and execute the specified escalated verification action (e.g., capture a photo of the user's identification). The client may respond to the escalated verification request using the information captured in response to the escalated verification action.

[0076] FIG. 6 shows the corresponding logic 600 executed by the verification server.

[0077] At block 502, the verification server may receive a transaction request from the vendor server. The transaction request may specify the identity of the vendor, the amount of the transaction, and other relevant details that may be used by the risk analysis executed at block 604.

[0078] Based on the risk analysis, an initial risk score may be calculated and the associated verification action may be obtained. In some cases, the verification action may not be necessary. The system may determine whether this is the case at block 606, and if verification is not required (e.g., because the risk score is below a pre-defined lower threshold), the process may proceed to block 608 and the transaction may be approved. Accordingly, an approval message may be generated and sent to the vendor server.

[0079] If verification is required, at block 610, the server may send a verification request to the client device associated with the user account assigned to the transaction (e.g., based on information obtained from the user database 122 in FIG. 1A). At block 612, the server may receive a verification response having the information requested from the client.

[0080] Process the verification response, for example, authenticate the ciphertext of the verification response and obtain the counter value. The server may identify the risk level determined by the risk analysis executed in block 604 at block 614.

[0081] In this example, two risk levels (high and low) are defined. Based on the risk level, a range of counter values can be defined (for example, a narrow window for the high risk level and a wide window for the low risk level). In some cases, the range of counter values can be a predetermined range associated with the risk score. Also, the range of counter values can be determined dynamically based on the risk score or risk factors (such as the current risk level of the environment). There can be multiple different risk levels, each having its own window size.

[0082] If the received counter value is within the range specified for the risk level (yes at block 618 or 616), the process proceeds to block 608 and the transaction may be approved.

[0083] On the other hand, if the counter value is not within the range specified for the risk level (no at block 616 or 618), the process may proceed to block 620. Optionally, escalated verification can be performed at this block. As part of the escalated verification procedure, an updated risk score can be calculated and the risk score can be compared with a new risk level. Alternatively, an escalated verification action defined for the current risk level can be executed.

[0084] If the escalated verification is successful, the process proceeds to block 608, where the transaction may be approved. If the escalated verification is not successful, or if the escalated verification is not performed at this stage, the process proceeds to block 622, where the transaction may be rejected. Alternatively, if the escalated verification was not successful, the process returns to block 620, where a further updated risk score may be calculated. This process may be repeated until a predetermined maximum number of iterations occurs, until the risk score exceeds a predetermined maximum threshold, or until a predefined stop condition is met.

[0085] At any point during this process (e.g., during approval or rejection at block 608 and / or 622), data from the authentication process may be fed back to the system for use as part of the risk calculation process. Thus, the risk calculation may be updated based on the authentication / verification procedure, and vice versa. Thereby, the system may be able to generate a feedback loop in which the authentication process affects the risk assessment and the risk assessment affects the authentication process.

[0086] The above method may be embodied as instructions on a computer-readable medium or as part of a computing architecture. FIG. 7 shows an embodiment of an exemplary computing architecture 700 suitable for implementing various embodiments as described above. In one embodiment, the computing architecture 700 may comprise or be implemented as part of an electronic device such as a computer 701. In this context, the embodiments are not limited.

[0087] The terms "system" and "component" as used in this application are intended to refer to any computer-related entity, be it hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture 700. For example, a component can be a process running on a processor, a processor, a hard disk drive, a plurality of storage drives (of optical and / or magnetic storage media), an object, an executable, a thread of execution, a program, and / or a computer, but not limited to these. As an example, both an application running on a server and the server can be components. One or more components can reside within a process and / or thread of execution, and a component can be localized on one computer and / or distributed between two or more computers. Further, components can be communicatively coupled to each other by various types of communication media and can coordinate their operations. The coordination can include the one-way or two-way exchange of information. For example, a component can communicate information in the form of signals communicated through a communication medium. The information can be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, further embodiments can alternatively use data messages. Such data messages can be transmitted through various connections. Examples of connections include a parallel interface, a serial interface, and a bus interface.

[0088] The computing architecture 700 includes various common computing elements such as one or more processors, multi-core processors, coprocessors, memory units, chip sets, controllers, peripheral devices, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, power supplies, etc. However, embodiments are not limited to implementation by the computing architecture 700.

[0089] As shown in FIG. 7, computing architecture 700 includes a processing unit 702, a system memory 704, and a system bus 706. The processing unit 702 can be any of a variety of commercially available processors including, but not limited to, AMD (R) Athlon (R), Duron (R), and Opteron (R) processors, ARM (R) application, embedded, and secure processors, IBM (R) and Motorola (R) DragonBall (R) and PowerPC (R) processors, IBM and Sony (R) Cell processors, Intel (R) Celeron (R), Core (2) Duo (R), Itanium (R), Pentium (R), Xeon (R), and XScale (R) processors and similar processors. Dual microprocessors, multi-core processors, and other multiprocessor architectures can also be used as the processing unit 702.

[0090] The system bus 706 provides an interface to system components including, but not limited to, the system memory 704 to the processing unit 702. The system bus 706 can be any of several types of bus structures that can further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. An interface adapter can connect to the system bus 706 via a slot architecture. Examples of slot architectures include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), etc.

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

[0092] The system memory 704 can include various types of computer-readable storage media in the form of one or more high-speed memory units, such as read-only memory (ROM), random access memory (RAM), dynamic RAM (DRAM), double data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, ferroelectric polymer memory, ovonic memory, polymer memory such as phase change or ferroelectric memory, silicon oxide nitride oxide silicon (SONOS) memory, magnetic or optical cards, arrays of devices such as redundant arrays of independent disks (RAID) drives, solid state memory devices (e.g., USB memory, solid state drives (SSD)), and other types of storage media suitable for storing information. In the illustrated embodiment shown in FIG. 7, the system memory 704 can include non-volatile memory 708 and / or volatile memory 710. The basic input / output system (BIOS) can be stored in the non-volatile memory 708.

[0093] Computing architecture 700 can include various types of computer-readable storage media in the form of one or more low-speed memory units, including an internal (or external) hard disk drive (HDD) 712, a magnetic floppy disk drive (FDD) 714 that reads from or writes to a removable magnetic disk 716, and an optical disk drive 718 that reads from or writes to a removable optical disk 720 (e.g., CD-ROM or DVD). The HDD 712, FDD 714, and optical disk drive 720 can each be connected to the system bus 706 by an HDD interface 722, an FDD interface 724, and an optical drive interface 726, respectively. The HDD interface 722 for external drive use can include at least one or both of universal serial bus (USB) and IEEE 694 interface technologies.

[0094] The drives and associated computer-readable media provide volatile and / or non-volatile storage such as data, data structures, computer-executable instructions, etc. For example, a number of program modules can be stored in the drives and memory units 708, 712, including an operating system 728, one or more application programs 730, other program modules 732, and program data 734. In one embodiment, the one or more application programs 730, other program modules 732, and program data 734 can include various applications and / or components of, for example, the messaging system 500.

[0095] The user can input commands and information into the computer 701 via one or more wired / wireless input devices, such as a pointing device like the keyboard 736 and the mouse 738. Other input devices may include a microphone, an infrared (IR) remote control, a radio frequency (RF) remote control, a game pad, a stylus pen, a card reader, a dongle, a fingerprint reader, a grab, a graphic tablet, a joystick, a keyboard, a retina reader, a touch screen (e.g., capacitive, resistive, etc.), a trackball, a track pad, a sensor, a stylus, and so on. These and other input devices are often connected to the processing unit 702 via an input device interface 740 coupled to the system bus 706, but can be connected by other interfaces such as a parallel port, an IEEE694 serial port, a game port, a USB port, an IR interface, and the like.

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

[0097] Computer 701 may operate in a network environment using logical connections via wired and / or wireless communication to one or more remote computers such as remote computer 744. Remote computer 744 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer device, or other common network node, and typically includes many or all of the elements described in relation to computer 701, but for brevity, only memory / storage device 746 is shown. The logical connections shown include wired / wireless connections to a local area network (LAN) 748 and / or a larger network, such as a wide area network (WAN) 750. Such LAN and WAN network environments are common in offices and enterprises and facilitate enterprise-scale computer networks such as intranets. All of these can be connected to a global communication network such as the Internet, for example.

[0098] When used in a LAN networking environment, computer 701 is connected to LAN 748 via a wired and / or wireless communication network interface or adapter 752. Adapter 752 can facilitate wired and / or wireless communication to LAN 748, which may include a wireless access point disposed thereon to communicate with the wireless function of adapter 752.

[0099] When used in a WAN networking environment, computer 701 may include a modem 754, or be connected to a communication server on WAN 750, or have other means for establishing communication on WAN 750, such as via the Internet. Modem 754 can be internal or external, a wired and / or wireless device, and is connected to system bus 706 via input device interface 740. In a network environment, program modules shown with respect to computer 701, or portions thereof, can be stored in remote memory / storage device 746. The network connections shown are exemplary, and it will be understood that other means of establishing communication links between computers can be used.

[0100] Computer 701 is operable to communicate with wired and wireless devices or entities using the IEEE 802 standard family, such as a wireless device operably arranged for wireless communication (e.g., IEEE802.13 wireless modulation technology). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, Bluetooth® wireless technology, etc. Thus, the communication can be in a pre-defined structure similar to a conventional network, or just ad-hoc communication between at least two devices. A Wi-Fi network provides a secure and reliable high-speed wireless connection using wireless technologies called IEEE802.13x (a, b, g, n, etc.). Wi-Fi networks can be used to connect computers to each other, to the Internet, or to a wired network (using media and functions related to IEEE802.3).

[0101] FIG. 8 is a block diagram showing an exemplary communication architecture 800 suitable for implementing the various embodiments described above. Communication architecture 800 includes various common communication elements such as a transmitter, receiver, transceiver, radio, network interface, baseband processor, antenna, amplifier, filter, power supply, etc. However, the embodiments are not limited to implementation by communication architecture 800.

[0102] As shown in FIG. 8, the communication architecture 800 includes one or more clients 802 and a server 804. The client 802 may implement the client device 510. The server 804 may implement the server device 526. The client 802 and the server 804 are operably connected to one or more respective client data stores 806 and server data stores 808 and may be used to store information local to the respective client 802 and server 804, such as cookies and / or related context information.

[0103] The client 802 and the server 804 may communicate information with each other using a communication framework 810. The communication framework 810 may implement well-known communication technologies and protocols. The communication framework 810 may be implemented as a packet-switched network (e.g., a public network such as the Internet, a private network such as a corporate intranet, etc.), a circuit-switched network (e.g., a public switched telephone network), or a combination of a packet-switched network and a circuit-switched network (using appropriate gateways and translators).

[0104] The communication framework 810 may implement various network interfaces configured to receive, communicate with, and connect to a communication network. The network interface may be regarded as a special form of the input / output interface. The network interface may adopt connection protocols including, but not limited to, direct connection, Ethernet (such as thick, thin, twisted pair 10 / 100 / 1000BaseT, etc.), token ring, wireless network interface, cellular network interface, IEEE802.8a-x network interface, IEEE802.16 network interface, IEEE802.20 network interface, etc. Further, multiple network interfaces may be used to cooperate with various communication network types. For example, multiple network interfaces may be used to enable communication via broadcast, multicast, and unicast networks. When speed and capacity are required due to processing requirements, a distributed network controller architecture may likewise be used to pool, load-balance, or otherwise increase the communication bandwidth required by the client 802 and the server 804. The communication network may be any one and combination of wired and / or wireless networks including, but not limited to, direct interconnection, secure custom connection, private network (such as a corporate intranet), public network (such as the Internet), personal area network (PAN), local area network (LAN), metropolitan area network (MAN), operation mission as a node on the Internet (OMNI), wide area network (WAN), wireless network, cellular network, and other communication networks.

[0105] The components and functions of the above-described device may be implemented using any combination of discrete circuits, application-specific integrated circuits (ASICs), logic gates, and / or single-chip architectures. Further, the functions of the device may be implemented using a microcontroller, a programmable logic array and / or a microprocessor, or any combination of the foregoing where appropriate. Note that hardware, firmware, and / or software elements may sometimes be referred to herein collectively or individually as “logic” or “circuit.”

[0106] It should be understood that the exemplary devices shown in the above block diagrams may represent one example of the many potential implementations for explaining the functions. Thus, the division, omission, or inclusion of the block functions shown in the accompanying figures does not necessarily mean that the hardware components, circuits, software, and / or elements for implementing these functions are divided, omitted, or included in the embodiments.

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

[0108] Some embodiments may be described using the phrase “one embodiment” or “an embodiment” along with its derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The phrase “in one embodiment” appearing in various places in this specification does not necessarily refer to the same embodiment. Further, unless otherwise specified, it is recognized that the above features can be used together in any combination. Thus, any features described individually may be used in combination with each other, provided that these features are not noted to be incompatible with each other.

[0109] Referring generally to the notations and terms used herein, the detailed description herein may be presented with respect to program procedures executed on a computer or a network of computers. The descriptions and representations of these procedures are used by those skilled in the art to most effectively convey the substance of their work to other skilled persons.

[0110] The procedures herein are generally considered to be a coherent series of operations leading to a desired result. These operations are those that require physical manipulation of physical quantities. Usually, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated, but not necessarily so. It is sometimes convenient, mainly for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc. However, it should be noted that all of these and similar terms are merely convenient labels associated with appropriate physical quantities and nothing more.

[0111] Furthermore, the operations performed are often referred to in terms such as addition or comparison, which are usually associated with intellectual operations performed by a human operator. None of the operations described herein, which form part of one or more embodiments, require such capabilities of a human operator, nor are they desirable in most cases. Rather, the operations are machine operations. Useful machines for performing the operations of the various embodiments include general-purpose digital computers or similar devices.

[0112] Some embodiments may be described using the expressions "coupled" and "connected" along with their derivatives. These terms are not necessarily intended to be synonyms of each other. For example, some embodiments are described using the terms "connected" and / or "coupled" to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term "coupled" may mean that two or more elements are not in direct contact with each other but still cooperate or interact with each other.

[0113] The various embodiments also relate to an apparatus or system for performing these operations. The apparatus can be specially constructed for the required purposes or can comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. The procedures shown herein are not inherently related to a particular computer or other apparatus. Various general-purpose machines can be used with the programs described in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for these various machines will become apparent from the given description.

[0114] It is emphasized that the abstract of the disclosure is provided to enable the 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. Further, in the foregoing detailed description, for the purposes of simplifying the disclosure, it can be seen that various features are grouped together in a single embodiment. This method of disclosure should not 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, the subject matter of the invention is less than all of the features of a single disclosed embodiment. Accordingly, the following claims are incorporated into the detailed description, with each claim standing on its own as a separate embodiment. In the appended claims, the terms "comprising" and "therein" are used as the plain English equivalents of the terms "including" and "wherein", respectively. Also, the terms "first", "second", "third", etc. are used merely as labels and are not intended to impose numerical requirements on their objects.

[0115] The foregoing includes examples of the disclosed architecture. Of course, it is not possible to describe every possible combination of components and / or methodologies, but one of ordinary skill in the art will recognize that many more combinations and permutations are possible. Accordingly, the novel architecture is intended to embrace all such alterations, modifications, and variations that fall within the spirit and scope of the appended claims.

Claims

1. A non - transitory computer - readable medium storing instructions which, when executed by a processor, cause the processor to: receive, by a computing device, a request from a verification server, wherein the request is associated with a user account associated with a user; perform a first verification action by authenticating a username and a password of the user for accessing an application on the computing device to authenticate the identity of the user on the computing device; perform a second verification action by the application on the computing device, wherein the second verification action comprises receiving a code from a contactless card via a short - range communication protocol; generate, by the application on the computing device, a verification response package identifying the user and the code obtained from the contactless card; transmit, by the application on the computing device, the response package to the verification server; store the instructions for causing the above to be executed, wherein the code is a counter stored on the contactless card that is incremented each time the code is read from the contactless card. The medium.

2. The medium according to claim 1, wherein the short - range communication protocol is a Near - Field Communication (NFC) protocol.

3. The medium according to claim 1, wherein the contactless card is a debit card, a point card, or a credit card.

4. The medium according to claim 1, further storing instructions for causing the processor to receive and process an escalated verification request, wherein the escalated verification request comprises a requested verification action.

5. The requested verification action comprises a request to present a security question, and the medium causes the processor to: present the security question via the application and on a display on the computing device; receive, by the application, a response to the security question; transmit, by the application, the response to the verification server. The medium according to claim 4, further storing instructions for causing the execution.

6. The requested verification action comprises a request to present a biometric input, The medium causes the processor to receive the biometric input by the application and via a biometric device of the computing device, transmit the biometric input to the verification server by the application, The medium according to claim 4, further storing instructions for causing the execution.

7. The requested verification action comprises a request to provide a photo, The medium causes the processor to receive the photo from a camera of the computing device by the application, generate, by the application, a response to the escalated verification request, the response including the photo, transmit the response to the verification server by the application, The medium according to claim 4, further storing instructions for causing the execution.

8. The photo is a photo of an identifier associated with the user, the medium according to claim 7.

9. A computer-implemented method, processing, by a computing device, a request from a verification server, the request being associated with a user account associated with a user, performing, by the computing device, a first verification action on the computing device, the first verification action authenticating a username and a password associated with the user for accessing an application and executing the application in response to verification of the username and the password, performing, by the application on the computing device, a second verification action, the second verification action presenting a prompt to provide a physical token within a short-range communication range and receiving a code from the physical token based on a short-range communication protocol, generating, by the application on the computing device, a verification response package identifying the user and the code received from the physical token The application on the computing device transmits the response package to the verification server. The code is a counter that is incremented each time the code is read from the physical token and stored in the physical token. A computer-implemented method. **Claim 10**: A computer-implemented method according to claim 9, comprising receiving an escalated verification request, the escalated verification request comprising a requested verification action. **Claim 11** The requested verification action comprises a request to present a security question. The method comprises: presenting, by the application, the security question on a display of the computing device; receiving, by the application, a response to the security question; transmitting, by the application, the response to the verification server. A computer-implemented method according to claim 10. **Claim 12**: The requested verification action comprises a request to present a biometric input. The method comprises: receiving, by the application, the biometric input via a biometric device of the computing device; transmitting, by the application, the biometric input to the verification server. A computer-implemented method according to claim 10. **Claim 13** The requested verification action comprises a request to present a photo. The method comprises: receiving, by the application, the photo from a camera of the computing device; generating, by the application, a response to the escalated verification request, the response including the photo; transmitting, by the application, the response to the verification server. A computer-implemented method according to claim 10. **Claim 14**: An apparatus comprising: a memory storing instructions for one or more applications; a hardware processor circuit, receiving, by a first application of the one or more applications, a request from a verification server, the request being associated with a user account associated with a user. ​ ​ The first verification action is to be executed on a computing device by the first application among the one or more applications based on the authentication of the user's identity, and the first verification action includes verifying the username and the user's password to continue executing the first application. The first application provides a prompt to present a physical token within the short-range communication range of the computing device, and executes a second verification action by scanning a code from the physical token based on a short-range communication protocol. The application generates a verification response package that identifies the user and the code obtained from the physical token. The application transmits the response package to the verification server. A hardware processor circuit configured to execute instructions including the above. The code is a counter stored in the physical token that is incremented each time the code is read from the physical token. Device.

15. The hardware processor circuit is configured to receive an escalated verification request to answer a security question, present the security question on a display, receive a response to the security question, and transmit the response to the verification server. The device according to claim 14, wherein the hardware processor circuit is configured to execute instructions including the above.

16. The hardware processor circuit is configured to receive an escalated verification request to present a biometric input, receive the biometric input by a biometric device, and transmit the biometric input to the verification server. The device according to claim 14, wherein the hardware processor circuit is configured to execute instructions including the above.

17. The hardware processor circuit is configured to receive an escalated verification request to present a photo, receive the photo from a camera, and generate a response to the escalated verification request, where the response includes the photo. transmitting the response to the verification server; The apparatus according to claim 14, comprising a hardware processor circuit configured to execute an instruction.

Images