Tapping contactless card to computing device to provision virtual number

Abstract

To provide an apparatus and method for tapping a contactless card to a computing device to provision a virtual number, and a storage medium.SOLUTION: A method includes receiving a parameter for authorizing a virtual account number for a subaccount associated with a primary account. An application executing on a processor circuit may receive authentication credentials for the primary account. A card reader may receive encrypted data from a communications interface of a contactless card. The application may transmit the encrypted data to an authentication server, receive verification of the encrypted data from the authentication server, provide the at least one parameter for authorizing the virtual account number, and receive a virtual account number for the subaccount generated by a virtual card number server. The virtual account number is restricted to a spending limit based on the amount parameter associated with the virtual account number.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] Related Applications This application claims priority to U.S. Patent Application No. 16 / 731,835, entitled "Virtual Number Provisioning by Tapping a Contactless Card to a Computing Device," filed December 31, 2019, the contents of which are incorporated herein by reference in their entirety.

[0002] Technical Field TECHNICAL FIELD Embodiments herein relate generally to computing platforms, and more particularly to tapping a contactless card to a computing device to provision a virtual number. [Background technology]

[0003] Cardholders (e.g., credit card holders, bank card holders, etc.) often obtain additional physical cards for trusted individuals, such as family members or employees. However, obtaining additional physical cards is impractical in many situations. For example, it is impractical to obtain additional physical cards with nominal spending limits. Similarly, it is impractical to obtain additional physical cards for infrequent purchasers or to deactivate and / or reactivate existing physical cards for such users. Summary of the Invention

[0004]

[0006] Embodiments disclosed herein provide systems, methods, articles of manufacture, and computer-readable media for provisioning a virtual number by tapping a contactless card to a computing device. According to one example, at least one parameter for authorizing a virtual account number for a sub-account associated with a primary account may be received, the at least one parameter including an amount parameter associated with the virtual account number. An application running on a processor circuit may receive authentication credentials for the primary account. A card reader may receive encrypted data from a communication interface of a contactless card associated with the primary account. The encrypted data is generated by an applet running in the contactless card's memory using an encryption algorithm and a private key stored in the contactless card's memory. The application may transmit the encrypted data to an authentication server associated with the contactless card's issuer. The application may receive verification of the encrypted data from the authentication server, and the authentication server may verify the encrypted data based on the encryption algorithm and the private key stored in the authentication server's memory. The application may provide at least one parameter for authorizing the virtual account number and receive the virtual account number for the sub-account generated by the virtual card number server. The virtual account number is restricted to a spending limit based on an amount parameter associated with the virtual account number. [Brief explanation of the drawings]

[0005] [Figure 1A] 1 illustrates an embodiment of a system for tapping a contactless card to a computing device to provision a virtual number. [Figure 1B] 1 illustrates an embodiment of a system for tapping a contactless card to a computing device to provision a virtual number. [Figure 1C]1 illustrates an embodiment of a system for tapping a contactless card to a computing device to provision a virtual number. [Figure 2A] 1 illustrates an embodiment in which a contactless card is tapped to a computing device to provision a virtual number. [Figure 2B] 1 illustrates an embodiment in which a contactless card is tapped to a computing device to provision a virtual number. [Figure 3A] 1 illustrates an embodiment in which a contactless card is tapped to a computing device to provision a virtual number. [Figure 3B] 1 illustrates an embodiment in which a contactless card is tapped to a computing device to provision a virtual number. [Figure 3C] 1 illustrates an embodiment in which a contactless card is tapped to a computing device to provision a virtual number. [Figure 3D] 1 illustrates an embodiment in which a contactless card is tapped to a computing device to provision a virtual number. [Figure 4] 1 illustrates an embodiment of an interface for requesting provisioning of a virtual number. [Figure 5] 1 illustrates an embodiment of an interface for managing provisioned virtual numbers. [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] 10 illustrates a fourth logic flow embodiment. [Figure 10] 1 illustrates an embodiment of a computing architecture. [Figure 11A] 1 shows an example of a contactless card. [Figure 11B] 1 shows an example of a contactless card. DETAILED DESCRIPTION OF THE INVENTION

[0006]

[0003] Embodiments disclosed herein provide secure techniques for provisioning virtual account numbers from one account (referred to herein as a "primary account") to one or more other accounts (referred to herein as "sub-accounts") by tapping a contactless card to a computing device. Generally, a user may specify parameters for the virtual account number and provide input to an application running on the computing device. For example, a user may specify to generate a $20 virtual account number for a child to be used within one week at a grocery store. 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, the contactless card generates encrypted data, which is transmitted to the computing device. The application may receive the encrypted data generated by the contactless card and transmit the encrypted data to an authentication server for verification. Once verified, the authentication server may instruct a virtual account number server to generate a virtual account number, an expiration date, and a card verification value (CVV) associated with the contactless card. The generated virtual account number (including the expiration date and / or CVV) may then be transmitted to the device of the user and / or recipient of the virtual account number. A virtual account number may also be added to the recipient's digital wallet. The recipient may use the virtual account number based on input parameters. For example, a child may have one week to spend $20 allocated to a virtual account number at a grocery store.

[0007] Advantageously, the embodiments disclosed herein improve the security of all devices and associated data. For example, by eliminating the need for a physical card, the risks associated with physical cards are avoided. Furthermore, the validation performed by the authentication server provides safeguards to ensure that an authorized user with access to the physical card is requesting the generation of a virtual account number. Furthermore, by enforcing rules associated with the generation of virtual account numbers, the security of the account approving the generation of the virtual account number is maintained.

[0008] 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. A procedure is herein, and generally, conceived to be a self-consistent sequence 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.

[0009] Further, these operations are often referred to in terms, such as adding or comparing, that 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 that form 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 specially constructed apparatus or digital computers for the required purposes. Various embodiments also relate to apparatus or systems for performing these operations. These apparatus may be specially constructed for the required purposes. The required structure for these various machines will be apparent from the description given.

[0010] Reference is now made to the drawings. 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. However, it may be apparent 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 thereof. The intention is to cover all modifications, equivalents, and alternatives within the scope of the claims.

[0011] 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, an authentication server 120, a virtual account number server 140, and one or more wallet services 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 EMV standards, Bluetooth, and / or Wi-Fi. The computing devices 110 represent any type of network-enabled computing device, such as a smartphone, tablet computer, wearable device, laptop, portable gaming device, mobile device, workstation, desktop computer, server, etc. Servers 120, 140 and wallet service 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, or the like.

[0012] 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®, macOS®, Linux®, and Windows® operating systems. As shown, OS 112 includes account application 113. Account application 113 allows a user to perform various account-related operations, such as viewing account balances, purchasing items, processing payments, and generating and managing virtual account numbers. Initially, a user may authenticate using authentication credentials to access certain functionality of account application 113. For example, authentication credentials may include a username and password, biometric credentials (e.g., fingerprint, FaceID, etc.), etc. As shown, account application 113 may receive primary account credentials 114 for a primary account and / or sub-account credentials 115 for a sub-account.

[0013] Generally, a user associated with a primary account may use the account application 113 to generate a virtual account number for a sub-account according to one or more parameters 106-1 specified by the user. Similarly, a user associated with a sub-account may use the account application to request the generation of a virtual account number from the primary account according to one or more parameters 106-1 specified by the user associated with the sub-account (which may be modified and / or accepted by the user of the primary account). However, in some embodiments, the virtual account number may be generated using one or more of the parameters 106-2 stored in the memory 102 of the contactless card 101 (e.g., as default parameters that may be automatically entered in the form of the account application 113). Generally, by provisioning a virtual account number, the user of the primary account allocates funds and / or extends credit to the user of the sub-account. In at least one embodiment, the sub-account is a generated virtual account number.

[0014] For example, an employer (primary account owner) may assign a virtual account number to an employee (sub-account owner) to enable the employee to purchase $2,000 worth of office furniture from one or more vendors that sell office furniture. The employer may provide primary account credentials 115 to authenticate the primary account in the account application 113. The employer may then input parameters 106-1 in the account application 113 form. Parameters 106-1 may include an indication of the sub-account (or recipient of the sub-account if the sub-account does not exist), the amount of the virtual account number, the period for which the virtual account number can be used, and one or more vendors for which the virtual account number can be used. In some embodiments, the employee may provide sub-account credentials 114 to the account application 113 to process the provisioning of the virtual account number.

[0015] In response, account application 113 may output a notification to computing device 110 (which may be the primary account holder and / or a sub-account holder). The notification may instruct the user to tap the primary account holder's contactless card 101 to computing device 110, thereby bringing contactless card 101 close enough to card reader 119 of computing device 110 to enable data transfer (e.g., NFC data transfer, Bluetooth data transfer, etc.) between communication interface 107 of contactless card 101 and card reader 119 of computing device 110. Applet 103 executing on a processor (not shown) of contactless card 101 may then generate and transmit encrypted data 105 to computing device 110 via communication interface 107. For example, applet 103 of contactless card 101 may use an encryption algorithm to generate an encrypted payload of data 105 encrypted based at least in part on private key 104 stored in memory 102 of contactless card 101. In such an embodiment, the private key 104 and some other data (e.g., a customer identifier, an account identifier, etc.) may be provided as input to an encryption algorithm that outputs encrypted data 105. In general, the applet 103 may generate the encrypted data 105 using any type of encryption algorithm and / or system, and the use of a particular encryption algorithm as an example herein should not be considered limiting of the present disclosure.

[0016] In some embodiments, applet 103 may perform encryption using key diversification techniques to generate encrypted data 105. For example, applet 103 may use secret key 105 in combination with a counter value to enhance security using key diversification. The counter may comprise a value that is synchronized between contactless card 101 and server 120. The counter value may comprise a number that changes each time data is exchanged between contactless card 101 and server 120 (and / or contactless card 101 and mobile device 110). When preparing to send data (e.g., to server 120 and / or mobile device 110), contactless card 101 may increment the counter value. Contactless card 101 may then provide master key 105 and the counter value as inputs to an encryption algorithm, which generates a diversified key as an output. The diversified key may then be used to generate encrypted data 105. The server 120 may then encrypt the secret key 104 and the counter value to generate an instance of the diversified key and decrypt the encrypted data 105 using the diversified key. The encryption algorithm may include an encryption algorithm, a hash-based message authentication code (HMAC) algorithm, a cipher-based message authentication code (CMAC) algorithm, etc. Non-limiting examples of encryption algorithms may include a symmetric encryption algorithm such as 3DES or AES128, a symmetric HMAC algorithm such as HMAC-SHA-256, or a symmetric CMAC algorithm such as AES-CMAC. Examples of key diversification techniques are described in detail 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] In some embodiments, the computing device 110 may send a device identifier to the applet 103. The device identifier may be any identifier, such as a media access control (MAC) address, a unique device identifier, a software fingerprint of an application installed on the computing device 110, or the like. In some such embodiments, the applet 103 determines whether the received device identifier matches (or is similar to) one or more authorized device identifiers stored in the parameter 106-2. If the received identifiers match, the applet 103 may generate encrypted data 105. If the received identifiers do not match, the applet 103 may refrain from generating encrypted data 105 to maintain security. Additionally, the applet 103 may apply other rules to the parameter 106-2 when determining whether to generate encrypted data 105. For example, the parameter 106-2 may specify a threshold number of authorized virtual account numbers, and the applet 103 may determine whether the generation of additional virtual account numbers would exceed the threshold. As another example, the computing device 110 may send the parameter 106-1 specified by the user. If a user-specified parameter 106-1 exceeds a corresponding threshold value in parameter 106-2, applet 103 may refrain from generating encrypted data 105. For example, if the dollar amount specified as parameter 106-1 exceeds a maximum dollar amount specified in parameter 106-2, applet 103 may refrain from generating encrypted data 105.

[0018] Once generated, applet 103 may transmit encrypted data 105 to account application 113 of computing device 110, e.g., via NFC. In some embodiments, applet 103 may also transmit one or more parameters from parameter 106-2 to account application 113. Account application 113 may transmit encrypted data 105 and parameters 106 (which may include one or more parameters 106-1 and / or one or more parameters 106-2) to authentication application 123 of authentication server 120. Parameters 106 may include, but are not limited to, a primary account identifier, a sub-account identifier, a virtual account value, any restrictions, etc. In some embodiments, account application 113 may determine (e.g., based on one or more rules described above) whether the specified parameters 106 are allowed for the generation of a virtual account number before transmitting encrypted data 105 and / or parameters 106 to authentication server 120. For example, if the requested dollar amount exceeds a threshold, account application 113 may reject the request to generate a virtual account number. As another example, the account application 113 may reject a request to generate a virtual account number if the requested location is not located within one or more permitted areas specified in parameters 106. In some embodiments, the account application 113 sends additional data to the authentication application 123 (e.g., a device identifier for the computing device 110, etc.).

[0019] FIG. 1B illustrates an embodiment in which account application 113 transmits encrypted data 105 and parameters 106 to authentication server 120. Upon receipt, authentication application 123 may authenticate encrypted data 105. For example, authentication application 123 may attempt to decrypt 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 encrypted data 105, thereby verifying 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 .

[0020] For example, as mentioned, a customer identifier (e.g., of a primary account) may be used to generate encrypted data 105. In such an example, authentication application 123 may decrypt encrypted data 105 using private key 104 of authentication server 120. If the decryption results in a customer identifier associated with the primary account of account data 124, authentication application 123 verifies encrypted data 105 and instructs VAN generator 142 to generate a virtual account number 126 (including an expiration date and CVV) for the account associated with contactless card 101. If authentication application 123 decrypts the encrypted data and does not obtain the expected result (e.g., a customer identifier of the primary account associated with contactless card 101), authentication application 123 does not verify encrypted data 105. Because the verification failed, authentication application 123 does not instruct VAN generator 142 to generate a virtual account number to maintain the security of the primary account.

[0021] In some embodiments, the authentication application 123 processes data received from the computing device 110 as a condition for instructing the VAN generator 142 to generate a virtual account number. For example, similar to the applet 103 and / or the account application 113, the authentication application 123 may verify whether the parameters 106 for generating a virtual account number comply with one or more rules (e.g., parameters 106-1 and / or 106-2 in the account data 124). For example, if the requested dollar amount exceeds a threshold, the authentication application 123 may reject the request to generate a virtual account number. As another example, the authentication application 123 may determine whether the device identifier of the computing device 110 is specified as a known device identifier for the associated account in the account data 124. If the device identifier is not a known identifier, the authentication application 123 may refrain from instructing the VAN generator 142 to generate a virtual account number. Otherwise, the authentication application 123 may instruct the VAN generator 142 to generate a virtual account number. As another example, authentication application 123 may determine whether the software fingerprint matches a known software fingerprint of an associated account in account data 124. If the software fingerprint is not a known software fingerprint, authentication application 123 may refrain from instructing VAN generator 142 to generate a virtual account number. Otherwise, authentication application 123 may instruct VAN generator 142 to generate a virtual account number. As yet another example, authentication application 123 may determine whether the GPS coordinates of device 110 indicate whether the user is at home, at work, or another known address associated with an account in account data 124. If the location of device 110 is not within a threshold distance of a known address, authentication application 123 may refrain from instructing VAN generator 142 to generate a virtual account number.Otherwise, authentication application 123 may instruct VAN generator 142 to generate a virtual account number. As yet another example, authentication application 123 may determine whether the GPS coordinates of the location requested to use the virtual account number are within one or more permitted locations specified in account data 124. For example, if the requested location is within one mile of a home address associated with the account and account data 124 limits the use of the virtual card number to four miles from the home address, authentication application 123 may instruct VAN generator 142 to generate a virtual account number. However, if the requested location is not within one or more permitted locations, authentication application 123 may refrain from instructing VAN generator 142 to generate a virtual account number.

[0022] As shown in FIG. 1B , once authentication application 123 verifies encrypted data 105, authentication application 123 instructs virtual account number (VAN) generator 142 in memory 141 of virtual account number server 140 to generate a virtual account number 126, which may include a virtual account number, an expiration date, and a CVV for the sub-account. In at least one embodiment, the virtual account number generated by VAN generator 142 is restricted to one or more merchants specified in parameters 106. The virtual account number may further include other restrictions specified by parameters 106 (e.g., time restrictions, amount restrictions, location restrictions, etc.). For example, the virtual account number may be restricted by a location restriction that defines one or more locations where the virtual account number may be used. Once generated, VAN generator 142 may send virtual account number 126 (including the expiration date and / or CVV) to account application 113 of computing device 110 (which may be the computing device 110 of the primary account owner and / or the sub-account owner). VAN generator 142 may further transmit virtual account number 126 to authentication server 120. Authentication server 120 may then store virtual account number 126 in the sub-account profile of account data 124. The sub-account user may then remotely access virtual account number 126.

[0023] FIG. 1C illustrates an embodiment in which a virtual account number 126 (including an expiration date and / or CVV) generated by a VAN generator 142 is added to a sub-account owner's digital wallet 151-1. As shown, the virtual account number 126 may be stored in the wallet service 150 and / or the digital wallet 151-1 of the device 110. For example, the VAN generator 142 may provide the virtual account number 126 to an application program interface (API) of the wallet service 150 and / or the digital wallet 151-1. The API of the wallet service 150 and / or the digital wallet 151-1 may then add the virtual account number, CVV, and expiration date to the sub-account user's digital wallet 151-1. The sub-account user may then use the virtual account number 126 in the digital wallet 151-1 as a form of payment. However, as noted, in some embodiments, the virtual account number 126 may be used as a form of payment without adding the virtual account number 126 to a digital wallet.

[0024] In some embodiments, the account number, expiration date, and CVV of contactless card 101 may be added to digital wallet 151-1 in response to tapping contactless card 101 to device 110, subject to verification of encrypted data 105 generated by contactless card 101 by authentication server 120. In such embodiments, authentication server 120 may provide the account number, expiration date, and CVV of contactless card 101 to wallet service 150, along with the account holder's name and address. The name and address may be received from contactless card 101 and / or account data 124. In other embodiments, authentication server 120 notifies device 110 that the encrypted data 105 has been verified. Digital wallet 151-1 of device 110 may then add the account number, expiration date, and CVV of contactless card 101 to the user's digital wallet 151-1 (e.g., by communicating with wallet service 150). The account holder's name and address may be further added to digital wallet 151-1. The name and address may be received from the contactless card 101 and / or from the account data 124 of the authentication server 120 .

[0025] Generally, once generated, virtual account number 126 may be used according to the restrictions specified by parameters 106. For example, if parameters 106 limit virtual account number 126 to a $50 spending limit per year at restaurants within one mile of the corporate office, each attempt to use virtual account number 126 as a form of payment is parsed according to parameters 106. For example, if an employee attempts to spend $75 using virtual account number 126 at a restaurant 10 miles from the corporate office, the payment may be denied due to a violation of the spending and location restrictions. However, if one week after virtual account number 126 is generated, the employee attempts to spend $10 at a restaurant 0.5 mile from the corporate office, the payment may be processed using virtual account number 126.

[0026] Although depicted as being added via wallet service 150 and / or digital wallet 151-1, the virtual account number (including the expiration date, CVV, or other account-related data) may be transmitted and / or added using other techniques. For example, the virtual account number may be transmitted via email, text message, or other technique. Additionally, in one or more embodiments, OS 112 and / or account application 113 may detect receipt of a virtual account number (e.g., virtual account number 126, expiration date, CVV, and / or any other data). For example, OS 112 and / or account application 113 may parse text from an email, text message, push notification, etc. to detect the virtual account number, CVV, expiration date, and / or other account-related data. As another example, account application 113 may receive an indication from contactless card 101 that a data payload being transmitted includes a virtual account number, expiration date, CVV, billing address, etc.

[0027] In response to detecting receipt of a virtual account number (e.g., from VAN generator 142 and / or contactless card 101), OS 112 and / or account application 113 may perform any number of operations. For example, OS 112 and / or account application 113 may output a notification suggesting, for example, that the virtual account number be used to complete a mobile payment. Additionally and / or alternatively, OS 112 and / or account application 113 may provide a selectable option (e.g., a link, a button, etc.) that allows copying the virtual account number, expiration date, and / or CVV to OS 112's clipboard. Additionally and / or alternatively, OS 112 and / or account application 113 may auto-populate the virtual account number, expiration date, and / or CVV into one or more detected form fields of a form (e.g., into one or more payment fields of a form in account application 113, OS 112, wallet service 150, digital wallet 151, web browser 203, etc.). In some embodiments, OS 112 and / or account application 113 may auto-fill data in response to receiving user input specifying auto-fill (e.g., via a link and / or button that may be selected by the user specifying to perform auto-fill). More generally, any type of operation may be performed in response to receiving a virtual account number, CVV, expiration date, and / or other account-related data.

[0028] FIG. 2A is a schematic diagram 200 illustrating an example embodiment of tapping a contactless card 101 to provision a virtual card number without requiring the recipient to authenticate with an account application 113. As shown, the account application 113 may receive primary account credentials 115 from a user associated with a primary account. The user may further specify parameters 106-1 via the account application 113, which may indicate, for example, the recipient of the virtual card number, the associated amount, and / or any restrictions. As noted, in some embodiments, one or more parameters 106-2 may be received from the contactless card 101. Once the parameters 106 are submitted, the account application 113 instructs the user of the primary account to tap their contactless card 101 to the computing device 110 to provision the virtual card number.

[0029] As described above, when a user taps contactless card 101 against computing device 110, contactless card 101 generates encrypted data 105. However, as shown, memory 102 of contactless card 101 includes uniform resource locator (URL) 201. URL 201 may be stored in memory 102 and / or generated by applet 103. URL 201 may be directed to authentication server 120 or some other URL associated with the entity issuing contactless card 101. URL 201 may further include data (e.g., parameters) used by authentication server 120 to verify the data generated by contactless card 101. For example, applet 103 of contactless card 101 may include encrypted data 105 as a parameter of the URL.

[0030] In some embodiments, encrypted data 105 may be a string, such as "ABC123." Applet 103 may include the generated encrypted data 105 as a parameter of URL 201, thereby generating a URL using encrypted data 202. For example, URL 201 to authentication server 120 may be "http: / / www.example.com / ." Thus, the URL including encrypted data 202 may be "http: / / www.example.com / ?ABC123." In some embodiments, applet 103 may encode encrypted data 105 according to a URL-compatible encoding format before including encrypted data 105 as a parameter of URL 201. For example, encrypted data 105 may be a string of binary data (e.g., 0s and 1s), which may not be URL-compatible. Thus, applet 103 may encode encrypted data 105 into the American Standard Code for Information Interchange (ASCII) base64 encoding format. In doing so, the binary encrypted data 105 is represented in ASCII string format by converting it into a base 64 representation (eg, "ABC123" in the previous example).

[0031] Once generated, the applet 103 may transmit the URL containing the encrypted data 202 to the mobile device 110, for example, via NFC. In one embodiment, once received by the OS 112, the OS 112 causes the web browser 203 to access the URL containing the encrypted data 202. Doing so causes information describing the mobile device 110 to be transmitted along with the request to access the URL containing the encrypted data 202. For example, the information may include attributes of the mobile device 110, such as a media access control (MAC) address, a unique device identifier, and / or a software fingerprint of an application installed on the computing device 110. The account application 113 may further include parameters 106, such as a primary account identifier, a subaccount identifier, a monetary value, any restrictions, etc., in the URL containing the encrypted data 202.

[0032] In some embodiments, URL 201 is a universal link that opens one or more pages of account application 113. For example, a page for specifying parameters 106 may be loaded when URL 201 is received. As another example, a login page for receiving primary account credentials 115 may be loaded when URL 201 is received. When web browser 203 accesses the URL containing encrypted data 202, authentication server 120 and / or authentication application 123 may extract encrypted data 105 from the URL containing encrypted data 202.

[0033] The authentication application 123 may then attempt to decrypt the encrypted data 105 using the private key 104 associated with the primary account's contactless card 101. As noted, in some embodiments, the encrypted data 105 is encoded by the applet 103. In such embodiments, the authentication application 123 may decrypt the encrypted data 105 before the decryption is attempted. If the authentication application 123 decrypts the encrypted data and does not obtain the expected result (e.g., a customer identifier for the primary account), the authentication application 123 does not verify the encrypted data 105 and does not instruct the VAN generator 142 to generate a virtual account number. If the authentication application 123 decrypts the encrypted data and obtains the expected result (e.g., a customer identifier for the primary account), the authentication application 123 verifies the encrypted data 105 and instructs the VAN generator 142 to generate a virtual account number, an expiration date, and a CVV value. The authentication application 123 may further include an indication of the parameters 106 received from the account application 113 (e.g., primary account identifier, subaccount identifier, monetary value, any restrictions, etc.).

[0034] 2B illustrates an embodiment in which authentication application 123 verifies encrypted data 105 extracted from a URL containing encrypted data 202. In response, VAN generator 142 generates virtual account number 204, which includes a virtual account number, an expiration date, and a CVV value. As previously described, virtual account number 204 may be generated based on parameters 106. Thus, virtual account number 204 may be associated with the sub-account owner and limited to an amount specified in parameters 106. Virtual account number 204 may be further limited to a time period, a merchant type, one or more specific merchants, one or more geographic locations, etc., based on parameters 106. VAN generator 142 may then transmit virtual account number 204 to an API of wallet service 150, which may add virtual account number 204 to the sub-account owner's digital wallet 151-1. As another example, the VAN generator 142 may send the virtual account number 204 to a computing device, which may add the virtual account number 204 to the sub-account owner's digital wallet 151-1.

[0035] FIG. 3A is a schematic diagram 300 illustrating an example of tapping a contactless card 101 to provision a virtual card number. As shown, account application 113 executing on computing device 110-1 outputs a graphical user interface (GUI) for receiving parameters 106. Illustratively, the GUI includes form fields 310-305, where field 310 corresponds to an amount field, field 302 corresponds to a recipient field (e.g., a subaccount), field 303 corresponds to a period for using the virtual card number, field 304 corresponds to a merchant field, and field 305 corresponds to a location field. The form fields may be filled in by a requesting user as part of a request for a virtual card number and / or by a primary account holder as part of the granting of the virtual card number. The example shown in FIG. 3A corresponds to an embodiment in which the primary account holder fills in form fields 301-304. As shown, the primary account owner user has entered an amount of $30 in field 301, an example recipient "Child 1" in field 302, a one-day period in field 303, an example vendor category of hardware store in field 304, and an example location of two miles from home.

[0036] When a form in account application 113 on device 110-1 is submitted, account application 113 sends a request to sub-account owner's device 110-2. In one embodiment, account application 113 sends the request to authentication server 120, which may then send the request to sub-account owner's device 110-2. Generally, the request includes parameters 106 (e.g., at least an indication of the values ​​entered in form fields 301-305 and / or other parameters resolved based on the values ​​entered in form fields 301-305). As shown, account application 113 on computing device 110-2 has received authentication credentials for the sub-account. Additionally, account application 113 on computing device 110-2 requires credentials for the primary account (a fingerprint, in this example). Next, account application 113 on computing device 110-2 may instruct the primary account holder to tap contactless card 101 to computing device 110-2. Applet 103 on contactless card 101 may then generate and send encrypted data 105 to computing device 110-2. Account application 113 on computing device 110-2 may then send encrypted data 105 along with parameters 106 (e.g., values ​​from form fields 301-304) to authentication server 120. Authentication server 120 may then verify encrypted data 105 and instruct VAN generator 142 to generate a virtual account number, expiration date, and CVV according to the constraints specified by parameters 106. VAN generator 142 may then send the generated virtual account number to the sub-account owner's computing device 110-2. The sub-account owner may display the generated virtual account number and / or use the virtual account number as a form of payment.

[0037] FIG. 3B is a schematic diagram 310 illustrating an example of tapping a contactless card 101 to add an account number to a digital wallet 151. As shown, computing device 110-1 outputs a GUI for specifying tapping a contactless card to add the card to a digital wallet. The GUI may be part of account application 113 and / or a different application (e.g., a GUI provided by one or more wallet services 150). As shown, the GUI provides the user with an option to specify whether to add a virtual account number, for example, by checking checkbox 311. If the user selects checkbox 311, the virtual account number generated by VAN generator 142 may be added to the corresponding wallet 151. If the user does not select checkbox 311, the card number associated with the contactless card may be added to the corresponding wallet 151. Additionally, as shown, the GUI includes checkboxes 312-313 for allowing the user to specify which wallet 151 the account number should be added to. For example, as shown, the user has selected checkbox 312 but not checkbox 313. Thus, an account number may be added to example wallet 151 for "wallet x," but not to "wallet y." Different wallets "wallet x" and "wallet y" may be provided by the same wallet service 150 and / or different wallet services 150.

[0038] When a user taps contactless card 101 to device 110-1, applet 103 on contactless card 101 may generate and transmit encrypted data 105 to computing device 110-1. Computing device 110-1 may then transmit encrypted data 105 to authentication server 120. In some embodiments, applet 103 transmits additional data to computing device 110-1 (e.g., the account number of contactless card 101, the expiration date of contactless card 101, the CVV of contactless card 101, the name of the account holder, and one or more addresses of the account holder). In such embodiments, computing device 110-1 may transmit the additional data to authentication server 120. Computing device 110-1 may further transmit to authentication server 120 whether the user specified to generate a virtual account number and instructions for each selected wallet (e.g., generate a virtual account number for wallet x).

[0039] Authentication application 123 may then verify the encrypted data 105 as described above. In one embodiment, authentication application 123 may send the account number, expiration date, and CVV of contactless card 101 to wallet service 150 for addition to the designated wallet 151. Authentication application 123 may further provide additional information to wallet service 150 to add to wallet 151, for example, a name and / or address to be associated with the virtual account number. The name and / or address may be received from contactless card 101 and / or received by authentication application 123 from account data 124. In other embodiments, authentication application 123 may send instructions to device 110-1 to verify the encrypted data, and the user may add the account number to wallet 151 using a GUI provided by wallet service 150. In such an embodiment, authentication application 123 may optionally send the account number, expiration date, CVV, name, and / or address to device 110-1.

[0040] If the user specifies to generate a virtual account number via the GUI of FIG. 3B , authentication application 123 may verify encrypted data 105 and instruct VAN generator 142 to generate a virtual account number, expiration date, and CVV. VAN generator 142 may then generate the virtual account number, expiration date, and CVV. In one embodiment, VAN generator 142 may send the virtual account number, expiration date, and CVV to wallet service 150. VAN generator 142 may specify an identifier for wallet 151, and the virtual account number, expiration date, and CVV should be added by wallet service 150. VAN generator 142 may further provide wallet service 150 with additional information to add to wallet 151, such as a name and / or address to be associated with the virtual account number. The name and / or address may be received from contactless card 101 and / or from account data 124 (e.g., by VAN generator 142 and / or authentication application 123). In other embodiments, VAN generator 142 may send the generated virtual account number, expiration date, and CVV to device 110-1, and the user may add the virtual account number to wallet 151 using a GUI provided by wallet service 150. In such embodiments, VAN generator 142 may optionally send the account holder name and / or address to device 110-1.

[0041] 3C is a schematic diagram 315 illustrating an embodiment in which VAN generator 142 adds a virtual account number directly to a user's wallet 151 within wallet service 150. However, as noted, if a virtual account number is not generated, authentication server 120 may add the account number, expiration date, and CVV of contactless card 101 directly to the user's wallet 151 within wallet service 150. In such an example, the GUI shown in FIG. 3C may be updated accordingly.

[0042] As noted, the GUI shown in FIG. 3B may be provided by wallet service 150 (and / or an application associated with wallet service 150). FIG. 3D is a schematic diagram 320 reflecting such an example. In FIG. 3D, authentication server 120 verifies encrypted data 105 generated by contactless card 101 in response to tapping contactless card 101 to device 110-1. Upon verification, authentication server 120 may send an instruction to verify encrypted data 105 to the GUI provided by wallet service 150 on device 110-1. As shown, the GUI provided by wallet service 150 on device 110-1 then outputs fields 321-325. Fields 321-325 may be automatically populated with data. The values ​​entered into fields 321-325 are examples and should not be considered limiting of the disclosure.

[0043] For example, field 321 corresponds to an account number and may be populated to include a virtual account number generated by VAN generator 142 and / or the account number of contactless card 101. To protect privacy, the account number may be obfuscated. Similarly, field 322 corresponds to an expiration date and may be populated to include an expiration date generated by VAN generator 142 and / or the expiration date of contactless card 101. Field 323 corresponds to a CVV value and may be populated to include a CVV generated by VAN generator 142 and / or the CVV of contactless card 101. Field 324 corresponds to an account holder name and may be populated to include an account holder name received from authentication server 120, VAN generator 142, and / or contactless card 101. Field 325 corresponds to an account holder address and may be populated to include an account holder address received from authentication server 120, VAN generator 142, and / or contactless card 101. The user may then submit the information entered in fields 321-325 to wallet service 150 for addition to the user's wallet 151 via submit button 326.

[0044] As noted, the data entered in fields 321-325 may be received from contactless card 101 in response to a tap of the contactless card. In such an embodiment, a GUI provided by wallet service 150 on device 110-1 may instruct the user to tap contactless card 101 to device 110-1 (e.g., without presenting the GUI of FIG. 3B ). In response to a single tap of contactless card 101, applet 103 may generate encrypted data 105 and transmit encrypted data 105 to device 110-1 along with the account number, expiration date, and CVV of contactless card 101. The GUI provided by wallet service 150 (and / or account application 113) may then transmit encrypted data 105 to authentication server 120, which may verify encrypted data 105. Once the GUI provided by wallet service 150 receives an indication that authentication server 120 has verified encrypted data 105, values ​​may be programmatically entered into fields 321-325 of the GUI. In one embodiment, the account holder's name and / or address are received from applet 103 along with encrypted data 105. In other embodiments, the account holder's name and / or address are received from authentication server 120. The user may then submit the entered data via send button 326, which adds the contactless card 101 data to wallet 151 of wallet service 150.

[0045] FIG. 4 is a schematic diagram 400 illustrating an example of tapping a contactless card 101 to provision a virtual account number. As shown, an account application 113 executing on a computing device 110-3 outputs a GUI for receiving parameters 106. Illustratively, the GUI includes form fields 401-403, where field 401 corresponds to an amount field, field 402 corresponds to a primary account field (e.g., primary account holder), and field 403 corresponds to a merchant field. The form fields may be filled in by a requesting user as part of a request for a virtual card number and / or by the primary account holder as part of the assignment of the virtual card number. The example shown in FIG. 4 corresponds to an embodiment in which an employee fills in form fields 401-403 as part of a request to provision a sub-account. In this context, the embodiment is not limited. For example, a child may use the GUI of FIG. 4 to request a sub-account approved via the GUI of FIG. 3A.

[0046] As shown in FIG. 4 , the employee entered an amount of $300 in field 401, an example primary account of “Employer” in field 402, and an example merchant category of Hardware Store in field 403. When the employee selects submit button 404, account application 113 sends the request to the primary account owner. The request may typically be approved by the primary account owner (e.g., using the GUI shown in FIG. 3A ). While not shown for clarity, account application 113 on the primary account owner's device 110 may instruct the primary account owner to tap their contactless card 101 against device 110 to approve the request. In some embodiments, the primary account owner may add and / or modify requested parameters, for example, to impose location restrictions on the request. Contactless card 101 may then generate encrypted data 105, which is sent to account application 113 on the primary account owner's (e.g., employer's) computing device 110. The primary account holder's account application 113 may then send the encrypted data 105 and parameters 106 (e.g., values ​​and / or instructions for fields 401-403) to the authentication application 123. The authentication application 123 may then verify the encrypted data 105 and instruct the VAN generator 142 to generate a virtual account number, expiration date, and CVV that may be limited to $300 and may be used at merchants in the hardware store category. The virtual account number may then be sent to the sub-account holder's requesting device 110-3 and / or added to the sub-account holder's digital wallet 151.

[0047] FIG. 5 is a schematic diagram 500 illustrating the GUI of the account application 113 for managing provisioned virtual card numbers. As shown, the GUI of the account application 113 on the computing device 110-4 lists one or more previously generated virtual card numbers associated with a primary account and one or more sub-accounts. As shown, the GUI of the account application 113 allows the primary account owner to activate and / or deactivate virtual card numbers. For example, as shown, check box 501 is unchecked, thereby indicating that the associated virtual card number has not been activated. However, if the user checks check box 501, the account application 113 may reactivate the virtual account number. In some embodiments, the account application 113 requests that the user tap the contactless card 101 to the device 110-4 to reactivate the virtual account number (e.g., by generating encrypted data 105 that is verified by the authentication server 120, which may add requested funds to the reactivated virtual account number).

[0048] Similarly, check boxes 502-503 are checked to indicate that the associated virtual card numbers are active. When the user unchecks one or more of check boxes 502-503, the associated virtual account numbers are deactivated. In one embodiment, account application 113 requires the user to tap contactless card 101 to deactivate the virtual account numbers. In other embodiments, the virtual account numbers are deactivated without requiring the user to tap contactless card 101 to device 110-4.

[0049] The operation of the disclosed embodiments may be further described with reference to the following figures. Some figures may include logic flows. While such figures presented herein may include specific logic flows, it can be understood that the logic flows merely provide examples of how the general functionality as described herein may be implemented. Furthermore, a given logic flow does not necessarily have to be executed in the order presented, unless otherwise specified. Furthermore, a given logic flow may be implemented by a hardware element, a software element executed by a processor, or any combination thereof. In this context, the embodiments are not limited.

[0050] 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 for using a contactless card to provision a virtual account number. In this context, the embodiments are not limited.

[0051] As shown, logic flow 600 begins at block 605, where account application 113 receives parameters 106 for authorizing a virtual account number for a sub-account associated with a primary account. Parameters 106 may include user-defined parameters and / or parameters 106 received from contactless card 101. A sub-account may be associated with a primary account in any manner, such as through organizational ties, familial ties, friendships, etc. For example, a parent may provide parameters 106 specifying that a $20 virtual account number be generated for their child, which is valid for one week and can be used at bookstores within two miles of a city center. At block 610, account application 113 receives primary account credentials 115 to authenticate the primary account.

[0052] At block 615, the user taps the contactless card 101 to the computing device 110, causing the contactless card 101 to generate and transmit encrypted data 105. At block 620, the applet 103 of the contactless card 101 may generate the encrypted data 105 using the private key 104, input data (e.g., a customer identifier), and an encryption algorithm. The applet 103 may then transmit the encrypted data 105 to the computing device 110 at block 625. At block 630, the account application 113 may transmit the encrypted data 105 received from the contactless card 101 to the authentication server 120. The account application 113 may further transmit one or more parameters 106, e.g., the parameters received at block 605, to the authentication server 120. More generally, the parameters may include a primary account identifier, a subaccount identifier, a monetary value, a limit, etc.

[0053] At block 635, the authentication application 123 decrypts the encrypted data 105 using the private key 104 in the memory 122 of the authentication server 120 to verify the encrypted data 105. At block 640, the authentication application 123 sends instructions to the VAN generator 142 specifying the generation of a virtual account number, an expiration date, and a CVV. The authentication application 123 may further send the received parameters 106 and / or any data from the account data 124 to the VAN generator 142. At block 645, the VAN generator 142 generates the virtual account number, the expiration date, and the CVV according to the parameters 106. For example, the VAN generator 142 may limit the virtual account number to $30, which can be used by a child for one week at bookstores within two miles of a city center. At block 650, the VAN generator 142 sends the virtual account number, the expiration date, and the CVV to the computing device 110. As described above, in response to receiving the virtual account number, expiration date, and CVV, account application 113 and / or OS 112 may detect the virtual account number, expiration date, and CVV and perform operations. For example, account application 113 and / or OS 112 may auto-populate one or more form fields with the virtual account number, expiration date, and / or CVV, copy the virtual account number, expiration date, and / or CVV to a clipboard, etc.

[0054] At block 655, account application 113 and / or VAN generator 142 may provide the virtual account number, expiration date, and CVV to the sub-account owner's digital wallet 151 (e.g., via device 110 and / or wallet service 150). Similarly, VAN generator 142 may provide the virtual account number, expiration date, and CVV to authentication server 120, which may store the virtual account number, expiration date, and CVV in the sub-account owner's account data 124 (or other database for storing virtual card numbers). At block 660, the sub-account owner optionally completes a transaction using the virtual account number, expiration date, and CVV. For example, a child may use the virtual account number, expiration date, and CVV to purchase $20 worth of books from a bookstore the day after VAN generator 142 generated the virtual account number, expiration date, and CVV.

[0055] 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 receiving parameters for provisioning a virtual account number using the contactless card 101. In this context, the embodiments are not limited.

[0056] As shown, logic flow 700 begins at block 705, where the account application 113 receives a request to generate a virtual account number, including one or more parameters 106, from a sub-account user. For example, a child may request $30 from a parent at block 705. At block 710, the account application 113 may receive at least one parameter 106 from the primary account holder. For example, the parent may specify that the requested amount can only be used at a bookstore five miles from their home. At block 715, the account application 113 receives one or more parameters 106-2 from the contactless card 101. For example, the parameter 106 of the contactless card 101 may specify a one-week validity period for any virtual numbers provisioned using the contactless card 101. At block 720, the account application 113 may receive one or more parameters 106 from the authentication server 120. For example, parent account data 124 may specify parameters 106 that limit the amount of funds for any virtual number provisioned using contactless card 101 to a maximum of $20. Thus, using the parameters received in blocks 705-720, account application 113 receives parameters 106 specifying that a virtual account number be generated that is limited to $20 in weekly spending at a bookstore five miles from the home address associated with the primary account.

[0057] 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 an applet running on a contactless card. In this context, the embodiments are not limited.

[0058] As shown, logic flow 800 begins at block 805, where applet 103 executing in memory 102 of primary account owner's contactless card 101 receives an identifier of a sub-account device 110. The identifier may be, for example, but not limited to, a media access control (MAC) address, a unique device identifier, and / or a software fingerprint of an application installed on computing device 110. At block 810, applet 103 determines that the received identifier is designated as an identifier of an authorized device of the primary account owner. For example, applet 103 may find a matching identifier in memory 102 indicating that the device is authorized by the primary account owner. At block 815, applet 103 generates encrypted data 105 based on private key 104. Applet 103 may further generate a URL that includes encrypted data 105 as a parameter, where the URL is directed to an authentication server. The applet 103 may further include any parameters 106-2 stored in the memory of the contactless card 101. The applet 103 may then transmit the encrypted data 105, the URL, and / or the parameters 106-2 to the sub-account holder's computing device 110.

[0059] 9 illustrates an embodiment of a logic flow 900. The logic flow 900 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 900 may include some or all of the operations performed by the account application 113 to provision a virtual account number. In this context, the embodiments are not limited.

[0060] As shown, logic flow 900 begins at block 905, where account application 113 receives encrypted data 105 and a URL from a contactless card. In one embodiment, the encrypted data 105 is a parameter of the URL. In some embodiments, account application 113 and / or applet 103 may encode the encrypted data 105 into an encoding format compatible with a URL. At block 910, account application 113 and / or a web browser on computing device 110 may follow the URL, which may be directed to authentication server 120 and / or authentication application 123. As part of following the URL, account application 113 may provide parameters 106 for generating a virtual account number for the sub-account holder.

[0061] At block 915, authentication application 123 authenticates encrypted data 105 included as a parameter in the URL. If the encrypted data is encoded, authentication application 123 may decrypt the encrypted data 105. As described above, to authenticate the encrypted data 105, authentication application 123 decrypts the encrypted data using private key 104. At block 920, authentication application 123 sends instructions to VAN generator 142 authorizing the generation of a virtual account number, expiration date, and CVV. Authentication application 123 may further provide parameters 106 to VAN generator 142 to enable VAN generator 142 to implement any restrictions on the virtual account number (e.g., amount restrictions, time restrictions, location restrictions, merchant restrictions, etc.). VAN generator 142 may generate virtual card data including the virtual account number, expiration date, and CVV (and any restrictions) at block 925.

[0062] At block 930, the VAN generator 142 provides the generated virtual account number to an API of the digital wallet service 150. The VAN generator 142 may further provide an indication of the sub-account owner's digital wallet 151, which may be received from the account data 142. At block 935, the digital wallet service 150 adds the virtual account number, expiration date, and CVV to the sub-account owner's digital wallet 151. The sub-account owner may then make payment for the transaction using the virtual account number via the digital wallet 151.

[0063] FIG. 10 illustrates an embodiment of an exemplary computing architecture 1000 comprising a computing system 1002 that may be suitable for implementing various embodiments as described above. In various embodiments, the computing architecture 1000 may comprise or be implemented as part of an electronic device. In some embodiments, the computing architecture 1000 may represent, for example, a system implementing one or more components of the system 100. In some embodiments, the computing system 1002 may represent, for example, the contactless card 101, the computing device 110, the authentication server 120, the virtual account number server 140, and / or the wallet service 150 of the system 100. In this context, the embodiments are not limited. More generally, the computing architecture 1000 is configured to implement all logic, applications, systems, methods, apparatus, and functions described herein with reference to FIGS. 1-9.

[0064] 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 1000. 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 their 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. Example connections include parallel interfaces, serial interfaces, and bus interfaces.

[0065] The computing system 1002 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 the computing system 1002.

[0066] 10, computing system 1002 includes processor 1004, system memory 1006, and system bus 1008. Processor 1004 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 1004.

[0067] The system bus 1008 provides an interface to system components, including but not limited to, the processor 1004, from the system memory 1006. The system bus 1008 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 1008 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.

[0068] The system memory 1006 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. 10, the system memory 1006 may include non-volatile memory 1010 and / or volatile memory 1012. The non-volatile memory 1010 may store a basic input / output system (BIOS).

[0069] Computing system 1002 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) 1014, a magnetic floppy disk drive (FDD) 1016 that reads from or writes to a removable magnetic disk 1018, and an optical disk drive 1020 that reads from or writes to a removable optical disk 1022 (e.g., a CD-ROM or DVD). HDD 1014, FDD 1016, and optical disk drive 1020 may be connected to system bus 1008 by HDD interface 1024, FDD interface 1026, and optical drive interface 1028, respectively. HDD interface 1024 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies. The computing system 1002 is generally configured to implement all of the logic, systems, methods, devices, and functionality described herein with reference to FIGS.

[0070] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-readable instructions, computer-executable instructions, etc. For example, a number of program modules may be stored on the drives and memory units 1010, 1012, including an operating system 1030, one or more application programs 1032, other program modules 1034, and program data 1036. In one embodiment, the one or more application programs 1032, other program modules 1034, and program data 1036 may include, for example, various applications and / or components of system 100, such as applets 103, private keys 104, encrypted data 105, parameters 106, operating system 112, account application 113, authentication application 123, wallet service 150, and / or digital wallet 151.

[0071] A user may enter commands and information into the computing system 1002 through one or more wired / wireless input devices, for example, a keyboard 1038 and a pointing device such as a mouse 1040. 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, glove, 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 1004 through an input device interface 1042 coupled to the system bus 1008, 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.

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

[0073] The computing system 1002 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 1048. The remote computer 1048 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 1002, although for simplicity, only the memory / storage device 1050 is shown. The logical connections shown include wired / wireless connections to a local area network (LAN) 1052 and / or larger networks, e.g., a wide area network (WAN) 1054. 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 1052 and the WAN 1054.

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

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

[0076] The computing system 1002 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).

[0077] FIG. 11A 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 1102, which may display the card's name on the front or back. In some examples, the contactless card 101 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 1110, which may include a single layer or one or more laminated layers composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium oxide, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 101 may have physical characteristics that conform to the ID-1 format of the ISO / IEC 7810 standard; otherwise, the contactless card 101 may conform to the ISO / IEC 14443 standard. However, it should be understood that contactless cards 101 according to the present disclosure may have different characteristics and the present disclosure does not require contactless cards to be implemented as payment cards.

[0078] The contactless card 101 may also include identification information 1115 displayed on the front and / or back of the card, and a contact pad 1120. The contact pad 1120 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. 11A . These components may be located behind the contact pad 1120 or elsewhere on the substrate 1110. The contactless card 101 may also include a magnetic strip or tape (not shown in FIG. 11A ) that may be located on the back of the card.

[0079] 11B, the contact pad 1120 of the contactless card 101 may include processing circuitry 1125 for storing and processing information, including a microprocessor 1130 and memory 102. It will be understood that the processing circuitry 1125 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.

[0080] 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 may be read-only or one-time programmable at the factory. One-time programming allows it to be written once and read many times. Write-once / read-multiple memory may be programmed at some point after the memory chip leaves the factory. Once programmed, the memory may not be rewritten, but it may be read many times. Read / write memory may be programmed and reprogrammed many times after leaving the factory. Read / write memory may be read many times after leaving the factory.

[0081] Memory 102 may be configured to store one or more applets 103, private key 104, encrypted data 105, parameters 106-2, and one or more customer (or user) identifiers (IDs) 1107. One or more applets 103 may comprise 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 130 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. Customer ID 1107 may comprise a unique alphanumeric identifier assigned to a user of contactless card 101, which may distinguish the contactless card user from other contactless card users. In some examples, customer ID 1107 may identify both the customer and the account assigned to that customer, and further identify the contactless card associated with the customer's account. In some embodiments, the applet 103 may use the customer ID 1107 as input to an encryption algorithm using a private key 1108 to generate the encrypted data 108 .

[0082] While 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 external to, or completely separate from, the pads 1120, or as additional elements in addition to the processor 1130 and memory 102 elements located within the contact pads 1120.

[0083] In some examples, the contactless card 101 may include one or more antennas 1155. The one or more antennas 1155 may be disposed within the contactless card 101 and around the processing circuit 1125 of the contact pads 1120. For example, the one or more antennas 1155 may be integrated with the processing circuit 1125, or the one or more antennas 1155 may be used with an external booster coil. As another example, the one or more antennas 1155 may be external to the contact pads 1120 and the processing circuit 1125.

[0084] 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 disconnecting power or amplitude modulation. The contactless card 101 may infer data transmitted from the terminal using gaps in the contactless card's power connection, which may be maintained functionally through one or more capacitors. The contactless card 101 may return communication by switching the load on the contactless card's coil or load modulation. Load modulation may be detected in the terminal's coil through interference. More generally, using the antenna 1155, processing circuitry 1125, and / or memory 102, the contactless card 101 provides a communication interface for communicating via NFC, Bluetooth, and / or Wi-Fi communications.

[0085] As described above, contactless card 101 may be built on a software platform operable on a memory-limited smart card or other device, such as a Java Card, and one or more applications or applets may be securely executed. The applets 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 applets may be configured to respond to one or more requests, such as near-field wireless data exchange requests, from a reader, such as a mobile NFC reader (e.g., card reader 119 of device 110), and generate an NDEF message comprising the cryptographically secure OTP encoded as an NDEF text tag.

[0086] 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 computing 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 desired computational speed, power level, heat tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed and other design or performance constraints.

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

[0088] 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. 1. An apparatus, comprising: a processor circuit; and a memory storing instructions that, when executed by the processor circuit, cause the processor circuit to: receiving at least one parameter for authorizing a virtual account number of a sub-account associated with a primary account, the at least one parameter including an amount parameter associated with the virtual account number; receiving, by an application running on the processor circuit, authentication credentials for the primary account; a card reader of the device receiving encrypted data from a contactless card associated with the primary account, the encrypted data being based on an encryption algorithm and a private key; the application transmitting the encrypted data to an authentication server associated with the issuer of the contactless card; the application receiving verification of the encrypted data from the authentication server based on the encryption algorithm and the private key; the application providing the server with the at least one parameter for validating the virtual account number; receiving, by the application, a virtual account number for the sub-account generated by a virtual card number server, the virtual account number being limited to a spending limit based on the amount parameter associated with the virtual account number; A device that performs the following.

2. The memory stores instructions that, when executed by the processor circuit, cause the processor circuit to: the application providing the virtual account number to an application programming interface (API) of a digital wallet service to add the virtual account number to the user's digital wallet associated with the sub-account; The apparatus of claim 1 , wherein the apparatus causes the execution of the following:

3. 2. The device of claim 1, wherein the device comprises a first device associated with the sub-account, and the at least one parameter is received from at least one of (i) an applet running in the memory of the contactless card, (ii) the first device, and (iii) a second device associated with the primary account.

4. The device of claim 3 , wherein the at least one parameter is received from the second device associated with the primary account.

5. 5. The apparatus of claim 4, wherein the at least one parameter is received by an instance of the application executing on the processor circuit of the second device in response to a request generated by an instance of the application executing on the processor circuit of the first device.

6. 10. The apparatus of claim 1, wherein the at least one parameter further includes a time parameter specifying a time limit for using the virtual account number, a location parameter specifying one or more locations where the virtual account number may be used, and a merchant parameter specifying one or more merchants where the virtual account number may be used.

7. The memory stores instructions that, when executed by the processor circuit, cause the processor circuit to: the application outputs on a display a plurality of virtual account numbers provided for a plurality of sub-accounts associated with the primary account; receiving a selection of one of the plurality of virtual account numbers, the selected one of the plurality of virtual account numbers including an inactive virtual account number; activating a selected one of the plurality of virtual account numbers, said activating providing an additional amount of funds to the activated virtual account number; The apparatus of claim 1 , further comprising:

8. receiving at least one parameter for authorizing a virtual account number of a sub-account associated with a primary account, the at least one parameter including an amount parameter associated with the virtual account number; receiving, by an application executing on a processor circuit of the first device, authentication credentials for the primary account; a card reader of the first device receiving encrypted data from a communication interface of a contactless card associated with the primary account, the encrypted data being generated by an applet executing in the memory of the contactless card using an encryption algorithm and a private key stored in the memory of the contactless card; the application transmitting the encrypted data to an authentication server associated with the issuer of the contactless card; the application receiving verification of the encrypted data from the authentication server, the authentication server verifying the encrypted data based on the encryption algorithm and an instance of a private key stored in a memory of the authentication server; the application providing the server with the at least one parameter for validating the virtual account number; receiving, by the application, a virtual account number for the sub-account generated by a virtual card number server, the virtual account number being limited to a spending limit based on the amount parameter associated with the virtual account number; A method comprising:

9. The method comprises: the application providing the virtual account number to an application programming interface (API) of a digital wallet service to add the virtual account number to the user's digital wallet associated with the sub-account; The method of claim 8 further comprising:

10. 9. The method of claim 8, wherein the first device is associated with the sub-account, and the at least one parameter is received from at least one of (i) the applet executing in the memory of the contactless card, (ii) the first device, and (iii) a second device associated with the primary account, and the at least one parameter further includes a time parameter specifying a time limit for using the virtual account number, a location parameter specifying one or more locations where the virtual account number may be used, and a merchant parameter specifying one or more merchants where the virtual account number may be used.

11. The at least one parameter is received from the second device associated with the primary account, and the authentication server: receiving, from an instance of the application executing on a processor circuit of the second device, encrypted data received by the second device from the communication interface of the contactless card associated with the primary account; The method of claim 10 , further comprising verifying the encrypted data received by the second device from the communication interface of the contactless card associated with the primary account.

12. 12. The method of claim 11, wherein the at least one parameter is received by an instance of the application executing on the processor circuit of the second device in response to a request generated by an instance of the application executing on the processor circuit of the first device.

13. The applet running in the memory of the contactless card comprises: receiving an identifier of the first device, the identifier including one or more of: (i) a media access control (MAC) address of the card reader; (ii) a unique identifier of the first device; and (iii) a software fingerprint of the first device generated based on a plurality of applications installed on the first device; configured to determine that the identifier of the first device is designated as one of a plurality of devices associated with the primary account. The method of claim 8.

14. The communication interface of the contactless card is configured to support at least one of Near Field Communication (NFC), Bluetooth, and Wi-Fi, and the method includes: the application outputs on a display a plurality of virtual account numbers provided for a plurality of sub-accounts associated with the primary account; receiving a selection of one of the plurality of virtual account numbers, the selected one of the plurality of virtual account numbers including an inactive virtual account number; activating a selected one of the plurality of virtual account numbers, said activating providing an additional amount of funds to the activated virtual account number; The method of claim 8 further comprising:

15. A non-transitory computer-readable storage medium having computer-readable program code embodied therein, the computer-readable program code executable by a processor circuit of a first device, the computer-readable program code causing the processor circuit to: receiving at least one parameter for authorizing a virtual account number of a sub-account associated with a primary account, the at least one parameter including an amount parameter associated with the virtual account number; receiving, by an application running on the processor circuit, authentication credentials for the primary account; a card reader receiving encrypted data from a communication interface of a contactless card associated with the primary account, the encrypted data being based on an encryption algorithm and a private key; the application transmitting the encrypted data to an authentication server associated with the issuer of the contactless card; the application receiving verification of the encrypted data from the authentication server based on the encryption algorithm and the private key; the application providing the at least one parameter for authorizing the virtual account number to the server; receiving, by the application, a virtual account number for the sub-account generated by a virtual card number server, the virtual account number being limited to a spending limit based on the amount parameter associated with the virtual account number; A non-transitory computer-readable storage medium that causes the

16. The non-transitory computer-readable storage medium may include: the application providing the virtual account number to an application programming interface (API) of a digital wallet service to add the virtual account number to the user's digital wallet associated with the sub-account; 16. The non-transitory computer-readable storage medium of claim 15, further comprising computer-readable program code executable by the processor circuitry to cause the processor circuitry to perform:

17. 16. The non-transitory computer-readable storage medium of claim 15, wherein the first device is associated with the sub-account, and the at least one parameter is received from at least one of (i) an applet running on the contactless card, (ii) the first device, and (iii) a second device associated with the primary account.

18. The at least one parameter is received from the second device associated with the primary account, and the non-transitory computer-readable storage medium stores instructions that, when executed by the authentication server, cause the authentication server to: receiving, from an instance of the application executing on a processor circuit of the second device, encrypted data received by the second device from the communication interface of the contactless card associated with the primary account; verifying the encrypted data received by the second device from the communication interface of the contactless card associated with the primary account; 20. The non-transitory computer-readable storage medium of claim 17,

19. 20. The non-transitory computer-readable storage medium of claim 18, wherein the at least one parameter is received by an instance of the application executing on the processor circuitry of the second device in response to a request generated by an instance of the application executing on the processor circuitry of the first device.

20. 16. The non-transitory computer-readable storage medium of claim 15, wherein the at least one parameter further includes a time parameter specifying a time limit for using the virtual account number, a location parameter specifying one or more locations where the virtual account number may be used, and a merchant parameter specifying one or more merchants where the virtual account number may be used.

Images