Tap card for securely generating card data for copying to clipboard

Abstract

The invention relates to a tap card for securely generating card data for copying to a clipboard. The web browser may output a form including payment fields. A URL may be received from a communication interface of a contactless card, the URL including encrypted data generated by the contactless card based on a private key stored in a memory of the contactless card. The application may send the encrypted data to an authentication server, which may decrypt the encrypted data based on the private key. An application may receive a virtual account from a virtual account server. The application may receive the deadline and the CVV. The application may copy the virtual account to a clipboard of the OS. The OS may paste the virtual account from the clipboard to a payment field of the form in the web browser. The OS may output a notification including an expiration date and a CVV associated with the virtual account.

Description

[0001] This application is a divisional application of the application with application number 202080019926.9, application date January 29, 2020, and invention name “Tap card for securely generating card data for copying to clipboard”. Technical Field

[0002] Embodiments herein relate generally to computing platforms, and more particularly to tapping a card to a computing device to securely generate card data that can be copied to a clipboard of the computing device.

[0003] Related Applications

[0004] This application claims priority to U.S. Patent Application Serial No. 16 / 265,937, entitled “TAP CARD TO SECURELY GENERATE CARDDATA TO COPY TO CLIPBOARD,” filed on February 1, 2019. The contents of the above application are incorporated herein by reference in their entirety. Background Art

[0005] Account identifiers for payment cards are typically long strings of numbers and / or characters. As a result, it is difficult for users to correctly manually enter account identifiers. In fact, users often make mistakes and enter incorrect account identifiers into computing interfaces (e.g., payment interfaces). In addition, processes have been developed that allow cameras to capture and recognize account identifiers entered into devices, thereby creating security risks for account identifiers. In addition, some operating systems restrict the ability to access identifiers stored on contactless cards, which prevents conventional attempts to programmatically copy and / or paste account identifiers. Summary of the invention

[0006] Embodiments disclosed herein provide systems, methods, articles, and computer-readable media for tapping a contactless card to securely generate card data to copy to a clipboard. According to one example, a web browser executed on a processor circuit may output a form including a payment field. A uniform resource locator (URL) may be received from a communication interface of the contactless card, the URL including encrypted data generated by the contactless card based at least in part on a private key of the contactless card stored in a memory of the contactless card. An application executed on the processor circuit may transmit the encrypted data to an authentication server, which verifies the encrypted data by decrypting the encrypted data based at least in part on a private key of the contactless card stored in a memory of the authentication server. The application may receive a virtual account number from a virtual account server based on verification of the encrypted data by the authentication server. The application may receive an expiration date associated with the virtual account number and a card verification value (CVV) associated with the virtual account number. The application may copy the virtual account number to a clipboard of an operating system (OS) executed on the processor circuit. The OS may paste the virtual account number from the clipboard to a payment field of a form in the web browser. The OS may output a notification including an expiration date and a CVV associated with the virtual account number. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figures 1A-1C An embodiment of a system for tapping a contactless card to securely generate card data for copying to a clipboard is shown.

[0008] Figures 2A-2D An embodiment is shown of tapping a contactless card to securely generate card data for copying to a clipboard.

[0009] Figures 3A-3D An embodiment is shown of tapping a contactless card to securely generate card data for copying to a clipboard.

[0010] Figure 4 An embodiment of a first logic flow is shown.

[0011] Figure 5 An embodiment of a second logic flow is shown.

[0012] Figure 6 An embodiment of a third logic flow is shown.

[0013] Figure 7 An embodiment of a computing architecture is shown. DETAILED DESCRIPTION

[0014] Embodiments disclosed herein provide security techniques for using a contactless card to generate card data (e.g., account number, expiration date, customer billing address, shipping address, and / or card verification value (CVV)) that can be copied to a clipboard of a computing device. Typically, a contactless card can be brought into the communication range of a computing device, for example, by a tap gesture. Doing so causes the contactless card to generate a uniform resource locator (URL), which is transmitted to the computing device. The URL may include data used by an authentication server as part of a verification process. For example, the URL may include encrypted data decrypted by a server as part of a verification process. As another example, the URL may include a unique identifier associated with the contactless card, which is used by the authentication server as part of a verification process. Once verified, the authentication server may instruct a virtual account server to generate card data for an account associated with the contactless card. The card data may include a virtual account number, expiration date, and CVV. The generated card data may then be transmitted to the computing device. In some embodiments, account holder information (e.g., name, billing address, shipping address, etc.) may also be transmitted to the computing device. The computing device may copy at least one element (e.g., a virtual account number, expiration date, and / or CVV) of the card data and / or account holder information (e.g., name, billing address, and / or shipping address) to a clipboard. Once copied to the clipboard, the data may be copied into corresponding fields of a form in a web browser and / or other application. Additionally, a notification may be output that includes one or more elements of the generated card data and / or account holder information. The notification may allow other elements of the data to be copied to the clipboard, which may then be pasted into a payment field of the form.

[0015] Advantageously, the embodiments disclosed herein improve the security of all devices and related data. For example, some operating systems may restrict access to data stored in contactless cards and / or specific types of data stored in contactless cards. Therefore, traditional techniques for copying and / or automatically filling card data do not work properly. However, advantageously, the embodiments disclosed herein allow for secure generation, transmission, copying and / or automatic filling of card data in any type of operating system. In addition, traditional methods require users to manually enter card data into a form. However, doing so may allow other users or devices to capture card data when the user enters the card data into the form. By eliminating the need for users to manually enter card data into a form, the security of card data is enhanced. In addition, the verification performed by the server provides additional protection to ensure that the correct card data is entered into the form. In addition, the generation and filling of virtual card numbers into the form protects the security of the actual account number of the contactless card, because traditional solutions require the actual account number of the contactless card to be provided in the form.

[0016] Generally with reference to the symbols and nomenclature used in this article, one or more parts of the following detailed description can be presented according to the program process executed on a computer or a network of computers. These program descriptions and representations are used by those skilled in the art to most effectively convey the essence of their work to other technicians in the field. The program is here and is generally considered to be a self-consistent sequence of operations that leads to the desired result. These operations are those operations that require physical manipulation of physical quantities. Usually, although not necessarily, these quantities take the form of electrical, magnetic or optical signals that can be stored, transmitted, combined, compared and otherwise manipulated. Mainly for general reasons, it is sometimes proven to be convenient to refer to these signals as bits, values, elements, symbols, characters, items, numbers, etc. However, it should be noted that all of these and similar terms are associated with appropriate physical quantities and are merely convenient labels applied to these quantities.

[0017] In addition, these manipulations are often referred to as terms such as addition or comparison, which are often associated with mental operations performed by human operators. However, in any of the operations described herein that form a part of one or more embodiments, this ability of a human operator is not necessary, or is not desirable in most cases. Instead, these operations are machine operations. Useful machines for performing the operations of various embodiments include digital computers selectively activated or configured by computer programs stored therein, written according to the teachings of this article, and / or include devices or digital computers specially constructed for the desired purpose. Various embodiments also relate to devices or systems for performing these operations. These devices can be specially constructed for the desired purpose. From the description given, the required structures of various these machines will be apparent.

[0018] Reference is now made to the accompanying drawings, in which the same reference numerals are used to refer to the same elements throughout. In the following description, for the purpose of explanation, many specific details are set forth in order to provide a thorough understanding thereof. However, it is apparent that novel embodiments can be practiced without these specific details. In other cases, well-known structures and devices are shown in block diagram form in order to describe them. It is intended to cover all modifications, equivalents, and alternatives within the scope of the claims.

[0019] Figure 1AA schematic diagram of an exemplary system 100 consistent with the disclosed embodiments is depicted. As shown, the system 100 includes one or more contactless cards 101, one or more mobile devices 110, an authentication server 120, and a virtual account server 140. The contactless card 101 represents any type of payment card, such as a credit card, a debit card, an ATM card, a gift card, etc. The contactless card 101 may include one or more communication interfaces 150, such as a radio frequency identification (RFID) chip, which is configured to communicate with the mobile device 110 via NFC, the EMV standard, or other short-range protocols in wireless communication. Although NFC is used as an example communication protocol, the present disclosure is equally applicable to other types of wireless communications, such as the EMV standard, Bluetooth, and / or Wi-Fi. The mobile device 110 represents any type of network-enabled computing device, such as a smartphone, a tablet, a wearable device, a laptop, a portable gaming device, etc. The servers 120, 140 represent any type of computing device, such as a server, a workstation, a computing cluster, a cloud computing platform, a virtualized computing system, etc.

[0020] As shown, the memory 111 of the mobile device 110 includes an instance of an operating system (OS) 112. The example operating system 112 includes OS, and Operating system. As shown, OS112 includes account application 113, clipboard 114 and web browser 115. Account application 113 allows users to perform various account-related operations, such as viewing account balances, purchasing items and / or processing payments. In some embodiments, users must authenticate using authentication credentials to access account application 113. For example, authentication credentials may include a username and password, biometric credentials, etc. In some embodiments, authentication server 120 may provide the required authentication as described in more detail below. Web browser 115 is an application that allows mobile device 110 to access information via network 130 (e.g., via the Internet). For example, a user can use web browser 115 to make a purchase from a merchant's website. Web browser 115 is an example of an application for accessing information (e.g., making a purchase) via network 130. The use of a web browser as a reference example here should not be considered a limitation of the present disclosure, as the present disclosure is equally applicable to other types of applications for accessing information via a network, such as applications provided by merchants that allow users to make purchases.

[0021] When using a web browser 115 (or another application), a user may encounter a form that includes one or more payment fields. Traditionally, users are required to manually enter their card number, expiration date, and / or CVV. Some mobile operating systems allow such data to be automatically filled into forms, but other mobile operating systems impose restrictions on automatically filling such data. Advantageously, embodiments disclosed herein address such issues by utilizing a contactless card 101 to trigger the generation of a virtual account number, expiration date, and / or CVV that can be copied to the clipboard 114 of the OS 112.

[0022] More specifically, the user can tap the contactless card 101 against the mobile device 110 so that the contactless card 101 is sufficiently close to the card reader 118 of the mobile device 110 to achieve NFC data transmission between the communication interface 150 of the contactless card 101 and the card reader 118 of the mobile device 110. In some embodiments, the mobile device 110 can trigger the card reader 118 through an application program interface (API) call. In one example, the mobile device 110 triggers the card reader via an API call in response to the user tapping or otherwise selecting an element of a user interface (e.g., a form field). In addition and / or alternatively, the mobile device 110 can trigger the card reader 118 based on periodic polling of the card reader 118. More generally, the mobile device 110 can use any feasible method to trigger the card reader 118 to communicate. After communication is established between the mobile device 110 and the contactless card 101, the contactless card 101 generates a message authentication code (MAC) password. In some examples, this may occur when the account application 113 reads the contactless card 101. In particular, this may occur when reading (eg, NFC reading) a Near Field Data Exchange (NDEF) tag, which may have been created according to the NFC data exchange format.

[0023] More generally, the applet 103 executed on the processor (not shown) of the contactless card 101 generates data and sends the data to the mobile device 110 via the communication interface 150. In some embodiments, the data generated by the contactless card 101 may include a URL. The URL may point to the authentication server 120, or some other URL associated with the entity that issued the contactless card 101. The URL may also be a universal link URL that opens a local resource (e.g., a page of the account application 113). The URL may also include data (e.g., parameters) used by the authentication server 120 to verify the data generated by the contactless card 101.

[0024] For example, the applet 103 of the contactless card 101 can use a cryptographic algorithm to generate a cryptographic payload based at least in part on a private key 104 stored in the memory 102 of the contactless card 101. In general, the applet 103 can use any type of cryptographic algorithm and / or system to generate a cryptographic payload, and the use of a specific cryptographic algorithm as an example here should not be considered a limitation of the present disclosure. The cryptographic algorithm may include an encryption algorithm, a hash-based message authentication code (HMAC) algorithm, a password-based message authentication code (CMAC) algorithm, and the like. Non-limiting examples of cryptographic 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. In some embodiments, the applet 103 can perform encryption using key diversification techniques to generate a cryptographic payload. Examples of key diversification techniques are described in U.S. patent application 16 / 205,119 filed on November 29, 2018. The above-mentioned patent application is incorporated herein by reference in its entirety. The applet 103 of the contactless card 101 may include the cryptographic payload as a parameter of the URL.

[0025] As another example, the applet 103 of the contactless card 101 may include some other string in the URL for identifying the contactless card 101. For example, the URL may include a subset of the digits (or characters) of the account number associated with the contactless card 101. For example, if the account number is 16 digits, the applet 103 of the contactless card 101 may include 4 digits of the account number as parameters of the URL. The account number may be any type of account number, such as a primary account number (PAN), a one-time use virtual account number, and / or a token generated based on the PAN.

[0026] The applet 103 can then send the generated data to the mobile device 110, and the mobile device 110 can send the received data to the authentication server 120. The authentication application 123 can then authenticate the received data. For example, if the URL includes a password payload, the authentication application 123 can decrypt the password payload using a copy of the private key 104 stored in the memory 122 of the server 120. The private key 104 can be the same as the private key 104 stored in the memory 102 of the contactless card 101, wherein each contactless card 101 is manufactured to include a unique private key 104 (and the server 120 stores a corresponding copy of each unique private key 104). Therefore, the authentication application 123 can successfully decrypt the password payload, thereby verifying the payload. As another example, the authentication application 123 can confirm that the digits of the account number match the digits of the account number associated with the contactless card 101 stored in the account data 124, thereby verifying the account number.

[0027] Regardless of the authentication technology used by the authentication application 123, once authenticated, the authentication application 123 can instruct the virtual account number (VAN) generator 142 in the memory 141 of the virtual account server 140 to generate a virtual account number, expiration date, and CVV for the account associated with the contactless card 101. In at least one embodiment, the virtual account number generated by the VAN generator 142 is limited to a specific merchant or merchant group. The virtual account number may also include other restrictions (e.g., time restrictions, location restrictions, amount restrictions, etc.). Once generated, the VAN generator 142 may provide the virtual account number, expiration date, and CVV to the mobile device 110 and / or the authentication server 120. The VAN generator 142 and / or the authentication server 120 may also provide the mobile device 110 with the account holder name, billing address, and / or shipping address. However, in some embodiments, the account holder name, billing address, and / or shipping address are stored locally by the mobile device 110. VAN generator 142 and / or authentication server 120 may provide data to mobile device 110 by any suitable method, such as push notification via web browser 115, text message, email, etc.

[0028] Once received by the mobile device 110, the virtual account number, expiration date, CVV, account holder name, billing address, and / or shipping address may be copied to the clipboard 114 of the OS 112. Doing so allows the user to paste the copied data into the corresponding fields in the web browser 115. For example, the user may paste the account number into the account number field of a form in the web browser 115. In some embodiments, a notification including the expiration date and CVV may be output on the mobile device 110. The notification may also include the account holder name, billing address, and / or shipping address. The notification may be output after a certain predefined amount of time (e.g., 5 seconds after the virtual account number is copied to the clipboard 114). The notification may allow the user to directly copy the account holder name, billing address, shipping address, expiration date, and / or CVV to the clipboard 114 to paste into the corresponding fields of the form in the web browser 115.

[0029] Typically, the clipboard 114 stores data that can be copied and / or pasted within the OS 112. For example, the clipboard 114 can locally store data for pasting into a field of the mobile device 110, and the user can use commands and / or gestures available within the OS 112 to enter / paste the data stored in the clipboard 114. For example, copying an account number to the clipboard 114 allows the user to paste the account number into the corresponding form field using commands and / or gestures available within the OS 112. In addition, the account application 113 can output a notification specifying the expiration date and CVV while the account number is copied to the clipboard 114. Doing so allows the user to manually enter the expiration date and CVV into the corresponding form field while the notification remains visible. In some embodiments, the account application 113 and / or the OS 112 can also copy the expiration date, billing address, and / or CVV to the clipboard 114, thereby allowing the expiration date, billing address, and / or CVV to be pasted into the corresponding form field.

[0030] Figure 1BAn embodiment is depicted in which the applet 103 of the contactless card 101 generates a cryptographic payload for verification by the authentication application 123. As described, when a user may encounter a payment form in a web browser 115. In response, the OS 112 and / or the account application 113 may output a notification to the mobile device 110 indicating that the user tapped the contactless card 101. In some embodiments, the user may select a form field associated with payment (e.g., an account number field, an expiration date field, and / or a CVV field), which brings focus to the form field. In such an embodiment, the OS 112 and / or the account application 113 may output a notification to the mobile device 110 of tapping the contactless card 101 when determining that the payment field has received focus. As another example, the OS 112 and / or the account application 113 may determine that the form includes one or more payment fields. For example, in some embodiments, the account application 113 and / or the OS 112 reads the metadata of the form field to determine the type of information. For example, the metadata of the form field may specify that the form field is associated with an account number field, an expiration date field, a CVV field, a shipping address field, and / or a billing address field. In some embodiments, information such as the 16-digit card number, CVV, and customer name may be available offline, while other information such as the address and generated virtual number may not be available offline and may require a network connection. In response, the account application 113 and / or OS 112 may output a notification to the mobile device 110 to tap the contactless card 101. Thus, the account application 113 and / or OS 112 may output a notification to the mobile device 110 to tap the contactless card 101 based on automatically determining that the form includes one or more payment fields and / or based on determining that a payment field has received focus.

[0031] Once tapped, the applet 103 of the contactless card 101 can generate encrypted data 105 based on the private key 104. In one embodiment, once the contactless card 101 is tapped against the mobile device 110, the contactless card 101 generates the encrypted data 105 and transmits the encrypted data 105 to the mobile device 110. In another embodiment, once the contactless card 101 is tapped against the mobile device 110, the account application 113 can instruct the contactless card 101 to generate the encrypted data 105 and transmit it to the mobile device 110. In some embodiments, the encrypted data 105 can be a string of characters, such as "A1B2C3Z". The applet 103 can also determine the URL 106. The URL 106 can point to the authentication server 120. In some embodiments, the applet 103 dynamically generates the URL 106. In other embodiments, the applet 103 dynamically selects the URL 106, which is one of a plurality of URLs 106 stored in the memory 102. In some embodiments, the URL 106 is a universal link that opens one or more pages of the account application 113. Applet 103 may include generated encrypted data 105 as a parameter of URL 106, thereby generating a URL with encrypted data 108. For example, URL 106 may be "http: / / www.example.com / ." Thus, the URL with encrypted data 108 may be "http: / / www.example.com / ?A1B2C3Z."

[0032] In some embodiments, before including the encrypted data 105 as a parameter of the URL 106, the applet 103 can encode the encrypted data 105 according to an encoding format compatible with the URL. For example, the encrypted data 105 can be a string of binary data (e.g., zeros and ones) that may not be compatible with the URL. Therefore, the applet 103 can encode the encrypted data 105 into the American Standard Code for Information Interchange (ASCII) base64 encoding format. Doing so allows the binary encrypted data 105 in the ASCII string format to be represented by converting the binary encrypted data 105 to a base 64 representation (e.g., "ABC123Z" in the previous example).

[0033] The contactless card 101 may then send the URL with the encrypted data 108 to the mobile device 110. The account application 113 may then be opened to a corresponding page, where the account application 113 extracts the encrypted data 105 from the URL with the encrypted data 108. In some embodiments, if the user is not logged into the account application 113, the account application 113 opens a login page where the user provides credentials for logging into the account before extracting the encrypted data 105. The account application 113 may then send the encrypted data 105 to the authentication server 120 via the network 130. In one embodiment, the account application 113 transmits the encrypted data to the URL 106 generated by the contactless card 101. In other embodiments, as described in more detail below, the URL with the encrypted data 108 causes the web browser 115 to open a new tab and follow the URL with the encrypted data 108. In such embodiments, the URL with the encrypted data 108 leads to the authentication application 123, which can extract the encrypted data 105 from the URL with the encrypted data 108.

[0034] Once received, the authentication application 123 may then attempt to decrypt the encrypted data 105 using the private key 104 associated with the contactless card 101. As described, in some embodiments, the encrypted data 105 is encoded by the applet 103. In such embodiments, the authentication application 123 may decode the encrypted data 105 before attempting to decrypt. If the authentication application 123 is unable to decrypt the encrypted data to produce the expected result (e.g., a customer identifier of an account associated with the contactless card 101, etc.), the authentication application 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 is able to decrypt the encrypted data to produce the expected result (e.g., a customer identifier of an account associated with the contactless card 101, etc.), the authentication application verifies the encrypted data 105 and instructs the VAN generator 142 to generate a virtual account number, an expiration date, and a CVV value. As shown, the VAN generator 142 generates a virtual number 125, which includes the virtual account number, the expiration date, and the CVV value.

[0035] The virtual number 125 may then be sent via the network to the mobile device 110. Once received, the account application 113 provides one or more elements of the virtual number 125 to the clipboard 114 of the OS 112. For example, the account application 113 may extract the virtual account number from the virtual number 125 and provide the extracted virtual account number to the clipboard 114, thereby copying the virtual account number to the clipboard 114. Doing so allows the user to return to the web browser 115 and paste the virtual account number from the clipboard into an account number field of a form in the web browser 115.

[0036] Figure 1CAn embodiment is depicted in which the applet 103 of the contactless card 101 generates an identifier for verification by the authentication application 123. As described, when a user may encounter a payment form in a web browser 115. In response, the OS 112 and / or the account application 113 may output a notification to the mobile device 110 indicating that the user tapped the contactless card 101. In some embodiments, the user may select a form field associated with payment (e.g., an account number field, an expiration date field, and / or a CVV field), which brings focus to the form field. In such an embodiment, the OS 112 and / or the account application 113 may output a notification to the mobile device 110 to tap the contactless card 101 when it is determined that the payment field has received focus.

[0037] In response to the tap, the contactless card applet 103 determines an identifier to include as a parameter of the URL 106. In one embodiment, the applet 103 selects a predefined number of characters of the account identifier 107 associated with the contactless card 101. For example, the applet 103 may select the last 4 digits of the account ID 107 and append the selected digits to the URL 106, thereby generating a URL with the account ID 109. As described, the URL 106 may be a generic link that opens one or more predefined pages of the account application 113.

[0038] The contactless card 101 may then send a URL with the account ID 109 to the mobile device 110. The account application 113 may then be opened to a corresponding page, where the account application 113 extracts the digits of the account ID 107 from the URL with the account ID 109. In some embodiments, if the user is not logged into the account application 113, the account application 113 opens a login page where the user provides credentials for logging into the account before extracting the encrypted data 105. The account application 113 may then send the digits of the account ID 107 to the authentication server 120 over the network 130. The authentication application 123 may then verify the account ID 107. For example, the authentication application 123 may determine whether the digits of the account ID 107 match corresponding digits of an account identifier of an account associated with the contactless card 101 in the account data 124. In such an embodiment, the account application 113 may provide data (e.g., an account token, a username associated with the account currently logged into the account application 113, etc.) to allow the authentication application 123 to verify the account ID 107 associated with the account in the account data 124.

[0039] If authentication application 123 verifies account ID 107, authentication application 123 instructs VAN generator 142 to generate a virtual account number. Otherwise, no virtual account number is generated in response to the tap of contactless card 101. In one embodiment, if authentication application 123 is able to verify the account, authentication application 123 can log account application 113 into the corresponding account without user input.

[0040] As shown, after the authentication application 123 verifies the account ID 107, the VAN generator 142 generates a virtual number 126 including a virtual account number, an expiration date, and a CVV value. The virtual number 126 can then be sent to the mobile device 110 via the network. Once received, the account application 113 provides one or more elements of the virtual number 126 to the clipboard 114 of the OS 112. For example, the account application 113 can extract the virtual account number from the virtual number 126 and provide the extracted virtual account number to the clipboard 114, thereby copying the virtual account number to the clipboard 114. Doing so allows the user to return to the web browser 115 and paste the virtual account number from the clipboard to the account field of the form in the web browser 115. The expiration date and / or CVV can similarly be extracted by the account application 113 and provided to the clipboard 114. Doing so allows the expiration date and / or CVV to be pasted from the clipboard 114 to the corresponding fields in the form of the web browser 115.

[0041] As described, the VAN generator 142 and / or the authentication server 120 may also provide the account holder name, billing address, and / or shipping address to the mobile device 110. However, in some embodiments, the account holder name, shipping address, and / or billing address are stored locally by the account application 113 and / or the mobile device 110. Therefore, in such embodiments, the account application 113 may provide the account holder name, billing address, and / or shipping address to the clipboard 114. Doing so allows the user to paste the account holder name, shipping address, and / or billing address from the clipboard into the account number field of the form in the web browser 115.

[0042] Figure 2A2 is a schematic diagram 200 depicting an example embodiment of tapping a contactless card 101 to generate a virtual account number and copy the virtual account number to a clipboard 114. As shown, a web browser 115 outputs a form (e.g., a payment form) including form fields 201-203, wherein field 201 corresponds to an account number field, field 202 corresponds to an expiration date field, and field 203 corresponds to a CVV field. As shown, when the account number field 201 receives focus (e.g., is selected by a user), the OS 112 and / or the account application 113 outputs a notification 204. The notification 204 instructs the user to tap the contactless card 101 to the mobile device 110. In one embodiment, the user selects the notification 204 before tapping the contactless card 101 to the mobile device 110.

[0043] As described, once the contactless card 101 is tapped against the mobile device 110, the account application 113 sends an indication of the contactless card 101 through the card reader 118 (e.g., through NFC, Bluetooth, RFID and / or EMV protocols, etc.). The indication can specify the generation of a URL with encrypted data. As described, the applet 103 can generate a URL with encrypted data using the private key 104 of the contactless card. The applet 103 can then generate a URL with the encrypted data as a parameter of the URL and send the URL with the encrypted data to the mobile device 110. Once received, the URL with the encrypted data can cause the page of the account application 113 to open.

[0044] Figure 2B 210 is a schematic diagram depicting an embodiment in which an account application 113 is opened in response to receiving a URL with encrypted data from a contactless card 101. As shown, the account application 113 requires the user to provide a fingerprint to log in to their account. In other embodiments, the user can use FaceID, other biometric identifiers, username / password or any other type of credentials to log in to the account. In some embodiments, the user is not required to log in. Once the user logs in to the account, the account application 113 transmits the encrypted data to the authentication application 123. Once verified (e.g., decrypted), the authentication application 123 causes the VAN generator 142 to generate a virtual account number, expiration date and CVV associated with the contactless card 101. The VAN generator 142 can then send the virtual account number, expiration date and CVV to the mobile device 110. As shown, once received, the account application 113 copies the virtual account number to the clipboard 114 of the OS. In one embodiment, the account application 113 copies the virtual account number to the clipboard 114 based on the determination that the account field has focus. The account application 113 may then generate and output a link 205 (or other graphical object) that allows the user to return to the previous application (eg, web browser 115 ).

[0045] Figure 2C 200 is a diagram depicting an embodiment in which the user has selected link 205 to return to web browser 115. As shown, notification 206 may allow the user to paste the virtual account number into form field 201 (e.g., after the user long-presses form field 201). Once selected, OS 112 may cause the virtual card number to be pasted from clipboard 114 into form field 201. Figure 2D 230 is a schematic diagram depicting an embodiment in which a virtual account number has been pasted into form field 201. As shown, OS 112 and / or account application 113 may output notification 207. Notification 207 includes an expiration date and CVV associated with the virtual account number received from VAN generator 142. As shown, notification 207 includes link 208, which, when selected, copies the expiration date to clipboard 114. Similarly, notification 207 includes link 209, which, when selected, copies the CVV to clipboard 114. Other graphical objects may be used in place of links. In some embodiments, the output of notification 207 is timed to facilitate easy copying / pasting of expiration dates and CVVs. For example, account application 113 may start a timer in response to receiving the virtual account number, expiration date, and CVV from VAN generator 142. As another example, account application 113 may start a timer when the user selects link 205 to return to web browser 115. Once the timer exceeds a predefined time threshold (e.g., 5 seconds, 10 seconds, etc.), a notification 207 is generated and output. This allows the user time to paste the account number into the form field 201 without being distracted by the notification 207, while providing the notification 207 in a timely manner to facilitate copying and / or pasting of the expiration date and / or CVV.

[0046] Figure 3A 300 is a schematic diagram depicting an example embodiment of tapping a contactless card 101 to generate a virtual account number and copy the virtual account number to a clipboard 114. As shown, a web browser 115 has loaded a website from a URL 305. The website includes a form (e.g., a payment form) with form fields 301-303 and may be in a first tab of the web browser 115. Field 301 corresponds to an account number field, field 302 corresponds to an expiration date field, and field 303 corresponds to a CVV field. As shown, when the account number field 301 receives focus (e.g., is selected by a user), the OS 112 and / or the account application 113 outputs a notification 304. The notification 304 instructs the user to tap the contactless card 101 to the mobile device 110. In one embodiment, the user selects the notification 304 before tapping the contactless card 101 to the mobile device 110.

[0047] To determine that a field has received focus, account application 113 and / or OS 112 may analyze a hypertext markup language (HTML) attribute of account field 301 to determine that account field 301 has received focus. Additionally, account application 113 and / or OS 112 may analyze metadata of account field 301 to determine that field 301 is associated with an account. For example, account application 113 and / or OS 112 may determine based on the metadata that account field 301 is configured to receive 16 characters as input. As another example, the metadata may specify a name for form field 301 that is similar to a name associated with an account field (e.g., "accountnumber," "account_number," etc.).

[0048] As described, once the contactless card 101 is tapped against the mobile device 110, the account application 113 sends an instruction to the contactless card 101 through the card reader 118 (e.g., through NFC, Bluetooth, RFID and / or EMV protocols, etc.). The instruction can specify the generation of a URL with encrypted data. However, in some embodiments, the contactless card 101 causes the applet 103 to generate a URL with encrypted data without instructions received from the mobile device 110. As described, the applet 103 can use the private key 104 of the contactless card 101 to generate a URL with encrypted data. Figure 3A In the example shown, applet 103 can use private key 104 to generate an example encrypted string "ABCD123XYZ". Applet 103 can then generate a URL to authentication application 123, where the URL includes the encrypted data as a parameter of the URL. Figure 3A In the example shown, the URL with the encrypted data may be “https: / / / www.example.com / auth.html?ABCD123XYZ.” The applet 103 may then send the URL with the encrypted data to the mobile device 110 .

[0049] Figure 3B310 is a schematic diagram showing an embodiment in which a new tab of a web browser 115 is opened in response to receiving a URL with encrypted data from a contactless card 101. As shown, the URL 306 of the web browser points to a URL with encrypted data generated by the applet 103, namely "https: / / / www.example.com / auth.html?ABCD123XYZ". The authentication application 123 can decrypt the encrypted data using the private key 104 to verify the encrypted data. The authentication application 123 can then instruct the VAN generator 142 to generate a virtual account number, an expiration date, and a CVV. However, in some embodiments, the VAN generator 142 generates a virtual account number and selects an existing expiration date and / or CVV (e.g., from the account data 124). In some such examples, the existing expiration date and / or CVV can be the expiration date and / or CVV of the contactless card 101 or another card associated with the account in the account data 124.

[0050] like Figure 3B As shown, the tab of the web browser 115 includes the virtual account number, expiration date, and CVV. In one embodiment, the VAN generator 142 provides the generated data to the authentication application 123. Doing so allows the authentication application 123 to output the data in the web browser 115. Other techniques can be used to redirect the web browser 115 to the VAN generator 142, which can output the virtual account number, expiration date, and CVV in the web browser 115. As shown, the web browser 115 includes a notification to the user that once the user copies / pastes the virtual account number, expiration date, and CVV, the tab of the web browser 115 is closed.

[0051] Figure 3C 3 is a schematic diagram 320 depicting an embodiment in which the VAN generator 142 and / or the authentication application 123 sends a push notification 307 to a mobile device including a virtual account number, expiration date, and CVV generated by the VAN generator 142. The virtual account number, expiration date, and CVV may be generated based on any of the techniques described herein. In one embodiment, instead of (or in addition to) Figure 3B115 in the web browser 115, and generates a notification 307. As shown, the notification 307 includes the virtual account number, the expiration date, and the CVV. As shown, the notification 307 includes a link 308, which, when selected, copies the virtual account number to the clipboard 114. Similarly, the notification 307 includes a link 309, which, when selected, copies the expiration date to the clipboard 114. Similarly, the notification 307 includes a link 321, which, when selected, copies the CVV to the clipboard 114. Other graphical objects can be used instead of links. In some embodiments, the output of the notification 307 is timed to facilitate easy copying / pasting of the expiration date and CVV, for example, when the timer expires as described above.

[0052] Figure 3D 330 is a diagram illustrating an embodiment in which the VAN generator 142 and / or the authentication application 123 sends a text message notification 311 to a mobile device (including a virtual account number, expiration date, and CVV generated by the VAN generator 142). The virtual account number, expiration date, and CVV may be generated based on any of the techniques described herein. In one embodiment, instead of (or in addition to) Figure 3B The virtual account number, expiration date and CVV are outputted in the web browser 115 in the text message notification 311, and a text message notification 311 is generated. As shown in the figure, the text message notification 311 includes the virtual account number, the expiration date and the CVV. As shown in the figure, the text message notification 311 includes a link 313, which, when selected, copies the virtual account number to the clipboard 114. Similarly, the text message notification 311 includes a link 314, which, when selected, copies the expiration date to the clipboard 114. Similarly, the text message notification 311 includes a link 315, which, when selected, copies the CVV to the clipboard 114. Other image objects can be used instead of links. In addition, as shown in the figure, the text message 311 includes an auto-fill link 312, which, when selected, automatically fills the virtual account number, expiration date and CVV into the format fields 301-303 respectively. In at least one embodiment, the auto-fill service (not shown) of the OS automatically fills the account number, expiration date and CVV into the form fields 301-303. In some embodiments, the autofill service detects form fields (e.g., form fields 301-303), detects content in a notification (e.g., notification 311) whose type matches the type of the detected form field, and provides the content parsed from the notification as an autofill suggestion in the keyboard. Doing so allows the autofill service to automatically fill data from the notification into the corresponding form field.

[0053] Despite Figures 2A-2D3A-3D, but the account holder name, billing address, and / or shipping address can be copied to clipboard 114 and pasted into corresponding form fields in the web browser. As described, the name, billing address, and / or shipping address can be stored locally on mobile device 110 and / or received from VAN generator 142 and / or authentication server 120.

[0054] Figure 4 An embodiment of a logic flow 400 is shown. The logic flow 400 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 400 may include some or all of the operations of generating a virtual account number using a contactless card and copying the virtual account number to the clipboard 114. The embodiments are not limited in this context.

[0055] As shown, logic flow 400 begins at box 405, where account application 113 and / or OS112 determine that the payment field of the form has received focus. The form can be in a web browser 115, account application 113 and / or different applications. For example, a user can tap the payment field of the form to give the payment field focus. As another example, a user can use a mouse and / or keyboard to select the payment field of the form. More generally, any technology can be used to give the payment field focus, including programmatically generated focus. For example, the payment field can receive focus based on the HTML "focus()" method. As another example, when a form is loaded, for example, based on the "autofocus" HTML attribute applied to the payment field in the source code, the payment field can automatically receive focus. The payment field can include one or more of a name field, an account number field, a deadline field, a shipping address field, a billing address field and / or a CVV field. Once the payment field receives focus, account application 113 and / or OS112 can output a notification designated to the user to tap the contactless card 101 on the mobile device 110. In some embodiments, a notification may be generated based on determining that a form contains one or more payment fields and does not require determining that a form field has received focus. The notification may include a GUI that provides an example of how to tap the contactless card 101 to the mobile device 110. At block 410, the user taps the contactless card 101 to the mobile device to cause the contactless card 101 to generate and transmit encrypted data as part of a URL. The account application 113 may send an instruction to the contactless card 101 via the NFC reader 118, specifying the generation and transmission of encrypted data as part of a URL.

[0056] At box 415, the small application 103 of contactless card generates encrypted data using private key 104 and cryptographic algorithm. The small application 103 can then include encrypted data as a parameter of URL. The URL can be a universal link URL, which at least partially causes the predefined page of account application 113 to be opened when being concerned. At box 420, the small application 103 can send the URL including encrypted data to mobile device 110. At box 425, account application 113 is opened to the page corresponding to the universal link URL received from contactless card 101. In some embodiments, account application 113 can require users to log in to their accounts (if not yet logged in). In some such embodiments, URL can point to an external authentication website, which is configured to receive the credentials required for users to log in to their accounts. As another example, URL can point to the authentication page of account application 113, which receives the credentials required for users to log in to their accounts.

[0057] At box 430, the account application 113 extracts the encrypted data from the URL and sends the encrypted data to the authentication application 123 of the authentication server 120 for verification. If the encrypted data is encoded, the account application 113 and / or the authentication application 123 can decode the encrypted data. At box 435, the authentication application 123 decrypts the encrypted data using the private key in the memory of the server 120 to verify the encrypted data. At box 440, the authentication application 123 sends an instruction to the VAN generator 142 specifying the generation of a virtual account number, an expiration date, and a CVV. The authentication application 123 can also specify one or more restrictions on the virtual account number (e.g., must be used within 1 hour, can only be used on the website of a specified merchant, etc.). At box 445, the VAN generator 142 generates a virtual account number, an expiration date, and a CVV. At box 450, the VAN generator 142 sends the virtual account number, the expiration date, and the CVV to the mobile device 110. VAN generator 142 may also send the account holder name, billing address, and / or shipping address (which may be received by VAN generator 142 from authentication server 120) to mobile device 110. For example, VAN generator 142 may generate a push notification, text message, or one or more data packets that account application 113 processes to receive the virtual account number, expiration date, and CVV.

[0058] At box 455, the account application 113 copies the virtual account number to the clipboard 114 of the OS. The account application 113 may also start a timer. At box 460, the user may return to the web browser 115 and paste the virtual account number stored in the clipboard 114 into the payment field of the form. At box 465, the account application 113 outputs a notification specifying the account holder name, billing address, shipping address, expiration date, and / or CVV after the timer set at box 455 has elapsed (or exceeds a threshold amount of time). Doing so allows the user to copy and paste the account holder name, billing address, shipping address, expiration date, and / or CVV into the corresponding fields of the form.

[0059] Figure 5 An embodiment of a logic flow 500 is shown. The logic flow 500 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 500 may include some or all of the operations of generating a virtual account number using a contactless card and copying the virtual account number to the clipboard 114. The embodiments are not limited in this context.

[0060] As shown, the logic flow 500 starts at box 505, where the account application 113 and / or OS112 determines that the payment field of the form has received focus. The form can be in a web browser 115, an account application 113, and / or a different application. For example, a user can tap the payment field of the form to give the payment field focus. As another example, a user can use a mouse and / or keyboard to select the payment field of the form. More generally, any technology can be used to give the payment field focus, including programmatically generated focus. For example, the payment field can receive focus based on the HTML "focus()" method. As another example, when the form is loaded, for example, based on the "autofocus" HTML attribute applied to the payment field in the source code, the payment field can automatically receive focus. The payment field can include one or more of a name field, an account number field, an expiration date field, a shipping address field, a billing address field, and / or a CVV field. Once the payment field receives focus, the account application 113 and / or OS112 can output a notification designated to the user to tap the contactless card 101 on the mobile device 110. In some embodiments, a notification can be generated based on determining that the form contains one or more payment fields. The notification may include a GUI depicting an example of how to tap the contactless card 101 against the mobile device 110. At block 510, the user taps the contactless card 101 against the mobile device to cause the contactless card 101 to generate and transmit data as part of a URL. The account application 113 may send an instruction to the contactless card 101 via the NFC reader 118 specifying the generation and transmission of data as part of a URL.

[0061] At box 515, the contactless card applet 103 generates a URL that includes the account identifier as a parameter of the URL (or a portion thereof). The URL may be a universal link URL that causes, at least in part, a predefined page of the account application 113 to be opened when focused. At box 520, the applet 103 may send the URL including the account identifier to the mobile device 110. At box 525, the account application 113 is opened to a page corresponding to the universal link URL received from the contactless card 101. In some embodiments, the account application 113 may require the user to log in to their account (if not already logged in).

[0062] At box 530, the account application 113 extracts the account identifier from the URL and sends the account identifier to the authentication application 123 of the authentication server 120 for verification. At box 535, the authentication application 123 verifies the account identifier (e.g., by determining whether the received account identifier matches the expected and / or known account identifier value). At box 540, the authentication application 123 sends an instruction to the VAN generator 142 specifying the generation of a virtual account number, an expiration date, and a CVV. The authentication application 123 may also specify one or more restrictions on the virtual account number (e.g., must be used within 1 hour, can only be used on the website of a specified merchant, etc.). At box 545, the VAN generator 142 generates the virtual account number, the expiration date, and the CVV. At box 550, the VAN generator 142 sends the virtual account number, the expiration date, and the CVV to the mobile device 110. The VAN generator 142 may also send the account holder name, billing address, and / or shipping address (which may be received by the VAN generator 142 from the authentication server 120) to the mobile device 110. For example, VAN generator 142 may generate a push notification, text message, or one or more data packets that account application 113 processes to receive the virtual account number, expiration date, and CVV.

[0063] At box 555, the account application 113 copies the virtual account number to the clipboard 114 of the OS. The account application 113 may also start a timer. At box 560, the user may return to the web browser 115 and paste the virtual account number stored in the clipboard 114 into the payment field of the form. At box 565, the account application 113 outputs a notification specifying the account holder name, billing address, shipping address, expiration date, and / or CVV after the timer set at box 555 has elapsed (or exceeds a threshold amount of time). Doing so allows the user to copy and paste the account holder name, billing address, shipping address, expiration date, and / or CVV into the corresponding fields of the form.

[0064] Figure 6An embodiment of a logic flow 600 is shown. The logic flow 600 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 600 may include some or all of the operations of generating a virtual account number using a contactless card and copying the virtual account number to the clipboard 114. The embodiments are not limited in this context.

[0065] As shown, the logic flow 600 starts at box 605, where the account application 113 and / or OS112 determines that the payment field of the form has received focus. The form can be in the first tab of the web browser 115. For example, the user can tap the payment field of the form to give the payment field focus. As another example, the user can use a mouse and / or keyboard to select the payment field of the form. More generally, any technology can be used to give the payment field focus, including programmatically generated focus. For example, the payment field can receive focus based on the HTML "focus()" method. As another example, when the form is loaded, for example, based on the "autofocus" HTML attribute applied to the payment field in the source code, the payment field can automatically receive focus. The payment field can include one or more of the name field, the account number field, the expiration date field, the shipping address field, the billing address field, and / or the CVV field. Once the payment field receives focus, the account application 113 and / or OS112 can output a notification designated to the user to tap the contactless card 101 on the mobile device 110. In some embodiments, a notification can be generated based on determining that the form contains one or more payment fields. The notification may include a GUI depicting an example of how to tap the contactless card 101 against the mobile device 110. At block 610, the user taps the contactless card 101 against the mobile device to cause the contactless card 101 to generate and transmit encrypted data as part of a URL. The account application 113 may send an instruction to the contactless card 101 via the NFC reader 118 specifying the generation and transmission of encrypted data as part of a URL.

[0066] At box 615, the contactless card applet 103 generates encrypted data using the private key 104 and the cryptographic algorithm. The applet 103 may then include the encrypted data as a parameter of the URL. The URL may be the URL of the authentication application 123 and / or the authentication server 120, which causes the second tab of the web browser 115 to be opened. At box 620, the applet 103 may send the URL including the encrypted data to the mobile device 110. At box 625, the web browser 115 opens the second tab and loads the URL including the encrypted data.

[0067] At box 630, the account application 113 extracts the encrypted data from the URL and decrypts the encrypted data using the private key in the memory of the server 120 to verify the encrypted data. At box 635, the authentication application 123 sends an instruction to the VAN generator 142 to specify the generation of a virtual account number, an expiration date, and a CVV. The authentication application 123 can also specify one or more restrictions on the virtual account number (e.g., must be used within 1 hour, can only be used on the website of a specified merchant, etc.). At box 640, the VAN generator 142 generates a virtual account number, an expiration date, and a CVV.

[0068] At box 645, the VAN generator 142 sends a push notification including the virtual account number, expiration date, and CVV to the mobile device 110. The VAN generator 142 may also send the account holder's name, billing address, and / or shipping address as part of the push notification. The mobile device 110 may then output the received push notification. Additionally and / or alternatively, at box 650, the VAN generator 142 sends a text message including the virtual account number, expiration date, and CVV to the mobile device 110. The mobile device 110 may then output a notification corresponding to the text message, wherein the notification displays the virtual account number, expiration date, and CVV. Additionally and / or alternatively, at box 655, the virtual account number, expiration date, CVV, account holder's name, billing address, and / or shipping address are optionally output for display in a second tab of the web browser 115. At block 660, one or more of the virtual account number, expiration date, CVV, account holder name, billing address, and / or shipping address may be copied from one or more of the push notification, text message notification, and second browser tab and pasted into the form in the first browser tab. Additionally and / or alternatively, the virtual account number, expiration date, CVV, account holder name, billing address, and / or shipping address may be automatically populated into the form.

[0069] Figure 7 An embodiment of an exemplary computing architecture 700 including a computing system 702 is shown, which may be suitable for implementing various embodiments as described above. In various embodiments, the computing architecture 700 may include or be implemented as part of an electronic device. In some embodiments, the computing architecture 700 may represent, for example, a system that implements one or more components of the system 100. In some embodiments, the computing system 702 may represent, for example, a mobile device 110, an authentication server 120, and / or a virtual account server 140 of the system 100. The embodiments are not limited in this regard. More generally, the computing architecture 700 is configured to implement the various embodiments described herein with reference to FIGS. 1 to 11 . Figure 6 All logic, applications, systems, methods, devices and functions described.

[0070] As used in this application, the terms "system" and "component" and "module" are intended to refer to computer-related entities, hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture 700. For example, a component can be, but is not limited to, a process running on a computer processor, a computer processor, a hard drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable file, a thread of execution, a program, and / or a computer. For example, both an application running on a server and a server can be a component. One or more components can reside in a process and / or a thread of execution, and a component can be located on a computer and / or distributed between two or more computers. Further, components can be communicatively coupled to each other through various types of communication media to coordinate operations. Coordination can include unidirectional or bidirectional information exchange. For example, a component can communicate information in the form of a signal transmitted through a communication medium. The information can be implemented as a signal assigned to various signal lines. In this assignment, each message is a signal. However, other embodiments can alternatively use data messages. Such data messages can be sent through various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0071] The computing system 702 includes various common computing elements, such as one or more processors, multi-core processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, sound cards, multimedia input / output (I / O) components, power supplies, etc. However, embodiments are not limited to implementation by the computing system 702.

[0072] like Figure 7 As shown, computing system 702 includes processor 704, system memory 706, and system bus 708. Processor 704 can be any of a variety of commercially available computer processors, including but not limited to and processor; Application, embedded and security processors; and and Processors; IBM and Cell processor; Core(2) and Dual microprocessors, multi-core processors, and other multi-processor architectures may also be used as processor 704 .

[0073] The system bus 708 provides an interface for system components, including but not limited to the interface of the system memory 706 to the processor 704. The system bus 708 can be any of several types of bus structures, which can also interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. Interface adapters can be connected to the system bus 708 through a slot architecture. Example slot architectures can include but are not limited to accelerated graphics port (AGP), card bus, (extended) industry standard architecture ((E)ISA), micro channel architecture (MCA), peripheral component interconnect (extended) (PCI (X)), PCI Express, personal computer memory card international association (PCMCIA), etc.

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

[0075] The computing system 702 may include various types of computer-readable storage media in the form of one or more low-speed storage units, including an internal (or external) hard disk drive (HDD) 714, a magnetic floppy disk drive (FDD) 716 that reads from or writes to a removable magnetic disk 718, and an optical drive 720 that reads from or writes to a removable optical disk 722 (e.g., a CD-ROM or DVD). The HDD 714, FDD 716, and optical drive 720 may be connected to the system bus 708 via a HDD interface 724, a FDD interface 726, and an optical drive interface 728, respectively. The HDD interface 724 for external drive implementations may include at least one or both of a universal serial bus (USB) and IEEE 1394 interface technologies. The computing system 702 is typically configured to implement the computer systems described herein with reference to FIGS. 1 to 13. Figure 6 All logic, systems, methods, devices and functions described herein.

[0076] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-executable instructions, etc. For example, a number of program modules may be stored in the drives and memory units 710, 712, including an operating system 730, one or more application programs 732, other program modules 734, and program data 736. In one embodiment, the one or more application programs 732, other program modules 734, and program data 736 may include, for example, various applications and / or components of the system 100, such as the operating system 112, the account application 113, the clipboard 114, the web browser 115, the authentication application 123, and the VAN generator 142.

[0077] A user may enter commands and information into the computing system 702 through one or more wired / wireless input devices, such as a keyboard 738 and a pointing device, such as a mouse 740. Other input devices may include a microphone, an infrared (IR) remote control, a radio frequency (RF) remote control, a game pad, a stylus, a card reader, a dongle, a fingerprint reader, a glove, a graphics tablet, a joystick, a keyboard, a retina reader, a touch screen (e.g., a capacitive touch screen, a resistive touch screen, etc.), a trackball, a trackpad, a sensor, a stylus, etc. These and other input devices are typically connected to the processor 704 through an input device interface 742 coupled to the system bus 708, but may also be connected through other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR port, etc.

[0078] A monitor 744 or other type of display device is also connected to the system bus 708 via an interface, such as a video adapter 746. The monitor 744 may be internal or external to the computing system 702. In addition to the monitor 744, computers typically include other peripheral output devices, such as speakers, printers, and the like.

[0079] The computing system 702 can operate in a networked environment using logical connections to one or more remote computers (e.g., remote computers 748) via wired and / or wireless communications. The remote computer 748 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment appliance, peer-to-peer device, or other public network node, and typically includes many or all of the elements described relative to the computing system 702, although only memory / storage device 750 is shown for simplicity. The depicted logical connections include wired / wireless connections to a local area network (LAN) 752 and / or a larger network (e.g., a wide area network (WAN) 754). Such LAN and WAN networking environments are common in offices and companies, and facilitate enterprise-wide computer networks, such as intranets, all of which can be connected to a global communications network, such as the Internet. In an embodiment, the network 130 of FIG. 1 is one or more of the LAN 752 and the WAN 754.

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

[0081] When used in a WAN networking environment, the computing system 702 may include a modem 758, or be connected to a communications server on the WAN 754, or have other means for establishing communications over the WAN 754, such as through the Internet. The modem 758 (which may be internal or external, and a wired and / or wireless device) is connected to the system bus 708 via the input device interface 742. In a networked environment, program modules depicted relative to the computing system 702, or portions thereof, may be stored in the remote memory / storage device 750. It should be appreciated that the network connections shown are exemplary, and other means of establishing a communications link between the computers may be used.

[0082] The computing system 702 is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices that are operatively arranged to be in wireless communication (e.g., IEEE 802.16 over-the-air modulation technology). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth wireless technologies, among others. Thus, the communication may be a predefined structure like a conventional network, or simply an ad hoc communication between at least two devices. Wi-Fi networks use radio technologies known as IEEE 802.11x (a, b, g, n, etc.) to provide secure, reliable, and fast wireless connections. Wireless networks can be used to connect computers to each other, to the Internet, and to wired networks (which use media and functions associated with IEEE 802.3).

[0083] Various embodiments can be implemented using hardware elements, software elements or a combination of the two. The example of hardware elements can include processors, microprocessors, circuits, circuit elements (e.g., 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, chipsets, etc. The example 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, processes, software interfaces, application program interfaces (APIs), instruction sets, computing codes, computer codes, code segments, computer code segments, words, values, symbols or any combination thereof. Determining whether an embodiment is implemented using hardware elements and / or software elements can vary according to many factors, such as desired computing rate, power level, heat resistance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed and other design or performance constraints.

[0084] One or more aspects of at least one embodiment may be implemented by representative instructions representing various logics within a processor stored on a machine-readable medium, which, when read by a machine, cause the machine to manufacture logic to perform the techniques described herein. Such a representative, referred to as an "IP core", may be stored on a tangible machine-readable medium and supplied to various customers or manufacturing facilities to be loaded into a manufacturing machine that manufactures logic or a processor. Some embodiments may be implemented, for example, using a machine-readable medium or article, which may store an instruction or a set of instructions that, if executed by a machine, may cause the machine to perform methods and / or operations according to an embodiment. Such a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and may be implemented using any suitable combination of hardware and / or software. The machine-readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, storage medium, storage device, storage article, storage medium and / or storage unit, such as memory, removable or non-removable media, erasable or non-erasable media, writable or rewritable media, digital or analog media, hard disk, floppy disk, compact disk read only memory (CD-ROM), compact disk recordable (CD-R), compact disk rewritable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various types of digital versatile disks (DVDs), magnetic tapes, cassettes, etc. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc., implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

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

Claims

1. A method comprising: receiving, by a processor of the computing device, a link to a server from the card, wherein parameters of the link include encrypted data; opening, by an operating system (OS) executing on the processor, a first application based on the link; accessing the link by the first application to provide the encrypted data to the server; receiving, by the first application, account data based on verifying the encrypted data by the server; receiving, by the first application, account data based on verifying the encrypted data by the server; as well as The account data is communicated by the first application to a second application executing on the processor via features of the OS.

2. The method according to claim 1, wherein: Features of the OS include an autofill service or a clipboard.

3. The method according to claim 1, wherein: Communicating the account data includes a feature of the OS inserting the account data into a form field of the second application.

4. The method according to claim 3, further comprising, before receiving the link: A determination is made, by the application or the OS, that the form field is associated with the account data based on a metadata attribute of the form field.

5. The method of claim 3, further comprising, before receiving the link: determining, by the application or the OS, that the form field has received focus; and Based on a determination by the application that the form field has received focus, an indication is output to the device specifying that the card be tapped.

6. The method according to claim 5, wherein: The application or the OS determines, based on a metadata attribute of the form field, that the form field has received focus.

7. The method according to claim 1, wherein: The account data includes one or more of a payment token, an account number, an expiration date, a card verification value (CVV), or a billing address.

8. The method according to claim 1, wherein: The account data is received via one of a push notification or a text message.

9. The method according to claim 1, wherein: The link and the encrypted data are received via Near Field Communication (NFC) and in NFC Data Exchange Format (NDEF).

10. A non-transitory computer-readable storage medium comprising instructions that, when executed by a processor of a device, cause the processor to: receiving a link to a server from the card, wherein parameters of the link include encrypted data; opening, by an operating system (OS), a first application based on the link; accessing the link by the first application to provide the encrypted data to the server; receiving, by the first application, account data based on verifying the encrypted data by the server; receiving, by the first application, account data based on verifying the encrypted data by the server; and The account data is communicated by the first application to a second application executing on the processor via features of the OS.

11. The computer-readable storage medium of claim 10, wherein: Features of the OS include an autofill service or a clipboard.

12. The computer-readable storage medium of claim 10, wherein: Communicating the account data includes a feature of the OS inserting the account data into a form field of the second application.

13. The computer-readable storage medium of claim 12, wherein: The instructions further cause the processor, prior to receiving the link: A determination is made, by the application or the OS, that the form field is associated with the account data based on a metadata attribute of the form field.

14. The computer-readable storage medium of claim 12, wherein: The instructions further cause the processor, prior to receiving the link: determining, by the application or the OS, that the form field has received focus; and Based on a determination by the application that the form field has received focus, an indication is output to the device specifying that the card be tapped.

15. The computer-readable storage medium of claim 14, wherein: The application or the OS determines, based on a metadata attribute of the form field, that the form field has received focus.

16. A computing device comprising: processor; and a memory storing instructions that, when executed by the processor, cause the processor to: receiving a link to a server from the card, wherein parameters of the link include encrypted data; opening, by an operating system (OS), a first application based on the link; accessing, by the first application, a link to provide the encrypted data to the server; receiving, by the first application, account data based on verifying the encrypted data by the server; receiving, by the first application, account data based on verifying the encrypted data by the server; and The account data is communicated by the first application to a second application executing on the processor via features of the OS.

17. The computing device of claim 16, wherein: Features of the OS include an autofill service or a clipboard.

18. The computing device of claim 16, wherein: Communicating the account data includes a feature of the OS inserting the account data into a form field of the second application.

19. The computing device of claim 18, wherein: The instructions further cause the processor, prior to receiving the link: A determination is made, by the application or the OS, that the form field is associated with the account data based on a metadata attribute of the form field.

20. The computing device of claim 18, wherein: The instructions further cause the processor, prior to receiving the link: determining, by the application or the OS, that the form field has received focus; and Based on a determination by the application that the form field has received focus, an indication is output to the device specifying that the card be tapped.

Images