Delegated management of authorizations using contactless cards

Abstract

To provide an apparatus and a method for delegated administration of permissions using a contactless card.SOLUTION: A permission module to be executed on a computing device is configured to: receive a request from a first account to grant an access to a computing resource to a second account; receive permission data of the first account from a contactless card and encrypted data generated by the contactless card; transmit the permission data and the encrypted data to an authentication server; verify the encrypted data on the basis of at least partially, a private key; determine, on the basis of the permission data, that the first account has permissions to grant an access to the computing resource; and receive, from the authentication server, an instruction to verify the encrypted data and a permission vector associated with the second account, the permission vector reflecting the grant of access to the computing resource to the second account.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] Related Applications This application claims priority to U.S. Patent Application No. 16 / 360,149, entitled "Delegated Management of Authorizations Using Contactless Cards," filed March 21, 2019, the contents of which are incorporated herein by reference in their entirety.

[0002] TECHNICAL FIELD Embodiments herein relate generally to computing platforms, and more particularly to delegated management of permissions to use contactless cards. [Background technology]

[0003] In many cases, users must have permission to access and / or perform actions using computing resources. As the number of users in an organization increases, the complexity and difficulty of managing permissions within the organization increases. Traditional solutions for managing permissions require significant user effort and often lack robust security measures. Summary of the Invention

[0004]

[0006] Embodiments disclosed herein provide systems, methods, products, and computer-readable media for delegated management of permissions using contactless cards. In one example, an authorization module may receive a request from a first account to grant a second account access to a computing resource, the computing resource comprising one or more of (i) an application, (ii) data, and (iii) an operation performed using the application. The authorization module may receive authorization data associated with the first account and encrypted data generated by the contactless card from a communication interface of the contactless card associated with the first account, and an applet on the contactless card may generate the encrypted data based at least in part on a private key of the contactless card stored in memory of the contactless card. The authorization module may transmit the authorization data and the encrypted data to an authentication server. The authentication server may verify the encrypted data by decrypting the encrypted data based at least in part on a private key of the contactless card associated with the first account stored in memory of the authentication server, and determine, based on the authorization data associated with the first account, that the first account has permission to grant access to the computing resource to the second account. The authorization module may receive, from the authentication server, instructions for verifying the encrypted data and an authorization vector associated with the second account, where the authorization vector may reflect granting access to the computing resource to the second account. [Brief explanation of the drawings]

[0005] [Figure 1A] 1 illustrates an embodiment of a system for implementing delegated management of permissions using contactless cards. [Figure 1B] 1 illustrates an embodiment of a system for implementing delegated management of permissions using contactless cards. [Figure 2A] 1 illustrates an embodiment of delegated management of permissions using contactless cards. [Figure 2B]1 illustrates an embodiment of delegated management of permissions using contactless cards. [Figure 3A] 1 illustrates an embodiment of delegated management of permissions using contactless cards. [Figure 3B] 1 illustrates an embodiment of delegated management of permissions using contactless cards. [Figure 3C] 1 illustrates an embodiment of delegated management of permissions using contactless cards. [Figure 3D] 1 illustrates an embodiment of delegated management of permissions using contactless cards. [Figure 3E] 1 illustrates an embodiment of delegated management of permissions using contactless cards. [Figure 3F] 1 illustrates an embodiment of delegated management of permissions using contactless cards. [Figure 4] 1 illustrates an embodiment of delegated management of permissions using contactless cards. [Figure 5] 1 illustrates an embodiment of authorization data. [Figure 6] 1 illustrates a first logic flow embodiment. [Figure 7] 10 illustrates a second logic flow embodiment. [Figure 8] 10 illustrates a third logic flow embodiment. [Figure 9] 1 illustrates an embodiment of a computing architecture. [Figure 10A] An example of a contactless card is shown. [Figure 10B] An example of a contactless card is shown. DETAILED DESCRIPTION OF THE INVENTION

[0006]

[0003] Embodiments disclosed herein provide secure techniques for using contactless cards for delegated management of permissions. Typically, during the manufacture of a contactless card, the contactless card is personalized to include data of an associated user. For example, the memory of the contactless card may store one or more applets, private keys, card data (e.g., account numbers, etc.), and authorization data. The user associated with the contactless card may then delegate permissions, access resources, and / or perform operations using the contactless card.

[0007] For example, a first user may wish to access data stored in a database via a computing device. The authorization module may control access to the database and output a notification specifying that the user tap their contactless card to the computing device. The user may then tap the contactless card to the computing device, which may bring the contactless card within communication range of the computing device. In doing so, an applet running on the contactless card may generate encrypted data using a private key and send it to the computing device along with authorization data stored in the contactless card's memory. The authorization module may receive the encrypted data and authorization data generated by the contactless card and send the received data to an authentication server for verification. The authentication server may then verify the encrypted data using a copy of the private key stored in the server's memory (or other secure element, such as a hardware security module (HSM)). If the authentication server can decrypt the encrypted data using the private key, the authentication server verifies the encrypted data and sends an indication of verification to the authorization module. In some embodiments, the authentication server sends an instance of the user's authorization data to the authorization module. The authorization module may then authorize the user to access the data stored in the database upon receipt of an indication of verification of the encrypted data by the authentication server.

[0008] Advantageously, embodiments disclosed herein improve the security of devices, applications, and / or data. For example, by requiring verification of encrypted data generated by a contactless card to access an application and / or data, the security of the application and / or data is improved. As another example, by requiring verification of encrypted data before performing an operation (e.g., a purchase, an extension of credit, etc.), the security of such operation and associated assets is improved. Furthermore, by requiring verification of encrypted data as a condition of attempting to delegate authorization, the security of delegated management of authorization is improved.

[0009] With general reference to the notation and nomenclature used herein, one or more portions of the detailed descriptions which follow 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. The procedures are described herein and are generally conceived to be self-consistent sequences of operations leading to a desired result. These operations are operations 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 is sometimes convenient, 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 these quantities.

[0010] Further, these operations are often referred to in terms, such as adding or comparing, which are commonly associated with mental operations performed by a human operator. However, no such capability of a human operator is necessary, or desirable in most cases, for any of the operations described herein forming part of one or more embodiments. Rather, these operations are machine operations. Useful machines for performing the operations of the various embodiments include digital computers selectively activated or configured by a computer program stored therein and written in accordance with the teachings herein, and / or include apparatuses or digital computers specially constructed for the required purposes. Various embodiments also relate to apparatuses or systems for performing these operations. These apparatuses may be specially constructed for the required purposes. The required structure for these various machines will be apparent from the description given.

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

[0012] FIG. 1A illustrates a schematic diagram of an exemplary system 100 consistent with disclosed embodiments. As shown, the system 100 includes one or more contactless cards 101, one or more computing devices 110, one or more authentication servers 120, and one or more host systems 150. The contactless cards 101 represent any type of payment card, such as a credit card, a debit card, an ATM card, or a gift card. The contactless cards 101 may include one or more communication interfaces 107, such as a radio frequency identification (RFID) chip, configured to communicate with the computing devices 110 via NFC, EMV standards, or other short-range protocols for wireless communication. While NFC is used as an example communication protocol, the present disclosure is equally applicable to other types of wireless communication, such as Bluetooth and / or Wi-Fi. The computing devices 110 represent any type of network-enabled computing device, such as a smartphone, a tablet computer, a wearable device, a laptop, a portable gaming device, a mobile device, a workstation, a desktop computer, a server, or the like. Authentication server 120 and host system 150 are representative of any type of computing device, such as a server, a workstation, a computing cluster, a cloud computing platform, a virtualized computing system, and the like.

[0013] As shown, memory 111 of computing device 110 includes an instance of operating system (OS) 112. Examples of operating systems 112 include Android® OS, iOS®, Linux®, macOS®, and Windows® operating systems. As shown, OS 112 includes one or more applications 113, an instance of authorization module 114-1, and data 115. Application 113 represents any type of executable code, such as an application, service, script, etc. Data 115 represents any data stored on a computer-readable medium. While shown as stored in memory 102, data 115 may be stored in non-volatile storage of computing device 110 (or communicatively connected to computing device 110).

[0014] Authorization modules 114 (including authorization module 114-1, authorization module 114-2 of server 120, and authorization module 114-3 of host system 150) are generally configured to enforce delegated authorization in system 100 by verifying that an actor attempting to perform an operation has the necessary permissions as reflected in authorization data 106 (including instances of authorization data 106-1, 106-2, 106-3, and 106-4). Authorization data 106 represents any data structure that reflects whether an associated user is authorized to perform an attempted operation and / or access a given resource. For example, authorization data 106 may be a vector, where each element of the vector reflects whether the user can perform the attempted operation and / or access a given resource. The attempted operation may include any type of operation, such as a user (e.g., an administrator) granting, modifying, and / or revoking permissions to other users. Additional examples of attempted operations include running an application (e.g., application 113 of computing device 110, application 152 of host system 150, etc.), accessing particular functions and / or interfaces of an application, accessing data (e.g., data 115 of computing device 110, data 151 of host system 150, etc.), and performing an operation using the application and / or data. Although shown as a separate entity, authorization module 114 and / or related functionality described herein may be integrated into OS 112, application 113, application 152, and / or any other authorization management platform. Thus, the particular configurations shown in FIGS. 1A-1B should not be considered limiting of the present disclosure.

[0015] The authorization module 114 may further consider data generated by the contactless card 101 when determining whether to grant and / or deny an attempted operation. For example, a system administrator may use the authorization application 113 to grant a new employee access to the accounting application 113 and corresponding accounting data 151 of the host system 150. The authorization module 114-1 receives an indication of an authorization delegation attempt from the authorization application 113 and / or the OS 112. The authorization module 114-1 may output a notification to the administrator's computing device 110 to complete the attempted authorization delegation. The notification may instruct the user to tap the contactless card 101 to the computing device 110, thereby bringing the contactless card 101 sufficiently close to the card reader 119 of the computing device 110 to enable data transfer (e.g., NFC data transfer, Bluetooth data transfer, etc.) between the communication interface 107 of the contactless card 101 and the card reader 119 of the computing device 110. In some embodiments, computing device 110 may trigger card reader 119 via an application program interface (API) call. In one example, computing device 110 triggers card reader 119 via an API call in response to receiving an indication of an attempted operation (e.g., from OS 112, application 113, data 115, etc.). Additionally and / or alternatively, computing device 110 may trigger card reader 119 based on periodically polling card reader 119. More generally, computing device 110 may trigger card reader 119 to communicate using any viable method.

[0016] After communication is established between the computing device 110 and the contactless card 101, the applet 103 executing on a processor (not shown) of the contactless card 101 generates encrypted data 105 and transmits it to the computing device 110 via the communication interface 107. For example, the applet 103 of the contactless card 101 may use an encryption algorithm to generate an encrypted payload of the encrypted data 105 based at least in part on the private key 104 stored in the memory 102 of the contactless card 101. In such an embodiment, the private key 104 and some other data (e.g., a user identifier, an account identifier, etc.) may be provided as inputs to the encryption algorithm, which outputs the encrypted data 105. In general, the applet 103 may use any type of encryption algorithm and / or system to generate the encrypted data 105, and the use of a particular encryption algorithm as an example herein should not be considered limiting of the disclosure. In some embodiments, the applet 103 may perform encryption using a key diversification technique to generate the encrypted data 105. Examples of key diversification techniques are described in U.S. Patent Application No. 16 / 205,119, filed November 29, 2018. The aforementioned patent application is incorporated herein by reference in its entirety.

[0017] Once generated, applet 103 may transmit encrypted data 105 to authorization module 114-1 of computing device 110, for example, via NFC. In some embodiments, applet 103 may transmit authorization data 106-1 to authorization module 114-1. Authorization module 114-1 may then generate an indication of the requested operation (or provide instructions received from OS 112 and / or application 113) as part of request 117 that includes encrypted data 105. Request 117 generally includes an indication of the attempted operation (e.g., the new employee's account identifier, an indication of accounting data in data 151, and an indication of accounting application 113, etc.) and encrypted data 105. Authorization module 114-1 may then transmit request 117 (including encrypted data 105) to authentication application 123 of authentication server 120. However, in some embodiments, encrypted data 105 is transmitted separately from request 117.

[0018] Once received, authentication application 123 may then attempt to authenticate the encrypted data 105 received in request 117. For example, authentication application 123 may attempt to decrypt the encrypted data 105 using a copy of private key 104 stored in memory 122 of authentication server 120. Private key 104 may be identical to the private key 104 stored in memory 102 of contactless card 101, where each contactless card 101 is manufactured to include a unique private key 104 (and authentication server 120 stores a corresponding copy of each unique private key 104). Thus, authentication application 123 may successfully decrypt the encrypted data 105, thereby verifying the encrypted data 105. Although private key 104 is shown stored in memory 122, private key 104 may be stored elsewhere, such as in a secure element and / or a hardware security module (HSM). In such an embodiment, the secure element and / or HSM may use the private key 104 and the encryption function to decrypt the encrypted data 105 .

[0019] For example, as mentioned, the user identifier of the user requesting to perform the operation may be used to generate the encrypted data 105. In such an example, the authentication application 123 may decrypt the encrypted data 105 using the private key 104 of the authentication server 120. If the result of the decryption yields a user identifier associated with the requesting user's account in the account data 124, the authentication application 123 verifies the encrypted data 105. If the authentication application 123 cannot decrypt the encrypted data to yield the expected result (e.g., the user identifier of the account associated with the contactless card 101), the authentication application 123 does not verify the encrypted data 105. Because the verification failed, the authentication application 123 sends an indication that the verification failed to the authorization module 114-1, which denies the requested operation (e.g., a request to grant the new employee access to the accounting application 113 and / or the accounting data 151).

[0020] If the authentication application 123 verifies the encrypted data 105, the authentication application 123 and / or the authorization module 114-2 may determine whether the requesting user has permission to grant the new employee access to the identified resource. For example, the authentication application 123 and / or the authorization module 114-2 may determine whether the requesting user's authorization data 106-3 in the account data 124 (and / or the authorization data 106-1, 106-2 received from the computing device 110) indicates whether the administrator has permission to grant access to the new employee.

[0021] 1B illustrates an embodiment in which authentication application 123 and / or authorization module 114-2 determine that authorization data 106 reflects that the administrator has permission to grant access to the new employee. In response, authentication application 123 and / or authorization module 114-2 may send approval 118 to authorization module 114-1 of computing device 110. Further, authentication application 123 and / or authorization module 114-2 may update the new employee's authorization data 106-3 to reflect that the new employee may access accounting application 113 and accounting data in data 151. Accordingly, approval 118 may include the updated authorization data 106. Authorization module 114-1 and / or authorization application 113 may then output an indication of the approval to the administrator. Authorization module 114-1 may further update authorization data 106-1 in contactless card 101, for example, when contactless card 101 is subsequently tapped to device 110.

[0022] However, if authentication application 123 and / or authorization module 114-2 determines that authorization data 106 reflects that the administrator does not have permission to grant access to the new employee, authentication application 123 and / or authorization module 114-2 may deny the requested operation. In such an embodiment, authentication application 123 and / or authorization module 114-2 may send an indication of denial to authorization module 114-1, which may then output the indication of denial to the administrator.

[0023] In some embodiments, authorization module 114-1 executing on computing device 110 may determine whether authorization data 106-2 (and / or authorization data 106-1 of contactless card 101) reflects whether the administrator has permission to grant access to a new employee. Thus, in such embodiments, authorization module 114-1, in response to receiving an indication that authentication application 123 has verified encrypted data 105, determines whether authorization data 106-2 (and / or authorization data 106-1 of contactless card 101) reflects whether the administrator has permission to grant access to a new employee. Similarly, if the request is to access a resource of host system 150, authorization module 114-3, in response to receiving an indication that authentication application 123 has verified encrypted data 105, may determine whether authorization data 106-4 (and / or authorization data 106-1, 106-2 received from requesting computing device 110) reflects whether the administrator has permission to grant access to a new employee.

[0024] The above techniques may be used for any type of attempted operation in system 100. For example, if a new employee subsequently attempts to open accounting application 113 using computing device 110, authorization module 114-1 may request that the new employee tap contactless card 101 against computing device 110. In response, applet 103 generates encrypted data 105 using private key 104 and the new employee's account identifier. Authorization module 114-1 may then receive encrypted data 105 and transmit the encrypted data 105 as part of a request to access accounting application 113. Authentication application 123 may then attempt to verify encrypted data 105 as described above. If verification of encrypted data 105 is successful, authentication application 123 and / or authorization module 114-2 may grant and / or deny the requested access to accounting application 113 based on authorization data 106 in account data 124 for the new employee.

[0025] 1A-1B are described with reference to an exemplary business organization, the present disclosure is equally applicable to other groups, such as families, educational institutions, and the like. For example, a parent may provide a child with limited access to a checking account. In such an example, the parent may use the account management application 113 to delegate access to the checking account according to one or more rules. The rules may include spending limits, merchant restrictions, time restrictions, and / or geographic restrictions. The authorization module 114-1 may then instruct the parent to tap the contactless card 101 against the computing device 110 to generate encrypted data 105, which may be verified by the authentication application 123. Once verified, the authorization data 106 of the parent's account (and / or any subaccounts created for the child) may be updated to reflect that the child can use funds in the checking account according to the rules specified by the parent. In one embodiment, a virtual account number may be generated for the child's account. The virtual account number may be associated with the parent's checking account and restricted based on the rules specified by the parent.

[0026] FIG. 2A is a schematic diagram 200 illustrating an example embodiment of tapping contactless card 101 for delegated management of permissions. As shown, authorization module 114-1 executing on computing device 110-1 displays a graphical user interface (GUI) for delegating permissions. While shown as part of authorization module 114-1, the GUI may be part of a different application 113. As shown, the GUI includes form fields 201-203. More specifically, user field 201 corresponds to the user for whom the permissions are being delegated, resource field 202 corresponds to the resource for which the permissions are being delegated, and duration field 203 corresponds to the amount of time for which the permissions are being delegated. Thus, as shown, the user has entered an exemplary user "User ABC" in field 201, an exemplary resource "Database 1" (e.g., corresponding to data 151) in field 202, and an unlimited duration in field 203. The user may then select submit button 204.

[0027] FIG. 2B is a schematic diagram 210 illustrating an embodiment in which a user selects the send button 204 of FIG. 2A. As shown, the authorization module 114-1 prompts the user to tap the contactless card 101 to the computing device 110-1 to complete the delegation of authorization to user ABC. As described above, when the user taps the contactless card 101 to the computing device 110-1, the contactless card 101 generates encrypted data 105 and transmits the encrypted data 105 to the authorization module 114-1. In some embodiments, the contactless card 101 transmits the authorization data 106-1 to the authorization module 114-1. The authorization module 114-1 may generate a request package specifying the requested authorization (e.g., unlimited access to database 1 for user ABC). The authorization module 114-1 then transmits the request and the encrypted data 105 to the authentication server 120. In some embodiments, the authorization module 114-1 may transmit the authorization data 106-1 and / or 106-2 to the authentication application 123.

[0028] Next, authentication application 123 may verify encrypted data 105 by decrypting it with server 120's private key 104. Once verified, authentication application 123 and / or authorization module 114-2 may determine whether the requesting user has permission to grant user ABC access to database 1. As described above, authentication application 123 and / or authorization module 114-2 may determine whether the requesting user has permission based on authorization data 106, which may include authorization data 106-1, 106-2, 106-3, and / or 106-4. If the requesting user has permission, authentication application 123 and / or authorization module 114-2 may update authorization data 106 of the target user (in this example, user ABC) to reflect unlimited access to database 1. Authorization data 106-1, 106-2, 106-3, and / or 106-4 may each be updated to reflect that user ABC has unlimited access to database 1.

[0029] FIG. 3A is a schematic diagram 300 illustrating an embodiment in which a user may request the granting of permissions from another user. As shown, an example application 113 executing on computing device 110-1 may include a GUI having form fields 301-303. While depicted as being output by application 113, form fields 301-303 may be output by permission module 114-1 of computing device 110-1. More specifically, user field 301 corresponds to the user requesting permission, resource field 302 corresponds to the resource for which permission is being requested, and duration field 303 corresponds to the amount of time for which permission is being requested. Thus, as shown, the user has entered an example user "User ABC" in field 301, an example resource "Spending Limit $20,000" in field 302, and a one-month duration in field 303. In some embodiments, the spending limit may be associated with the application 113, an account, or the like. The user may then select submit button 304.

[0030] FIG. 3B is a schematic diagram 310 illustrating an embodiment in which a user selects the send button 304 of FIG. 3A. As shown, authorization module 114-1 on computing device 110-1 prompts the user to tap contactless card 101 against computing device 110-1 to process the request for authorization for user ABC to have a $20,000 spending limit. As described above, when the user taps contactless card 101 against computing device 110-1, contactless card 101 generates encrypted data 105 and transmits encrypted data 105 to authorization module 114-1. In some embodiments, contactless card 101 transmits authorization data 106-1 to authorization module 114-1. In at least one embodiment, applet 103 on contactless card 101 generates a digital signature using private key 104. The digital signature may sign encrypted data 105 and / or authorization data 106-1. Contactless card 101 may then transmit a digital signature using encrypted data 105 and / or authorization data 106-1.

[0031] The authorization module 114-1 may then generate a request package specifying the requested authorization (e.g., user ABC has a monthly spending limit of $20,000). The request may further specify the account associated with the requested spending limit, the requesting user's account (e.g., the account number of user ABC's contactless card 101), the application 113 associated with the requested spending limit, etc. The authorization module 114-1 then transmits the request, the digital signature, and the encrypted data 105 to the authentication server 120. In some embodiments, the authorization module 114-1 may transmit the authorization data 106-1 and / or 106-2 to the authentication application 123.

[0032] Authentication application 123 may then verify encrypted data 105 by decrypting it with server 120's private key 104. Authentication application 123 may also verify the digital signature by decrypting it using a public key associated with contactless card 101 and stored by server 120. Once authentication application 123 verifies encrypted data 105 and the digital signature, authentication application 123 and / or authorization module 114-2 may send a notification (or other instruction) to an administrator (or other user) with sufficient authorization to approve the request.

[0033] 3C is a schematic diagram 320 illustrating an embodiment in which authorization module 114-1 executing on administrator's computing device 110-2 receives notification from authentication application 123 and / or authorization module 114-2 as described above with reference to FIG. 3B. As shown, authorization module 114-1 outputs a GUI having fields 305-307 reflecting the requested user, the requested authorization, and the time period, respectively. The administrator may select approve button 308 to initiate approval of the requested spending limit.

[0034] FIG. 3D is a schematic diagram 330 illustrating an embodiment in which the administrator selects the approve button 308 of FIG. 3C. As shown, the authorization module 114-1 prompts the user to tap the contactless card 101 to the computing device 110-2 to complete the delegation of authorization to user ABC. As described above, when the user taps the contactless card 101 to the computing device 110-2, the contactless card 101 generates encrypted data 105 and transmits the encrypted data 105 to the authorization module 114-1. In some embodiments, the contactless card 101 transmits the administrator's authorization data 106-1 to the authorization module 114-1. The authorization module 114-1 may generate a request package specifying the requested authorization (e.g., a $20,000 spending limit for user ABC for one month). The request may further specify an account associated with the requested spending limit (e.g., the account number of user ABC's contactless card 101), the requesting user's account, the application 113 associated with the requested spending limit, etc. Authorization module 114-1 then sends the request and encrypted data 105 to authentication server 120. In some embodiments, authorization module 114-1 may send authorization data 106-1 and / or 106-2 for the administrator to authentication application 123.

[0035] The authentication application 123 may then verify the encrypted data 105 by decrypting it with the private key 104 of the server 120. Once verified, the authentication application 123 and / or the authorization module 114-2 may determine whether the requesting user has permission to grant user ABC access to the requested spending limit. As mentioned above, the authentication application 123 and / or the authorization module 114-2 may determine whether the administrator has permission based on the authorization data 106, which may include authorization data 106-1, 106-2, 106-3, and / or 106-4. If the administrator has permission, the authentication application 123 and / or the authorization module 114-2 may update the authorization data 106 of the target user (in this example, user ABC) to reflect a monthly spending limit of $20,000. The authorization data 106-1, 106-2, 106-3, and / or 106-4 may each be updated to reflect that user ABC has a monthly spending limit of $20,000. As described in some embodiments, a virtual account number may be generated for user ABC for the described spending limit and time period. The virtual account number may be further restricted based on merchant, geographic location, and / or other parameters. In some embodiments, the account number for the user's (in this example, user ABC's) contactless card 101 may be given a monthly spending limit of $20,000.

[0036] FIG. 3E is a schematic diagram 340 illustrating one embodiment in which user ABC attempts a purchase using application 113. Application 113 may be a merchant application, a web browser, or any other application configured to process payments and / or transfer funds. As shown, application 113 includes form payment fields 311-313 corresponding to an account number field, an expiration date field, and a card verification value (CVV) field, respectively. As shown, the user entered an example account number, expiration date, and CVV into fields 311-313, respectively. The account number may be a time-limited virtual account number and / or the account number of the user's (in this example, user ABC's) contactless card 101.

[0037] FIG. 3F is a schematic diagram 350 illustrating an embodiment in which a user has selected the submit button 314 of FIG. 3E. As shown, authorization module 114-1 prompts the user to tap contactless card 101 to computing device 110-1 to complete the requested purchase. As described above, when the user taps contactless card 101 to computing device 110-1, contactless card 101 generates encrypted data 105 and transmits encrypted data 105 to authorization module 114-1. In some embodiments, contactless card 101 transmits authorization data 106-1 to authorization module 114-1. Authorization module 114-1 may generate a request package specifying the requested authorization (e.g., a purchase totaling $19,999). Authorization module 114-1 then transmits the request and encrypted data 105 to authentication server 120. In some embodiments, the authorization module 114-1 may transmit the authorization data 106-1 and / or 106-2 to the authentication application 123.

[0038] Next, authentication application 123 may verify encrypted data 105 by decrypting it with server 120's private key 104. Once verified, authentication application 123 and / or authorization module 114-2 may determine whether the requesting user has authorization to spend $19,999. As previously described, authentication application 123 and / or authorization module 114-2 may determine whether the requesting user has authorization based on authorization data 106, which may include authorization data 106-1, 106-2, 106-3, and / or 106-4. Authorization data 106 may reflect the requesting user's available spending limit and the one-month duration of the spending limit. If the requesting user has a sufficient spending limit and is within the one-month duration of the spending limit, as reflected in authorization data 106, authentication application 123 and / or authorization module 114-2 may approve the requested purchase. Otherwise, the requested purchase is denied.

[0039] If approved, authentication application 123 and / or authorization module 114-2 may update authorization data 106 of the target user (in this example, user ABC) to reflect that $19,999 has been spent by user ABC. Generally, authorization data 106-1, 106-2, 106-3, and / or 106-4 may each be updated to reflect that $19,999 has been spent by user ABC. Authentication application 123 and / or authorization module 114-2 may then send an indication of approval to authorization module 114-1 on computing device 110-1. Authorization module 114-1 may then send the indication of approval to application 113 processing the purchase.

[0040] 4 is a schematic diagram 400 illustrating an embodiment using a contactless card for authorization of a first computing device 110-1 and a second computing device 110-2. As shown, computing devices 110-1, 110-2 each execute an exemplary application 113-1. However, the functionality provided by application 113-1 on devices 110-1, 110-2 differs. As noted, authorization data 106-1 on contactless card 101 may be used to control the functionality, appearance, and / or other attributes of the application.

[0041] For example, when executing application 113-1 on device 110-1, authorization module 114-1 may output instructions specifying tapping contactless card 101-1 to device 110-1. In doing so, contactless card 101-1 may generate and transmit encrypted data 105 for verification by authentication application 123, as described above. Further, as noted, contactless card 101-1 may transmit authorization data 106-1 to authorization module 114-1 of device 110-1. Authorization module 114-1 may then transmit authorization data 106-1 and / or instructions to application 113-1 regarding which features of application 113-1 to expose. In response, application 113-1 exposes three features associated with links 401-403 of device 110-1. For example, as shown, link 401 is associated with an interface for displaying account balances that a user associated with contactless card 101-1 may access, link 402 is associated with a payment interface that a user associated with contactless card 101-1 may access, and link 403 is associated with an interface that a user associated with contactless card 101-1 may access to request credit.

[0042] However, as shown, when a user associated with contactless card 101-2 taps contactless card 101-2 to computing device 110-2, authorization data 106-1 permits the exposure of more limited functionality of application 113-1. For example, as shown, application 113-1 on computing device 110-2 exposes an interface associated with link 404, i.e., an interface for displaying account balances, based on authorization data 106-2 received from contactless card 101-2. However, application 113-1 on computing device 110-2 does not expose other interfaces (e.g., a payment interface, a credit request interface, etc.).

[0043] Thus, as noted, the authorization module 114-1 restricts and / or authorizes user access to different features, pages, and / or other attributes of the application 113-1 based on the authorization data 106 associated with the user associated with a given contactless card 101-1. In some embodiments, the authorization data 106-1 stored on the contactless card is in clear text that may be read directly by the computing device 110. In such embodiments, the generation of encrypted data 105 may not be generated and / or verified by the authentication server 120. Such embodiments may be useful, for example, when a given device 110 does not have access to the Internet. However, in some such embodiments, the user may be required to provide local login credentials on the computing device 110 to improve security.

[0044] 5 illustrates an example portion of permission data 106, according to one embodiment. As shown, permission data 106 is a vector of binary values. Each element of permission data 106 may specify whether an associated user is authorized to access the associated resource and / or perform an operation. For example, as shown, a value of "1" for element 501 of permission data 106 may indicate that the user is authorized to access the resource and / or perform the operation. Similarly, a value of "0" for element 502 of permission data 106 may indicate that the user is not authorized to access the resource and / or perform the operation. As noted, the elements of permission data 106 (including elements 501, 502) may be associated with granting, modifying, and / or revoking permissions to other users, running applications (e.g., application 113 of computing device 110, application 152 of host system 150, etc.), accessing particular functions and / or interfaces of applications, accessing data (e.g., data 115 of computing device 110, data 151 of host system 150, etc.), and performing operations using applications and / or data.

[0045] 6 illustrates an embodiment of a logic flow 600. The logic flow 600 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 600 may include some or all of the operations performed for delegated management of permissions using the contactless card 101. In this context, the embodiments are not limited.

[0046] As shown, logic flow 600 begins at block 605, where one or more contactless cards 101 are programmed with a unique private key 104 and authorization data 106-1 at the time of manufacture. For example, authorization data 106-3 within an associated user's account data 124 may be programmed into the memory 102 of the contactless card 101 for the user at the time of manufacture. At block 610, authorization module 114-1 executing on computing device 110 may receive a request from a first account to grant authorization to computing resources and / or perform an operation to a second account. For example, a user of the first account may grant a user of the second account access to data 151 and / or applications 152 on host system 150. At block 615, a user associated with the first account taps contactless card 101 to computing device 110, causing contactless card 101 to generate and transmit encrypted data 105. Next, in block 620, applet 103 of contactless card 101 may use private key 104, input data (e.g., a user identifier), and an encryption algorithm to generate encrypted data 105. In block 625, applet 103 may send encrypted data 105 and authorization data 106-1 to authorization module 114-1 of computing device 110.

[0047] At block 630, authorization module 114-1 of computing device 110 sends encrypted data 105 and a request to authentication server 120 to grant specified permissions to a second account. For example, the request may specify that a first account grants permission to the second account to access specified data 151 and / or application 152 of host system 150. In some embodiments, authorization module 114-1 may send authorization data 106-1 and / or authorization data 106-2 to authentication server 120. In other embodiments, authorization module 114 may refrain from sending the authorization data to server 120. At block 635, authentication application 123 decrypts encrypted data 105 using private key 104 of authentication server 120 to verify encrypted data 105.

[0048] At block 640, the authentication application 123 determines that the first account has permission to grant the requested access to the second account. For example, the authentication application 123 may reference the first account's permission data 106-3 stored in the account data 124 to determine whether the first account has the necessary permission. As another example, the authentication application 123 may use the received permission data 106-1 and / or permission data 106-2. At block 645, the authentication application 123 updates the second account's permission data 106 to reflect the granting of access to the specified resource. For example, the authentication application 123 may update the second account's permission data 106-3 stored in the account data 124 to reflect that the second account is authorized to access the specified data 151 and / or application 152 of the host system 150. Similarly, updates may be pushed to other instances of the second account's authorization data 106 (e.g., authorization data 106-1 on the second account's user's contactless card 101, authorization data 106-2 on the second account's user's computing device, authorization data 106-4 on the host system 150, etc.).

[0049] At block 650, the authentication application 123 may send to the authorization module 114-1 instructions to verify the encrypted data 105 and grant permission to the second account. In some embodiments, the authentication application 123 may send the authorization data 106-3 of the second account to the authorization module 114-1. At block 655, the user of the second account may tap their contactless card 101 to the computing device 110 to update the authorization data 106-1 stored on the contactless card 101 to reflect the granting of permission.

[0050] 7 illustrates an embodiment of a logic flow 700. The logic flow 700 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 700 may include some or all of the operations for modifying application functionality based on permission data. In this context, the embodiments are not limited.

[0051] As shown, logic flow 700 begins at block 705, where authorization module 114-1 executing on computing device 110 receives a request to perform an operation, for example, from application 113 and / or OS 112. The operation may include, but is not limited to, accessing a computing resource, granting permission, changing permission, revoking permission, and / or performing an operation using a computing resource. At block 710, a user associated with the request taps contactless card 101 against computing device 110, causing contactless card 101 to generate and transmit encrypted data 105. Applet 103 on contactless card 101 may then generate encrypted data 105 using private key 104, input data (e.g., a user identifier), and an encryption algorithm. Applet 103 may transmit encrypted data 105 and authorization data 106-1 to authorization module 114-1 on computing device 110.

[0052] At block 715, authorization module 114-1 of computing device 110 sends encrypted data 105 and an indication of the requested operation to authentication server 120. In some embodiments, authorization module 114-1 may send authorization data 106-1 and / or authorization data 106-2 to authentication server 120. Authentication application 123 may then decrypt encrypted data 105 using private key 104 of authentication server 120 to verify encrypted data 105. At block 720, authorization module 114-1 receives an indication of verification of encrypted data 105 from authentication server 120. Authorization module 114-1 may further receive authorization data 106-3 for the requesting account from authentication server 120.

[0053] At block 725, the authorization module 114-1 determines whether the requested operation is permitted based on the permission data 106-1, 106-2, 106-3, and / or 106-4 of the requesting account. If the authorization module 114-1 determines that the permission data 106 specifies that the operation is permitted, at block 730, the authorization module 114-1 permits the requested operation (e.g., based on a lookup of an entry in the permission data 106 associated with the requested operation). However, if the permission data 106 does not permit the requested operation, at block 735, the authorization module 114-1 restricts execution of the requested operation. For example, if the requested operation is to open an application, the authorization module 114-1 would restrict the application from being opened. Furthermore, if the requested operation is to open an application and / or a specific portion of an application, at block 740, the authorization module 114-1 and / or the application may modify the application's GUI to expose functionality permitted by the permission data 106 and disable functionality not permitted by the permission data 106.

[0054] 8 illustrates an embodiment of a logic flow 800. The logic flow 800 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 800 may include some or all of the operations performed by the applet 103 of the contactless card 101. In this context, the embodiments are not limited.

[0055] As shown, logic flow 800 begins at block 805, where applet 103 of contactless card 101 receives an identifier of requesting device 110. The identifier may be a Media Access Control (MAC) address, a software fingerprint, a device identifier, etc. The requesting device 110 may be any device that includes an instance of authorization module 114-1 brought within communication range of contactless card 101. At block 810, applet 103 determines that the received identifier is designated as an approved identifier in contactless card memory 102. At block 815, applet 103 generates encrypted data 105 based on the secret key, input data, and encryption function. At block 820, contactless card 101 transmits encrypted data 105 and authorization data 106-1 of contactless card 101 to the requesting device 110.

[0056] 9 illustrates an embodiment of an exemplary computing architecture 900 comprising a computing system 902 suitable for implementing the various embodiments described above. In various embodiments, the computing architecture 900 may be configured or implemented as part of an electronic device. In some embodiments, the computing architecture 900 may represent, for example, a system implementing one or more components of the system 100. In some embodiments, the computing system 902 may represent, for example, the contactless card 101, the computing device 110, the authentication server 120, and / or the host system 150 of the system 100. The embodiments are not limited in this context. More generally, the computing architecture 900 is configured to implement all logic, applications, systems, methods, apparatus, and functions described herein with reference to FIGS. 1-8.

[0057] As used in this application, the terms “system,” “component,” and “module” are intended to refer to any computer-related entity: hardware, a combination of hardware and software, software, or software in execution, an example of which is provided by exemplary computing architecture 900. For example, a component may be, but is not limited to, a process running on a computer processor, a computer processor, a hard disk drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable, a thread of execution, a program, and / or a computer. By way of example, both an application running on a server and the server may be a component. One or more components may reside within a process and / or thread of execution, and components may be localized on one computer and / or distributed among two or more computers. Furthermore, components may be communicatively coupled to each other and coordinate operations by various types of communication media. Coordination may include unidirectional or bidirectional exchange of information. For example, components may communicate information in the form of signals communicated over the communication media. Information may be embodied as signals assigned to various signal lines. In such assignments, each message is a signal. However, further embodiments may alternatively use data messages. Such data messages may be transmitted over a variety of connections, examples of which include parallel interfaces, serial interfaces, and bus interfaces.

[0058] Computing system 902 includes various typical computing elements, such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, 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 computing system 902.

[0059] 9, computing system 902 includes a processor 904, a system memory 906, and a system bus 908. Processor 904 may be any of a variety of commercially available computer processors, including, but not limited to, AMD® Athlon®, Duron®, and Opteron® processors, ARM® application, embedded, and secure processors, IBM® and Motorola® DragonBall® and PowerPC® processors, IBM and Sony® Cell processors, Intel® Celeron®, Core®, Core(2) Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors and similar processors. Dual microprocessors, multi-core processors, and other multi-processor architectures may also be used as processor 904.

[0060] The system bus 908 provides an interface from the system memory 906 to system components including, but not limited to, the processor 904. The system bus 908 may be any of several types of bus structures that may 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. Interface adapters may connect to the system bus 908 through a slot architecture. Examples of slot architectures include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, (Extended) Industry Standard Architecture ((E)ISA), MicroChannel Architecture (MCA), NuBus, Peripheral Component Interconnect (Expansion) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), etc.

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

[0062] Computing system 902 may include various types of computer-readable storage media in the form of one or more low-speed memory units, including an internal (or external) hard disk drive (HDD) 914, a magnetic floppy disk drive (FDD) 916 that reads from or writes to a removable magnetic disk 918, and an optical disk drive 920 that reads from or writes to a removable optical disk 922 (e.g., a CD-ROM or DVD). HDD 914, FDD 916, and optical disk drive 920 may be connected to system bus 908 by an HDD interface 924, an FDD interface 926, and an optical drive interface 928, respectively. HDD interface 924 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies. Computing system 902 is generally configured to implement all of the logic, systems, methods, devices, and functions described herein with reference to FIGS. 1-8.

[0063] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-executable instructions, etc. For example, a number of program modules may be stored on the drives and memory units 910, 912, including an operating system 930, one or more application programs 932, other program modules 934, and program data 936. In one embodiment, the one or more application programs 932, other program modules 934, and program data 936 may include, for example, various applications and / or components of system 100, such as applets 103, private keys 104, encrypted data 105, authorization data 106, operating system 112, applications 113, authorization module 114, authentication application 123, host system 150, data 151, and / or applications 152.

[0064] A user may enter commands and information into the computing system 902 through one or more wired / wireless input devices, for example, a keyboard 938 and a pointing device such as a mouse 940. Other input devices may include a microphone, infrared (IR) remote control, radio frequency (RF) remote control, game pad, stylus pen, card reader, dongle, fingerprint reader, grab, graphics tablet, joystick, keyboard, retina reader, touch screen (e.g., capacitive, resistive, etc.), trackball, track pad, sensor, stylus, etc. These and other input devices are often connected to the processor 904 through an input device interface 942 coupled to the system bus 908, but may be connected by other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.

[0065] A monitor 944 or other type of display device is also connected to the system bus 908 via an interface, such as a video adapter 946. The monitor 944 may be internal or external to the computing system 902. In addition to the monitor 944, computers typically include other peripheral output devices, such as speakers, printers, etc.

[0066] The computing system 902 may operate in a networked environment using logical connections via wired and / or wireless communications to one or more remote computers, such as a remote computer 948. The remote computer 948 may be a workstation, a server computer, a router, a personal computer, a portable computer, a microprocessor-based entertainment device, a peer device, or other common network node and typically includes many or all of the elements described relative to the computing system 902, although for simplicity, only a memory / storage device 950 is shown. The logical connections shown include wired / wireless connections to a local area network (LAN) 952 and / or larger networks, e.g., a wide area network (WAN) 954. Such LAN and WAN networking environments are commonplace in offices and businesses, facilitating enterprise-wide computer networks such as intranets. All of these may connect to a global communications network, e.g., the Internet. In an embodiment, the network 130 of FIG. 1 is one or more of the LAN 952 and the WAN 954.

[0067] When used in a LAN networking environment, the computing system 902 is connected to the LAN 952 through a wired and / or wireless communication network interface or adapter 956. The adapter 956 may facilitate wired and / or wireless communication to the LAN 952, which may include a wireless access point disposed thereon for communicating with the wireless functionality of the adapter 956.

[0068] When used in a WAN networking environment, the computing system 902 may include a modem 958 or have other means for establishing communications over the WAN 954, such as connected to a communications server on the WAN 954 or via the Internet. The modem 958 may be internal or external, a wired and / or wireless device, and connects to the system bus 908 via the input device interface 942. In a networked environment, program modules depicted relative to the computing system 902, or portions thereof, may be stored in the remote memory / storage device 950. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between computers may be used.

[0069] The computing system 902 is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively arranged for wireless communication (e.g., IEEE 802.16 wireless modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, Bluetooth® wireless technologies, and the like. Thus, communication can be in a predefined structure, similar to a traditional network, or simply ad hoc communication between at least two devices. Wi-Fi networks use radio technologies called IEEE 802.11x (a, b, g, n, etc.) to provide secure, reliable, and high-speed wireless connectivity. Wi-Fi networks can be used to connect computers to each other, to the Internet, or to wired networks (using IEEE 802.3-related media and functions).

[0070] FIG. 10A illustrates a contactless card 101, which may comprise a payment card such as a credit card, debit card, and / or gift card. As shown, the contactless card 101 may be issued by a service provider 1002, which may display the contactless card 101 on the front or back of the card 101. In some examples, the contactless card 500 may comprise, but is not limited to, an identification card, unrelated to a payment card. In some examples, the payment card may comprise a dual-interface contactless payment card. The contactless card 101 may comprise a substrate 1010, which may include a single layer or one or more laminate layers composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, contactless card 101 may have physical characteristics that conform to the ID-1 format of the ISO / IEC 7810 standard, or contactless card may conform to the ISO / IEC 14443 standard. However, it is understood that contactless card 101 according to the present disclosure may have different characteristics, and the present disclosure does not require that the contactless card be embodied in a payment card.

[0071] The contactless card 101 may also include identification information 1015 displayed on the front and / or back of the card, and a contact pad 1020. The contact pad 1020 may be configured to establish contact with other communication devices, such as the mobile device 110, a user device, a smartphone, a laptop, a desktop, or a tablet computer. The contactless card 101 may also include processing circuitry, an antenna, and other components not shown in FIG. 10A . These components may be located behind the contact pad 1020 or elsewhere on the substrate 1010. The contactless card 101 may also include a magnetic strip or tape (not shown in FIG. 10A ) that may be located on the back of the card.

[0072] 10B, the contact pad 1020 of the contactless card 101 may include processing circuitry 1025 for storing and processing information, including a microprocessor 1030 and memory 102. It will be understood that the processing circuitry 1025 may include additional components, including processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware, as needed to perform the functions described herein.

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

[0074] Memory 102 may be configured with one or more applets 103, private keys 104, encrypted data 105, authorization data 106-1, and one or more user identifiers (IDs) 1007. One or more applets 103 may include one or more software applications configured to run on one or more contactless cards, such as a Java Card applet. However, it is understood that applet 103 is not limited to a Java Card applet and may instead be any software application capable of operating on a contactless card or other device with limited memory. User ID 1007 may comprise a unique alphanumeric identifier assigned to a user of contactless card 101, which may distinguish a contactless card user from other contactless card users. In some examples, user ID 1007 may identify both a customer and an account assigned to the customer, and may further identify the contactless card associated with the customer's account. In some embodiments, applet 103 may use customer ID 1007 as input to an encryption algorithm using private key 104 to generate encrypted data 105 .

[0075] Although the processor and memory elements of the foregoing exemplary embodiments are described with reference to contact pads, the present disclosure is not limited thereto, and it will be understood that these elements may be implemented outside of the pads 1020, completely separate from the pads 1020, or as additional elements in addition to the processor 1030 and memory 102 elements disposed within the contact pads 1020.

[0076] In some examples, the contactless card 101 may include one or more antennas 1055. The one or more antennas 1055 may be disposed within the contactless card 101 around the contact pads 1020 and the processing circuit 1025. For example, the one or more antennas 1055 may be integral with the processing circuit 1025, or the one or more antennas 1055 may be used in conjunction with an external booster coil. As another example, the one or more antennas 1055 may be external to the contact pads 1020 and the processing circuit 1025.

[0077] In one embodiment, the coil of the contactless card 101 may function as the secondary of an air-core transformer. The terminal may communicate with the contactless card 101 by interrupting power or amplitude modulation. The contactless card 101 may infer data transmitted from the terminal using a gap in the contactless card's power connection, which may be functionally maintained via one or more capacitors. The contactless card 101 may communicate back by switching or load modulating the load on the contactless card's coil. Load modulation may be detected in the terminal's coil through interference. More generally, using the antenna 1055, processing circuitry 1025, and / or memory 102, the contactless card 101 provides a communication interface for communicating via NFC, Bluetooth, and / or Wi-Fi communications.

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

[0079] Various embodiments may be implemented using hardware elements, software elements, or a combination of both. Examples of hardware elements may include a processor, a microprocessor, a circuit, a circuit element (e.g., a transistor, a resistor, a capacitor, an inductor, etc.), an integrated circuit, an application specific integrated circuit (ASIC), a programmable logic device (PLD), a digital signal processor (DSP), a field programmable gate array (FPGA), a logic gate, a register, a semiconductor device, a chip, a microchip, a chipset, etc. Examples of software may include a software component, a program, an application, a computer program, an application program, a system program, a machine program, an operating system software, a middleware, a firmware, a software module, a routine, a subroutine, a function, a method, a procedure, a software interface, an application program interface (API), an instruction set, a computational code, a computer code, a code segment, a computer code segment, a word, a value, a symbol, or any combination thereof. The decision whether an embodiment is implemented using hardware and / or software elements may vary according to any number of factors, such as required computational speed, power level, thermal tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints.

[0080] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium that represent various logic within a processor, which, when read by a machine, causes the machine to manufacture logic that performs the techniques described herein. Such representations, known as “IP cores,” are stored on tangible machine-readable media and provided to various customers or manufacturing facilities for loading into manufacturing machines that create the logic or processors. Some embodiments may be implemented using, for example, a machine-readable medium or article that may store instructions or sets of instructions that, when executed by the machine, cause the machine to perform methods and / or operations in accordance with the embodiments. Such a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and may be implemented using any suitable combination of hardware and / or software. A machine-readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium and / or storage unit, such as memory, removable or non-removable media, erasable or non-erasable media, writable or rewritable media, digital or analog media, hard disk, floppy disk, compact disk read-only memory (CD-ROM), compact disk recordable (CD-R), compact disk rewriteable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various digital versatile disks (DVDs), tape, cassette, etc. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc., and may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0081] The foregoing description of exemplary embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. Many modifications and variations are possible in light of this disclosure. It is intended that the scope of the disclosure be limited not by this detailed description, but by the appended claims. Future applications claiming priority to this application may claim the disclosed subject matter differently and may generally include any set of one or more limitations as variously disclosed or demonstrated herein.

Claims

1. a processor circuit; a memory for storing instructions, The instructions, when executed by the processor circuit, cause the processor circuit to: Receives a request to access a resource, receiving encrypted data from a contactless card, the contactless card having a unique private key stored in a memory of the contactless card that is used to encrypt the data; transmitting the encrypted data to an authentication server; The authentication server receives a result of decrypting the encrypted data from the authentication server, the result includes authorization data including at least two elements indicating authorization to access the resource; the at least two elements include a first element and a second element; wherein the authentication server stores a corresponding copy of the unique private key, the unique private key being used for encryption and decryption; determining, based on the result, that the contactless card is verified and that the resource is accessed; granting access to the resource based on verification of the contactless card via a first function of the resource based on the first of the at least two factors; Disabling access to the resource via a second function of the resource based on the second of the at least two elements. system.

2. 2. The system of claim 1, wherein the encrypted data includes authorization data encrypted by the contactless card performing a cryptographic operation using the unique private key of the contactless card.

3. The system of claim 2 , wherein the result includes an indication that the authorization data was verified by the authentication server.

4. one of the at least two elements is associated with the contactless card and includes an indication that the contactless card has been verified; The system of claim 1 .

5. The instructions cause the processor circuit to: Initiating data exchange with the contactless card via near field communication (NFC); Receiving the encrypted data through the NFC data exchange The system of claim 1 further configured to:

6. one or more wireless interfaces configured to operate according to an NFC protocol, a Bluetooth protocol, a Wi-Fi protocol, or a combination thereof; the processor circuitry is configured to receive the encrypted data via one or more of the wireless interfaces. The system of claim 1 .

7. The system of claim 1 , wherein the resource is a computing device.

8. The instructions cause the processor circuit to: providing an indication on a graphical user interface (GUI) of a display device of the computing device that the access has been granted. The system of claim 7 further configured to:

9. 1. A computer-implemented method comprising: a processing circuit for receiving a request to access a resource or process a payment; receiving encrypted data from a contactless card via a wireless interface based on the request, wherein the contactless card has a unique private key stored in a memory of the contactless card that is utilized to encrypt the data; sending the encrypted data to an authentication server; receiving a result from the authentication server, wherein the result indicates whether verification was performed based on the encrypted data and the contactless card was verified, and the result includes authorization data including at least two elements indicating authorization to access the resource or process the payment, the at least two elements including a first element and a second element; determining whether to access the resource or process the payment via a first function based on the first factor of the at least two factors, wherein a memory in communication with the processing circuit stores a corresponding copy of the unique private key, the unique private key being used for encryption and decryption; Disabling access to the resource or refusing to process the payment via a second function of the resource based on the second of the at least two factors. A computer-implemented method.

10. 10. The computer-implemented method of claim 9, wherein the encrypted data includes an instance of authorization data encrypted by the contactless card performing a cryptographic operation using the unique private key of the contactless card.

11. if the result indicates that the contactless card is verified, granting the access to the resource; If the result indicates that the contactless card is not verified, restricting the access to the resource.

11. The computer-implemented method of claim 10, comprising:

12. 10. The computer-implemented method of claim 9, wherein the encrypted data comprises payment data encrypted by the contactless card performing a cryptographic operation using the unique private key of the contactless card.

13. enabling the payment if the result indicates that the contactless card is verified; restricting the payment if the result indicates that the contactless card is not verified.

13. The computer-implemented method of claim 12.

14. Initiating data exchange with the contactless card via near field communication (NFC), receiving the encrypted data through the NFC data exchange; 10. The computer-implemented method of claim 9, comprising:

15. 10. The computer-implemented method of claim 9, further comprising presenting an indication of the results on a graphical user interface (GUI) of a display device.

16. 1. A system configured to provide authentication services for contactless cards configured to provide payment and access functionality, comprising: The system comprises one or more servers; The one or more servers: a memory for storing instructions; processing circuitry for executing said instructions; wherein the instructions, when executed, cause the processing circuitry to: receiving encrypted data from a computing device to verify a contactless card for accessing a resource, wherein the encrypted data was generated by the contactless card using a cryptographic algorithm with a unique private key of the contactless card, wherein the contactless card has its unique private key stored in memory; applying a decryption algorithm and a second key to the encrypted data to generate decrypted data; verifying the contactless card based on the decrypted data, wherein the memory within the system stores a corresponding copy of the unique private key, the unique private key being used for encryption and decryption; causing the computing device to transmit a result including an indication that the contactless card has been verified; the result includes authorization data including at least two elements indicating authorization to access the resource; the at least two elements include a first element and a second element; the first element of the at least two elements indicates permission to access the resource via a first function; the second of the at least two elements indicates prohibiting access to the resource via a second function; system.

17. 17. The system of claim 16, wherein the encrypted data includes authorization data encrypted by the contactless card performing a cryptographic operation using the unique private key of the contactless card.

18. 20. The system of claim 17, wherein the result includes an indication that the authorization data was verified by the one or more servers.

19. 17. The system of claim 16, wherein one of the at least two elements is associated with the contactless card and includes an indication that the contactless card has been verified.

20. The system of claim 16 , wherein the resource is a device.

Images