Provisioning of Virtual Numbers for Tapping a Contactless Card on a Computing Device

Abstract

A system, method, article of manufacture, and computer-readable medium for provisioning a virtual number by tapping a contactless card to a computing device may receive at least one parameter for authorizing a virtual account number for a sub-account associated with a primary account. An application running on a processor circuit may receive authentication credentials for the primary account. The card reader may receive encrypted data from a communication interface of the contactless card. The application may transmit the encrypted data to an authentication server. The application may receive verification of the encrypted data from the authentication server. The application provides at least one parameter for authorizing the virtual account number and receives a virtual account number for the sub-account generated by the virtual card number server, where the virtual account number may be limited to a spending limit based on an amount parameter associated with the virtual account number.

Description

Technical Field

[0001] Related Applications This application claims priority to U.S. Patent Application No. 16 / 731,835, entitled "Provisioning of Virtual Numbers by Tapping a Contactless Card on a Computing Device," filed on December 31, 2019. The entire content of the foregoing application is incorporated herein by reference in its entirety.

[0002] Technical Field Embodiments herein generally relate to computing platforms, and more specifically, to provisioning virtual numbers by tapping a contactless card on a computing device.

Background Art

[0003] Card owners (e.g., credit card owners, bank card owners, etc.) often obtain additional physical cards for trusted individuals such as family members or employees. However, obtaining additional physical cards is not practical in many situations. For example, it is not practical to obtain additional physical cards with nominal spending limits. Similarly, it is not practical to obtain additional physical cards for low-frequency purchasers or to deactivate and / or reactivate existing physical cards for such users.

Summary of the Invention

[0004] The embodiments disclosed in this specification provide a system, method, article of manufacture, and computer-readable medium for tapping a contactless card to a computing device to provision a virtual number. According to an example, at least one parameter for authorizing a virtual account number of a sub-account associated with a primary account may be received, and the at least one parameter includes an amount parameter associated with the virtual account number. An application running on a processor circuit may receive authentication credentials of 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 executed in the memory of the contactless card using an encryption algorithm and a secret key stored in the memory of the contactless card. The application may send the encrypted data to an authentication server associated with the issuer of the contactless card. 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 an instance of the secret key stored in the memory of the authentication server. The application may provide at least one parameter for authorizing the virtual account number and may receive a virtual account number for a sub-account generated by a virtual card number server. The virtual account number is restricted by an expenditure limit based on an amount parameter associated with the virtual account number.

Brief Description of the Drawings

[0005]

Figure 1A

Figure 1B

Figure 1C

Figure 2A

Figure 2B

Figure 3A

Figure 3B

Figure 3C

Figure 3D

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11A

Figure 11B

DETAILED DESCRIPTION OF THE INVENTION

[0006] The embodiments disclosed herein provide a secure technique for tapping a contactless card on a computing device to provision a virtual account number from one account (referred to herein as the "primary account") to one or more other accounts (referred to herein as the "sub - accounts"). Generally, a user may specify parameters of the virtual account number and provide input to an application running on the computing device. For example, the user may specify to generate a virtual account number of $20 for a child to be used within one week at a grocery store. Next, the user may tap the contactless card on the computing device. Thereby, the contactless card may enter the communication range of the computing device. By doing so, the contactless card generates encrypted data, which is sent to the computing device. The application may receive the encrypted data generated by the contactless card and send the encrypted data to an authentication server for verification. When verified, the authentication server may instruct the virtual account number server to generate a virtual account number, an expiration date, and a card verification value (CVV) account associated with the contactless card. Next, the generated virtual account number (including the expiration date and / or CVV) may be sent to the device of the user and / or recipient of the virtual account number. It is also possible to add the virtual account number to the recipient's digital wallet. The recipient may use the virtual account number based on the input parameters. For example, the child may take one week to spend the $20 assigned to the virtual account number at the grocery store.

[0007] Advantageously, the embodiments disclosed herein improve the security of all devices and related data. For example, by eliminating the need for physical cards, the risks associated with physical cards are avoided. Further, the verification performed by the authentication server provides a safeguard to confirm that an authorized user with access to the physical card is requesting the generation of a virtual account number. Additionally, by applying the rules associated with the generation of the virtual account number, the security of the account that authorizes 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 following detailed description may be presented with respect to program procedures executed on a computer or a network of computers. The description and representation of these procedures 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 is conceived to be, a self-consistent sequence of operations leading to a desired result. These operations are those requiring physical manipulation 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. For reasons of common usage mainly, it is convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc. However, it should be noted that all of these and similar terms are merely convenient labels associated with appropriate physical quantities and are nothing more than convenient labels applied to these quantities.

[0009] Furthermore, these operations are often referred to in terms such as addition and comparison, which are generally associated with intellectual operations performed by a human operator. However, in any of the operations described herein that form part of one or more embodiments, such capabilities of a human operator are not necessary or, in most cases, desirable. Rather, these operations are machine operations. Useful machines for performing the operations of the various embodiments include digital computers selectively activated or configured by computer programs stored therein, written in accordance with the teachings herein, and / or include devices or digital computers specially constructed for the required purposes. The various embodiments also relate to devices or systems for performing these operations. These devices can be specially constructed for the required purposes. The structures required for these various machines will become apparent from the given description.

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

[0011] FIG. 1A shows a schematic diagram of an exemplary system 100 that conforms to the disclosed embodiments. As shown, 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. Contactless card 101 represents any type of payment card such as a credit card, debit card, ATM card, gift card, etc. Contactless card 101 may include one or more communication interfaces 107, such as a radio frequency identification (RFID) chip, configured to communicate with computing device 110 via NFC, EMV standard, or other short-range protocols in wireless communication. Although NFC is used as an example of the communication protocol, the present disclosure is equally applicable to other types of wireless communication such as EMV standard, Bluetooth®, and / or Wi-Fi. Computing device 110 represents any type of network-enabled computing device such as a smartphone, tablet computer, wearable device, laptop, portable game device, mobile device, workstation, desktop computer, server, etc. Servers 120, 140, and wallet service 150 represent any type of computing device such as a server, workstation, computing cluster, cloud computing platform, virtualized computing system, etc.

[0012] As shown, the memory 111 of the computing device 110 includes an instance of an operating system (OS) 112. Examples of operating systems 112 include the Android® OS, iOS®, macOS®, Linux®, and Windows® operating systems. As shown, the OS 112 includes an account application 113. The account application 113 enables a user to perform various account-related operations such as viewing account balances, purchasing items, processing payments, and generating and managing virtual account numbers. First, the user can authenticate using authentication credentials to access specific functions of the account application 113. For example, the authentication credentials can include a username and password, biometric authentication credentials (e.g., fingerprint, FaceID, etc.). As shown, the account application 113 can 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 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 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, one or more of the parameters 106 - 2 stored in the memory 102 of the contactless card 101 may be used to generate the virtual account number (e.g., as default parameters that may be automatically entered in the form of account application 113). Generally, by provisioning a virtual account number, the user of the primary account may allocate funds and / or extend credit to the user of the sub - account. In at least one embodiment, the sub - account is the generated virtual account number.

[0014] For example, an employer (owner of the primary account) may assign a virtual account number to an employee (owner of the sub - account) so that the employee can purchase up to $2,000 worth of office furniture from one or more vendors that sell office furniture. The employer may provide primary account qualification information 115 to authenticate the primary account in account application 113. Next, the employer may enter parameters 106 - 1 in the form of account application 113. Parameters 106 - 1 may include a display of the sub - account (or the recipient of the sub - account if no sub - account exists), the amount of the virtual account number, the period during which the virtual account number can be used, and one or more vendors with which the virtual account number can be used. In some embodiments, the employee may provide sub - account qualification information 114 to account application 113 to process the provisioning of the virtual account number.

[0015] In response, the account application 113 may output a notification to the computing device 110, which may be the primary account owner and / or a sub-account owner. The notification may instruct the user to tap the contactless card 101 of the primary account owner on the computing device 110, thereby bringing the contactless card 101 close enough to the card reader 119 of the computing device 110 to enable data transfer (e.g., NFC data transfer, Bluetooth® data transfer, etc.) between the communication interface 107 of the contactless card 101 and the card reader 119 of the computing device 110. Next, an applet 103 executed by a processor (not shown) of the contactless card 101 may generate encrypted data 105 and transmit it to the computing device 110 via the communication interface 107. For example, the applet 103 of the contactless card 101 may generate an encrypted payload of the encrypted data 105 based at least in part on a secret key 104 stored in the memory 102 of the contactless card 101 using an encryption algorithm. In such an embodiment, the secret key 104 and some other data (e.g., customer identifier, account identifier, etc.) may be provided as inputs to the encryption algorithm that outputs the encrypted data 105. Generally, 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 as limiting the present disclosure.

[0016] In some embodiments, the applet 103 may perform encryption using key diversification techniques to generate encrypted data 105. For example, the applet may use the 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 the contactless card 101 and the server 120. The counter value may comprise a number that changes each time data is exchanged between the contactless card 101 and the server 120 (and / or between the contactless card 101 and the mobile device 110). When preparing to send data (e.g., to the server 120 and / or the mobile device 110), the contactless card 101 may increment the counter value. Next, the contactless card 101 may provide the master key 105 and the counter value as input to an encryption algorithm, which generates a diversified key as output. Next, the diversified key may be used to generate the encrypted data 105. Next, the server 120 may 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 symmetric encryption algorithms such as 3DES or AES128, symmetric HMAC algorithms such as HMAC-SHA-256, and symmetric CMAC algorithms such as AES-CMAC. Examples of key diversification techniques are described in detail in U.S. Patent Application No. 16 / 205,119, filed on November 29, 2018. The foregoing patent application is hereby incorporated by reference in its entirety.

[0017] In some embodiments, computing device 110 may send a device identifier to applet 103. The device identifier can be any identifier such as a media access control (MAC) address, a unique device identifier, a software fingerprint of an application installed on computing device 110, etc. In some such embodiments, applet 103 determines whether the received device identifier matches (or is similar to) one or more permitted device identifiers stored in parameter 106-2. If the received identifier matches, applet 103 may generate encrypted data 105. If the received identifier does not match, applet 103 may refrain from generating encrypted data 105 to maintain security. Further, applet 103 may apply other rules to parameter 106-2 when determining whether to generate encrypted data 105. For example, parameter 106-2 may specify a threshold number of permitted virtual account numbers, and applet 103 may determine whether the generation of additional virtual account numbers exceeds the threshold. As another example, computing device 110 may send parameter 106-1 specified by the user. If parameter 106-1 specified by the user exceeds the corresponding threshold of parameter 106-2, applet 103 may refrain from generating encrypted data 105. For example, if the dollar amount specified as parameter 106-1 exceeds the maximum dollar amount specified by parameter 106-2, the applet may refrain from generating encrypted data 105.

[0018] Once generated, applet 103 may send the encrypted data 105 to the account application 113 of computing device 110, for example, via NFC. In some embodiments, applet 103 may also send one or more parameters from parameter 106-2 to account application 113. Account application 113 may send the encrypted data 105 and parameters 106 (which may include one or more parameters 106-1 and / or one or more parameters 106-2) to the authentication application 123 of authentication server 120. Parameters 106 may include, but are not limited to, primary account identifiers, sub-account identifiers, virtual account values, any restrictions, etc. In some embodiments, account application 113 may determine (e.g., based on one or more of the above rules) whether the parameters 106 specified for the generation of the virtual account number are permitted before sending the 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, if the requested location is not within one or more permitted regions specified by parameters 106, account application 113 may reject the request to generate a virtual account number. In some embodiments, account application 113 sends additional data to authentication application 123 (e.g., the device identifier of computing device 110, etc.).

[0019] Figure 1B shows an embodiment in which the account application 113 sends the encrypted data 105 and the parameter 106 to the authentication server 120. Upon receipt, the authentication application 123 may authenticate the encrypted data 105. For example, the authentication application 123 may attempt to decrypt the encrypted data 105 using a copy of the secret key 104 stored in the memory 122 of the authentication server 120. The secret key 104 may be identical to the secret key 104 stored in the memory 102 of the contactless card 101. Here, each contactless card 101 is manufactured to include a unique secret key 104 (and the authentication server 120 stores a corresponding copy of each unique secret key 104). Thus, the authentication application 123 may successfully decrypt the encrypted data 105, thereby verifying the encrypted data 105. Although the secret key 104 is shown as being stored in the memory 122, the secret key 104 may be stored in other locations such as a secure element and / or a hardware security module (HSM). In such embodiments, the secure element and / or HSM may use the secret key 104 and the encryption function to decrypt the encrypted data 105.

[0020] For example, as described, a customer identifier (e.g., of the primary account) can be used to generate encrypted data 105. In such an example, the authentication application 123 can decrypt the encrypted data 105 using the private key 104 of the authentication server 120. If, as a result of the decryption, a customer identifier associated with the primary account of the account data 124 is obtained, the authentication application 123 verifies the encrypted data 105 and instructs the VAN generator 142 to generate a virtual account number 126 (including expiration date and CVV) of the account associated with the contactless card 101. If the authentication application 123 decrypts the encrypted data and does not obtain the expected result (e.g., the customer identifier of the primary account associated with the contactless card 101), the authentication application 123 does not verify the encrypted data 105. Since the verification fails, the authentication application 123 does not instruct the 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 check whether the parameters 106 for generating the virtual account number comply with one or more rules (e.g., in the account data 124, parameters 106-1, and / or 106-2). 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 of a related account within 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, the authentication application 123 may determine whether the software fingerprint matches a known software fingerprint of a related account within the account data 124. If the software fingerprint is not a known software fingerprint, 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 yet another example, the authentication application 123 may determine whether the GPS coordinates of the device 110 indicate that the user is at home, at work, or at another known address associated with the account of the account data 124. If the location of the device 110 is not within a threshold distance of a known address, 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 yet another example, the authentication application 123 may determine whether the GPS coordinates of the requested location where the virtual account number is to be used are within one or more permitted locations specified in the account data 124. For example, if the requested location is within one mile of the home address associated with the account and the account data 124 limits the use of the virtual card number to four miles from the home address, the authentication application 123 may instruct the VAN generator 142 to generate a virtual account number. However, if the requested location is not within one or more permitted locations, the authentication application 123 may refrain from instructing the VAN generator 142 to generate a virtual account number.

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

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

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

[0025] Generally, once generated, the virtual account number 126 can be used according to the restrictions specified by the parameters 106. For example, if the parameter 106 restricts the virtual account number 126 to a spending limit of $50 for one year at a restaurant within one mile of the company's office, each attempt to use the virtual account number 126 as a form of payment is analyzed according to the parameter 106. For example, if an employee tries to spend $75 at a restaurant 10 miles away from the company's office using the virtual account number 126, the payment can be rejected because it violates the spending and location restrictions. However, if an employee tries to spend $10 at a restaurant 0.5 miles away from the company's office one week after the virtual account number 126 is generated, the payment can be processed using the virtual account number 126.

[0026] Although depicted as being added via wallet service 150 and / or digital wallet 151-1, virtual account numbers (including expiration dates, CVVs, or other account-related data) can be sent and / or added using other technologies. For example, virtual account numbers can be sent via email, text message, or other technologies. Further, in one or more embodiments, OS 112 and / or account application 113 can detect the 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 can analyze text such as email, text message, push notification, etc. to detect a virtual account number, CVV, expiration date, and / or other account-related data. As another example, account application 113 can receive an instruction from contactless card 101 that the transmitted data payload includes a virtual account number, expiration date, CVV, billing address, etc.

[0027] In response to detecting the 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 that the virtual account number is to be used, e.g., to complete a mobile payment. Additionally and / or alternatively, OS 112 and / or account application 113 may provide selectable options (e.g., links, buttons, etc.). Thereby, the virtual account number, expiration date, and / or CVV can be copied to the clipboard of OS 112. Additionally and / or alternatively, OS 112 and / or account application 113 may automatically input 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 such as account application 113, OS 112, wallet service 150, digital wallet 151, web browser 203). In some embodiments, OS 112 and / or account application 113 may automatically input data in response to receiving user input specifying the automatic input (e.g., via a link and / or button that specifies to perform the automatic input that may be selected by the user). More generally, any type of operation may be performed in response to receipt of a virtual account number, CVV, expiration date, and / or other account-related data.

[0028] Figure 2A is a schematic diagram 200 showing an exemplary embodiment of provisioning a virtual card number by tapping a contactless card 101 without requiring the recipient to authenticate with an account application 113. As shown, the account application 113 may receive primary account qualification information 115 from a user associated with the primary account. The user may further specify parameters 106-1 via the account application 113, for example, indicating the recipient of the virtual card number, the associated amount, and / or any restrictions. As described, in some embodiments, one or more parameters 106-2 may be received from the contactless card 101. When the parameters 106 are submitted, the account application 113 instructs the user of the primary account to tap the contactless card 101 on the computing device 110 to provision the virtual card number.

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

[0030] In some embodiments, the encrypted data 105 can be a character string, for example, "ABC123". The applet 103 can include the generated encrypted data 105 as a parameter of the URL 201, thereby generating a URL using the encrypted data 202. For example, the URL 201 to the authentication server 120 can be "http: / / www.example.com / ". Thus, the URL including the encrypted data 202 can be "http: / / www.example.com / ?ABC123". In some embodiments, the applet 103 can encode the encrypted data 105 according to an encoding format compatible with the URL before including the encrypted data 105 as a parameter of the URL 201. For example, the encrypted data 105 can be a character string of binary data (for example, 0 and 1) that may not be compatible with the URL. Thus, the applet 103 can encode the encrypted data 105 into the American Standard Code for Information Interchange (ASCII) base64 encoding format for information exchange. By doing so, the binary encrypted data 105 is converted into a base 64 representation (for example, "ABC123" in the previous example) and represented in the ASCII character string format.

[0031] Once generated, the applet 103 may send a URL containing the encrypted data 202 to the mobile device 110, for example, via NFC. In one embodiment, when received by the OS 112, the OS 112 causes the web browser 203 to access a URL containing the encrypted data 202. By doing so, information describing the mobile device 110 is sent along with a 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 sub-account identifier, an amount value, any restrictions, etc., in the URL containing the encrypted data 202.

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

[0033] Next, the authentication application 123 may attempt to decrypt the encrypted data 105 using the private key 104 associated with the contactless card 101 of the primary account. As described, in some embodiments, the encrypted data 105 is encrypted by the applet 103. In such embodiments, the authentication application 123 may decrypt the encrypted data 105 before the decryption attempt is made. If the authentication application 123 decrypts the encrypted data and does not obtain the expected result (e.g., the customer identifier of the primary account, etc.), 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., the customer identifier of the primary account, etc.), 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 instructions for the parameters 106 received from the account application 113 (e.g., the primary account identifier, the sub-account identifier, the amount value, any restrictions, etc.).

[0034] Figure 2B shows an embodiment where the authentication application 123 verifies the encrypted data 105 extracted from a URL containing the encrypted data 202. In response, the VAN generator 142 generates a virtual account number 204 that includes a virtual account number, an expiration date, and a CVV value. As described above, the virtual account number 204 can be generated based on the parameter 106. Thus, the virtual account number 204 can be associated with the sub-account owner and restricted to the amount specified by the parameter 106. The virtual account number 204 can be further restricted based on the parameter 106 in terms of a period, a type of merchant, one or more specific merchants, one or more geographical locations, etc. Next, the VAN generator 142 can send the virtual account number 204 to the API of the wallet service 150, which can add the virtual account number 204 to the digital wallet 151-1 of the sub-account owner. As another example, the VAN generator 142 can send the virtual account number 204 to a computing device, which can add the virtual account number 204 to the digital wallet 151-1 of the sub-account owner.

[0035] Figure 3A is a schematic diagram 300 showing an example of tapping a contactless card 101 to provision a virtual card number. As shown, an account application 113 executed on a computing device 110-1 outputs a graphical user interface (GUI) for receiving a parameter 106. Exemplarily, 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 sub-account), 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 can be input by a user requesting as part of a request for a virtual card number and / or by a primary account owner as part of the granting of the virtual card number. The example shown in Figure 3A corresponds to an embodiment where the primary account owner inputs into form fields 301-304. As shown, the user of the primary account owner inputs an amount of $30 into field 301, an example of a recipient "Child 1" into field 302, a period of one day into field 303, an example of a merchant category of a jewelry store into field 304, and an example of a location 2 miles from home into field 305.

[0036] When a form of the account application 113 on the device 110-1 is submitted, the account application 113 sends a request to the device 110-2 of the sub-account owner. In one embodiment, the account application 113 sends the request to the authentication server 120, which may then send the request to the device 110-2 of the sub-account owner. Generally, the request includes the parameter 106 (e.g., at least an indication of the values entered in the form fields 301-305 and / or other parameters resolved based on the values entered in the form fields 301-305). As shown, the account application 113 on the computing device 110-2 received the authentication credentials of the sub-account. Further, the account application 113 on the computing device 110-2 requires the credentials of the primary account (fingerprint in this example). Next, the account application 113 on the computing device 110-2 may instruct the primary account owner to tap the contactless card 101 on the computing device 110-2. Next, the applet 103 of the contactless card 101 may generate the encrypted data 105 and send it to the computing device 110-2. Next, the account application 113 on the computing device 110-2 may send the encrypted data 105 to the authentication server 120 together with the parameter 106 (e.g., the values from the form fields 301-304). Next, the authentication server 120 may verify the encrypted data 105 and instruct the VAN generator 142 to generate a virtual account number, expiration date, and CVV according to the restrictions specified by the parameter 106. Next, the VAN generator 142 may send the generated virtual account number to the computing device 110-2 of the sub-account owner. 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 showing an example of tapping the contactless card 101 to add an account number to the digital wallet 151. As shown, the computing device 110-1 outputs a GUI that specifies tapping the contactless card to add the card to the digital wallet. The GUI can be part of the 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 the checkbox 311. If the user selects the checkbox 311, the virtual account number generated by the VAN generator 142 can be added to the corresponding wallet 151. If the user does not select the checkbox 311, the card number associated with the contactless card can be added to the corresponding wallet 151. Further, as shown, the GUI includes checkboxes 312-313 to enable the user to specify which wallet 151 to add the account number to. For example, as shown, the user has selected the checkbox 312 but not the checkbox 313. Thus, the account number can be added to the wallet 151 in the example of "Wallet x" but not to "Wallet y". The different wallets "Wallet x" and "Wallet y" can be provided by the same wallet service 150 and / or different wallet services 150.

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

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

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

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

[0042] As described above, the GUI shown in FIG. 3B can be provided by the wallet service 150 (and / or an application associated with the wallet service 150). FIG. 3D is a schematic diagram 320 that reflects such an example. In FIG. 3D, the authentication server 120 verified the encrypted data 105 generated by the contactless card 101 in response to a tap of the contactless card 101 on the device 110-1. Once verified, the authentication server 120 may send an indication of the verification of the encrypted data 105 to the GUI provided by the wallet service 150 on the device 110-1. As shown, the GUI provided by the wallet service 150 on the device 110-1 then outputs fields 321-325. Data may be automatically entered into fields 321-325. The values entered into fields 321-325 are examples and should not be considered as limiting the disclosure.

[0043] For example, field 321 can be input to correspond to an account number and 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 can be obfuscated. Similarly, field 322 can be input to correspond to an expiration date and include an expiration date generated by VAN generator 142 and / or the expiration date of contactless card 101. Field 323 can be input to correspond to a CVV value and include a CVV generated by VAN generator 142 and / or the CVV of contactless card 101. Field 324 can be input to correspond to an account owner name and include an account owner name received from authentication server 120, VAN generator 142, and / or contactless card 101. Field 325 can be input to correspond to an account owner address and include an account owner address received from authentication server 120, VAN generator 142, and / or contactless card 101. Next, the user can send the information in the input fields 321-325 to wallet service 150 via send button 326 to add it to the user's wallet 151.

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

[0045] FIG. 4 is a schematic diagram 400 showing an example of tapping a contactless card 101 to provision a virtual account number. As shown, an account application 113 running on a computing device 110-3 outputs a GUI for receiving a parameter 106. Exemplarily, 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 owner), and field 403 corresponds to a merchant field. The form fields can be input by a user who requests them as part of a virtual card number request and / or by a primary account owner as part of virtual card number provisioning. The example shown in FIG. 4 corresponds to an embodiment where an employee inputs into 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 can 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 of the primary account of the "employer" in field 402, and an example of the jeweler merchant category in field 403. When the employee selects the send button 404, the account application 113 sends a request to the primary account owner. The request can typically be approved by the primary account owner (e.g., using the GUI shown in FIG. 3A). Although not shown for clarity, the account application 113 on the primary account owner's device 110 may instruct the primary account owner to tap their contactless card 101 on the device 110 to approve the request. In some embodiments, the primary account owner may add and / or change the requested parameters, for example, to impose location restrictions on the request. Next, the contactless card 101 may generate encrypted data 105, which is sent to the account application 113 on the computing device 110 of the primary account owner (e.g., the employer). Next, the primary account owner's account application 113 may send the encrypted data 105 and parameters 106 (e.g., the values of fields 401-403 and / or its instructions) to the authentication application 123. Next, the authentication application 123 verifies the encrypted data 105 and may instruct the VAN generator 142 to generate a virtual account number, expiration date, and CVV that is limited to $300 and can be used by merchants in the jeweler category. Next, the virtual account number is sent to the request device 110-3 of the sub-account owner and / or added to the digital wallet 151 of the sub-account owner.

[0047] FIG. 5 is a schematic diagram 500 showing the GUI of the account application 113 for managing the 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 the primary account and one or more sub-accounts. As shown, the GUI of the account application 113 enables the primary account owner to activate and / or deactivate the virtual card numbers. For example, as shown, the checkbox 501 is unchecked, indicating that the associated virtual card number is not activated. However, if the user checks the checkbox 501, the account application 113 may reactivate the virtual account number. In some embodiments, the account application 113 requires the user to tap the contactless card 101 on the device 110-4 to reactivate the virtual account number (e.g., by generating the encrypted data 105 verified by the authentication server 120, the required funds may be added to the reactivated virtual account number).

[0048] Similarly, the checkboxes 502-503 are checked, indicating that the associated virtual card numbers are active. If the user unchecks one or more of the checkboxes 502-503, the associated virtual account numbers are deactivated. In one embodiment, the account application 113 requires the user to tap the contactless card 101 to deactivate the virtual account number. In other embodiments, the virtual account number is deactivated without the user having to tap the contactless card 101 on the device 110-4.

[0049] The operations of the disclosed embodiments may be further described with reference to the following figures. Some of the figures may include a logical flow. It can be understood that such figures presented herein may include a specific logical flow, but the logical flow only provides examples of how the general functions described herein can be implemented. Further, a given logical flow need not necessarily be executed in the order presented, unless otherwise specified. Further, a given logical flow may be implemented by hardware elements, software elements executed by a processor, or any combination thereof. In this context, the embodiments are not limited.

[0050] FIG. 6 shows an embodiment of a logical flow 600. The logical flow 600 may represent some or all of the operations performed by one or more of the embodiments described herein. For example, the logical 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, the logical flow 600 begins at block 605, where the account application 113 receives parameters 106 for approving a virtual account number for a sub-account associated with the primary account. The parameters 106 may include user-defined parameters received from the contactless card 101 and / or the parameters 106. The sub-account may be associated with the primary account in any way, such as an organizational relationship, a family relationship, a friendship, etc. For example, a parent may provide parameters 106 that specify to generate a virtual account number of $20 for a child, which is valid for one week and can be used at a bookstore within 2 miles of the city center. At block 610, the account application 113 receives primary account qualification information 115 to authenticate the primary account.

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

[0053] In 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. In block 640, the authentication application 123 sends an instruction to the VAN generator 142 to generate a virtual account number, expiration date, and CVV. The authentication application 123 may further send the received parameter 106 and / or any data from the account data 124 to the VAN generator 142. In block 645, the VAN generator 142 generates a virtual account number, expiration date, and CVV according to the parameter 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 a bookstore within 2 miles from the city center. In block 650, the VAN generator 142 sends the virtual account number, expiration date, and CVV to the computing device 110. As described above, in response to receiving the virtual account number, expiration date, and CVV, the account application 113 and / or the OS 112 may detect the virtual account number, expiration date, and CVV and perform operations. For example, the account application 113 and / or the OS 112 may automatically enter the virtual account number, expiration date, and / or CVV into one or more form fields, or copy the virtual account number, expiration date, and / or CVV to a clipboard or the like.

[0054] At block 655, the account application 113 and / or the VAN generator 142 may provide the virtual account number, expiration date, and CVV to the digital wallet 151 of the sub-account owner (e.g., via the device 110 and / or the wallet service 150). Similarly, the VAN generator 142 may provide the virtual account number, expiration date, and CVV to the 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 may optionally use the virtual account number, expiration date, and CVV to complete a transaction. For example, a child may use the virtual account number, expiration date, and CVV to purchase a $20 book from a bookstore the day after the VAN generator 142 generates the virtual account number, expiration date, and CVV.

[0055] FIG. 7 shows an embodiment of a logical flow 700. The logical flow 700 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logical 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 account application 113 receives a request to generate a virtual account number that includes 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, account application 113 may receive at least one parameter 106 from the primary account owner. For example, the parent may specify that the requested amount can only be used at a bookstore that is 5 miles away from the home. At block 715, account application 113 receives one or more parameters 106-2 from contactless card 101. For example, the parameters 106 of contactless card 101 may specify a one-week validity period for any virtual number provisioned using contactless card 101. At block 720, account application 113 may receive one or more parameters 106 from authentication server 120. For example, the parent's account data 124 may specify a parameter 106 that limits the amount of funds for any virtual number provisioned using contactless card 101 to a maximum of $20. Thus, using the parameters received at blocks 705-720, account application 113 receives a parameter 106 that specifies to generate a virtual account number that is limited to $20 for a one-week expenditure at a bookstore that is 5 miles away from the home address associated with the primary account.

[0057] FIG. 8 shows an embodiment of logic flow 800. Logic flow 800 may represent some or all of the operations performed by one or more embodiments described herein. For example, logic flow 800 may include some or all of the operations performed by an applet executed 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, which runs in memory 102 of primary account owner's contactless card 101, receives an identifier of sub-account device 110. The identifier can 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 approved device of the primary account owner. For example, applet 103 may find a matching identifier in memory 102 indicating that the device is approved 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. Applet 103 may further include any parameter 106-2 stored in the memory of contactless card 101. Next, applet 103 may send encrypted data 105, the URL, and / or parameter 106-2 to sub-account owner's computing device 110.

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

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

[0061] At block 915, the authentication application 123 authenticates the encrypted data 105 included as a parameter in the URL. If the encrypted data is encoded, the authentication application 123 may decrypt the encrypted data 105. As described above, to authenticate the encrypted data 105, the authentication application 123 decrypts the encrypted data using the private key 104. At block 920, the authentication application 123 sends an instruction to the VAN generator 142 to approve the generation of the virtual account number, expiration date, and CVV. The authentication application 123 may further provide the parameter 106 to the VAN generator 142 so that the VAN generator 142 can enforce any restrictions (e.g., amount limit, time limit, location limit, merchant limit, etc.) on the virtual account number. The 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 the API of the digital wallet service 150. The VAN generator 142 may further provide instructions for the digital wallet 151 of the sub-account owner, 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 digital wallet 151 of the sub-account owner. Next, the sub-account owner may use the virtual account number via the digital wallet 151 to make payments for transactions.

[0063] FIG. 10 shows an embodiment of an exemplary computing architecture 1000 that includes a computing system 1002 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 that implements one or more components of system 100. In some embodiments, the computing system 1002 may represent, for example, the contactless card 101, computing device 110, authentication server 120, virtual account number server 140, and / or wallet service 150 of system 100. In this context, the embodiments are not limited. More generally, the computing architecture 1000 is configured to implement all of the logic, applications, systems, methods, devices, and functions described herein with reference to FIGS. 1-9.

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

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

[0066] As shown in FIG. 10, the computing system 1002 includes a processor 1004, a system memory 1006, and a system bus 1008. The processor 1004 can be any of a variety of commercially available computer processors including, but not limited to, AMD (R) Athlon (R), Duron (R), and Opteron (R) processors, ARM (R) application, embedded, and security processors, IBM (R) and Motorola (R) DragonBall (R) and PowerPC (R) processors, IBM and Sony (R) Cell processors, Intel (R) Celeron (R), Core (R), Core (2) Duo (R), Itanium (R), Pentium (R), Xeon (R), and XScale (R) processors and similar processors. Dual microprocessors, multi-core processors, and other multiprocessor architectures can also be used as the processor 1004.

[0067] System bus 1008 provides an interface to system components including, but not limited to, processor 1004 from system memory 1006. System bus 1008 can be any of several types of bus structures that can further interconnect, using any of a variety of commercially available bus architectures, to a memory bus (with or without a memory controller), a peripheral bus, and a local bus. Interface adapters can connect to system bus 1008 via a slot architecture. Examples of slot architectures include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and the like.

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

[0069] The computing system 1002 can include various types of computer-readable storage media in the form of one or more low-speed memory units, including an internal (or external) hard disk drive (HDD) 1014, a 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., CD-ROM or DVD). The HDD 1014, FDD 1016, and optical disk drive 1020 can each be connected to the system bus 1008 by an HDD interface 1024, an FDD interface 1026, and an optical drive interface 1028, respectively. The HDD interface 1024 for external drive use can 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, apparatuses, and functions described herein with reference to FIGS. 1-9.

[0070] The drive and associated computer-readable media provide volatile and / or non-volatile storage of data, data structures, computer-readable instructions, computer-executable instructions, etc. For example, a number of program modules can be stored in drive and memory units 1010, 1012, including operating systems 1030, one or more application programs 1032, other program modules 1034, and program data 1036. In one embodiment, one or more application programs 1032, other program modules 1034, and program data 1036 can include, for example, various applications and / or components of system 100, such as applet 103, private key 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 can input commands and information into computing system 1002 via one or more wired / wireless input devices, such as a pointing device like keyboard 1038 and mouse 1040. Other input devices can include a microphone, infrared (IR) remote control, radio frequency (RF) remote control, game pad, stylus pen, card reader, dongle, fingerprint reader, grab, graphic 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 processor 1004 via an input device interface 1042 coupled to system bus 1008, but can be connected by other interfaces such as a parallel port, IEEE 1394 serial port, game port, USB port, IR interface, etc.

[0072] Monitor 1044 or other types of display devices are also connected to the system bus 1008 via an interface such as a video adapter 1046. Monitor 1044 can be inside or outside the computing system 1002. In addition to monitor 1044, the computer typically includes other peripheral output devices such as speakers, printers, etc.

[0073] Computing system 1002 can operate in a network environment using logical connections via wired and / or wireless communication to one or more remote computers such as remote computer 1048. Remote computer 1048 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer device, or other common network node, and typically includes many or all of the elements described in relation to computing system 1002, but for brevity, only memory / storage device 1050 is shown. The logical connections shown include wired / wireless connections to a local area network (LAN) 1052 and / or a larger network, such as a wide area network (WAN) 1054. Such LAN and WAN network environments are common in offices and enterprises and facilitate enterprise-scale computer networks such as intranets. All of these can be connected to a global communication network such as the Internet, for example. In an embodiment, network 130 of FIG. 1 is one or more of LAN 1052 and WAN 1054.

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

[0075] When used in a WAN networking environment, computing system 1002 may include a modem 1058, or be connected to a communication server on WAN 1054, or have other means for establishing communication on WAN 1054, such as via the Internet. Modem 1058 can be internal or external, a wired and / or wireless device, and is connected to system bus 1008 via input device interface 1042. In a network environment, program modules shown with respect to computing system 1002, or portions thereof, may be stored in remote memory / storage device 1050. The network connections shown are illustrative, and it will be understood that other means of establishing a communication link between computers can be used.

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

[0077] FIG. 11A shows a contactless card 101 that may include a payment card such as a credit card, debit card, and / or gift card. As shown, the contactless card 101 may be issued by a service provider 1102 displayed on the front or back of the card 101. In some examples, the contactless card 101 may include an identification card and is not limited thereto, having no relation with the payment card. In some examples, the payment card may include a dual interface contactless payment card. The contactless card 101 may include a substrate 1110 that may include a single layer or one or more laminated layers composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 101 may have physical characteristics conforming 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 the contactless card 101 according to the present disclosure may have different characteristics, and the present disclosure does not require implementing a contactless card for a payment card.

[0078] The contactless card 101 may also include identification information 1115 displayed on the front and / or back of the card, and contact pads 1120. The contact pads 1120 may be configured to establish contact with other communication devices such as a mobile device 110, a user device, a smartphone, a laptop, a desktop, or a tablet computer. The contactless card 101 may also include a processing circuit, an antenna, and other components not shown in FIG. 11A. These components may be disposed behind the contact pads 1120 or at other locations on the substrate 1110. The contactless card 101 may also include a magnetic strip or tape that may be located on the back of the card (not shown in FIG. 11A).

[0079] As shown in FIG. 11B, the contact pad 1120 of the contactless card 101 may include a processing circuit 1125 for storing and processing information, including a microprocessor 1130 and a memory 102. The processing circuit 1125 may include additional components such as a processor, a memory, an error and parity / CRC checker, a data encoder, a collision prevention algorithm, a controller, a command decoder, a security primitive, and anti-tampering hardware, as necessary to perform the functions described herein.

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

[0081] Memory 102 may be configured to store one or more applets 103, a private key 104, encrypted data 105, parameters 106-2, and one or more customer (or user) identifiers (IDs) 1107. The one or more applets 103 may comprise one or more software applications configured to execute on one or more contactless cards, such as Java (registered trademark) card applets. However, it is understood that applet 130 is not limited to Java card applets and may instead be any software application operable on a contactless card or other device having limited memory. Customer ID 1107 may comprise a unique alphanumeric identifier assigned to a user of contactless card 101, which identifier may distinguish the user of the contactless card from other contactless card users. In some examples, customer ID 1107 may identify both a customer and the account assigned to that customer, and may further identify the contactless card associated with the customer's account. In some embodiments, applet 103 may use customer ID 1107 as an input to an encryption algorithm using private key 1108 to generate encrypted data 108.

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

[0083] In some examples, the contactless card 101 may comprise one or more antennas 1155. The one or more antennas 1155 may be disposed within the contactless card 101 and around the processing circuitry 1125 of the contact pad 1120. For example, the one or more antennas 1155 may be integrated with the processing circuitry 1125, and 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 pad 1120 and the processing circuitry 1125.

[0084] In one embodiment, the coil of the contactless card 101 may function as the secondary side 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 a gap in the power connection of the contactless card that may be functionally maintained via one or more capacitors. The contactless card 101 may return communication by switching the load of the coil of the contactless card or load modulation. The load modulation may be detected by the coil of the terminal due to interference. More generally, using the antenna 1155, the processing circuitry 1125, and / or the memory 102, the contactless card 101 provides a communication interface for communicating via NFC, Bluetooth®, and / or Wi-Fi communication.

[0085] As described above, the contactless card 101 may be built on a software platform operable on a memory-constrained smart card such as a Java card or other device, and one or more applications or applets may be securely executed. The applet may be added to the contactless card and may provide one-time passwords (OTP) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet may respond to one or more requests, such as a short-range wireless data exchange request from a reader such as a mobile NFC reader (e.g., the card reader 119 of the device 110), and may be configured to generate an NDEF message with a 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 can include processors, microprocessors, circuits, circuit elements (such as transistors, resistors, capacitors, inductors, etc.), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), logic gates, registers, semiconductor devices, chips, microchips, chip sets, and the like. Examples of software can include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (APIs), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. The determination of whether an embodiment is implemented using hardware elements and / or software elements can vary according to any number of factors such as desired computing 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 can be implemented by representative instructions stored on a machine-readable medium that represents various logic within a processor, which, when read by a machine, causes the machine to fabricate logic for performing 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 onto a manufacturing machine that creates the logic or processor. Some embodiments can be implemented using a machine-readable medium or article that can store, for example, instructions or instruction sets that, when executed by a machine, can cause the machine to perform methods and / or operations according to the embodiments. Such machines can include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and can be implemented using any suitable combination of hardware and / or software. The machine-readable medium or article can 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, writeable or rewritable media, digital or analog media, hard disk, floppy disk, compact disc read only memory (CD-ROM), compact disc recordable (CD-R), compact disc rewritable (CD-RW), optical disc, magnetic media, magneto-optical media, removable memory card or disk, various digital versatile discs (DVD), tape, cassette, etc. The instructions can include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc., and can be implemented using any suitable high-level, low-level, object-oriented, visual, compiled, and / or interpreted programming language.

[0088] The foregoing description of the 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 exact forms disclosed. Many modifications and variations are possible in light of this disclosure. The scope of this disclosure is intended to be limited not by this detailed description, but rather by the claims appended hereto. Future applications claiming the priority of this application may claim the disclosed subject matter in a different manner and may generally include any set of one or more limitations as variously disclosed or demonstrated herein.

Claims

1. The device receives a request to approve a virtual account number of a first account associated with a second account, wherein a card reader of the device receives, from a contactless card, a Uniform Resource Locator (URL) comprising at least one parameter for the virtual account number and encrypted data, and the contactless card is associated with the second account, the device opens an application in response to receiving the URL, the application sends the encrypted data to an authentication server of the URL, the application receives an instruction to specify the authentication server that has decrypted the encrypted data, the application provides the at least one parameter for the virtual account number to the authentication server in response to receiving the instruction to specify the authentication server that has decrypted the encrypted data, the application receives the virtual account number of the first account from a virtual card number server based on the decryption of the encrypted data, wherein the virtual account number is restricted based on the at least one parameter, A method comprising the above.

2. The at least one parameter comprises one or more amount parameters for the virtual account number, location parameters for the virtual account number, time parameters, and merchant parameters. The method according to claim 1.

3. The virtual account number is restricted by an expenditure limit based on the amount parameter, the virtual account number is restricted to one or more locations based on the location parameter, the virtual account number is restricted by a time limit specified by the time parameter, the virtual account number is restricted to one or more merchants specified by the merchant parameter. The method according to claim 2.

4. Further comprising receiving, via the application, additional parameters for the virtual account number, the application provides the additional parameters to the authentication server, the virtual account number is restricted based on the additional parameters. The method according to claim 2.

5. The URL is directed to a page of the application, The device opens the page of the application, The method according to claim 1.

6. The encrypted data is based on a diversified key, The diversified key is based on an identifier of the second account, a counter value, and a key stored in the contactless card, The method according to claim 1.

7. The instruction specifies that the authentication server decrypts the encrypted data based on an instance of the diversified key and the counter value stored by the authentication server, The method according to claim 6.

8. A non-transitory computer-readable storage medium, the computer-readable storage medium includes instructions, and when the instructions are executed by a processor of a device, the processor is caused to Receive a request to approve a virtual account number of a first account associated with a second account; A card reader of the device receives a Uniform Resource Locator (URL) including at least one parameter for the virtual account number and encrypted data from a contactless card, wherein the contactless card is associated with the second account; In response to receiving the URL, open an application; The application transmits the encrypted data to an authentication server of the URL; The application receives an instruction specifying the authentication server that has decrypted the encrypted data; In response to receiving the instruction specifying the authentication server that has decrypted the encrypted data, the application provides the at least one parameter for the virtual account number to the authentication server; The application receives a virtual account number of the first account from a virtual card number server based on the decryption of the encrypted data, wherein the virtual account number is restricted based on the at least one parameter; A computer-readable storage medium that causes the above to be executed.

9. The at least one parameter comprises one or more amount parameters for the virtual account number, location parameters for the virtual account number, time parameters, and merchant parameters. The computer-readable storage medium according to claim 8.

10. The virtual account number is restricted by an expenditure limit based on the amount parameter. The virtual account number is restricted to one or more locations based on the location parameter. The virtual account number is restricted by a time limit specified by the time parameter. The virtual account number is restricted to one or more merchants specified by the merchant parameter. The computer-readable storage medium according to claim 9.

11. The instructions further cause the processor to receive, via the application, additional parameters for the virtual account number, the application provides the additional parameters to the authentication server, the virtual account number is restricted based on the additional parameters. The computer-readable storage medium according to claim 9.

12. The URL is directed to a page of the application, the device opens the page of the application. The computer-readable storage medium according to claim 8.

13. The encrypted data is based on a diversified key, the diversified key is based on an identifier of the second account, a counter value, and a key stored in the contactless card. The computer-readable storage medium according to claim 8.

14. The instruction specifies that the authentication server decrypts the encrypted data based on an instance of the diversified key and the counter value stored by the authentication server. The computer-readable storage medium according to claim 13.

15. A computing device comprising a card reader, a processor, a memory storing instructions, and when the instructions are executed by the processor, the processor receives a request to approve a virtual account number of a first account associated with a second account. ​ The card reader of the device receives a Uniform Resource Locator (URL) from the contactless card, the URL comprising at least one parameter for the virtual account number and encrypted data, the contactless card being associated with the second account, in response to receiving the URL, opening an application; the application sending the encrypted data to an authentication server of the URL; the application receiving an instruction to specify the authentication server that has decrypted the encrypted data; in response to receiving the instruction to specify the authentication server that has decrypted the encrypted data, the application providing the at least one parameter for the virtual account number to the authentication server; the application receiving, from a virtual card number server, a virtual account number of the first account based on the decryption of the encrypted data, the virtual account number being restricted based on the at least one parameter; A computing device that causes the above to be executed.

16. The at least one parameter comprises one or more amount parameters for the virtual account number, location parameters for the virtual account number, time parameters, and merchant parameters. The computing device according to claim 15.

17. The virtual account number is restricted by an expenditure limit based on the amount parameter; The virtual account number is restricted to one or more locations based on the location parameter; The virtual account number is restricted by a time limit specified by the time parameter; The virtual account number is restricted to one or more merchants specified by the merchant parameter. The computing device according to claim 16.

18. The instructions further cause the processor to receive, via the application, additional parameters for the virtual account number; the application providing the additional parameters to the authentication server; the virtual account number being restricted based on the additional parameters. The computing device according to claim 16.

19. The URL is directed to the page of the application, The device opens the page of the application, The computing device according to claim 15.

20. The encrypted data is based on a diversified key, The diversified key is based on the identifier of the second account, a counter value, and the key stored in the contactless card, The computing device according to claim 15.

Images