Generating virtual number of virtual card with on-demand application to securely and automatically populate form

Abstract

Generating a virtual number of a virtual card with an on-demand application to securely and automatically populate a form is disclosed. Wherein the first application may output a form including a payment domain. An operating system (OS) may receive a uniform resource locator (URL) including encrypted data from a contactless card. A second application received by the OS from the URL may be executed. The second application may send the encrypted data to an authentication server that verifies the encrypted data. The second application may receive, from the virtual account server, a virtual account, a period of validity associated with the virtual account, and a CVV associated with the virtual account. The second application may provide the virtual account, the period of validity, and the CVV to an auto-fill service of the OS. An auto-fill service of the OS may automatically fill the virtual account in a payment domain of the first application.

Description

[0001] This application is a divisional application of the patent application with the application number "202080008130.3", the application date "January 29, 2020", and the title "Generating Virtual Numbers for Virtual Cards with On-Demand Applications to Securely Autofill Forms". Technical Field

[0002] Embodiments herein generally relate to computing platforms, and more particularly, to using on-demand applications to generate virtual numbers for contactless cards to securely autofill form fields.

[0003] Related Applications

[0004] This application claims the priority of U.S. Patent Application Serial No. 16 / 265,961, entitled "USING ON-DEMAND APPLICATIONS TO GENERATE VIRTUAL NUMBERS FOR A CONTACTLESS CARD TO SECURELY AUTOFILL FORMS", filed on February 1, 2019. The content of the above application is incorporated herein by reference in its entirety. Background Art

[0005] The account identifier of a payment card is typically a long number and / or string. As such, it is difficult for users to manually enter the account identifier correctly. In fact, users often make mistakes and enter incorrect account numbers into computing interfaces (e.g., payment interfaces). Generally, native operating system (OS) applications downloaded from an app store may include functions to assist users in entering account identifiers into forms. However, some users may not have such applications on their devices. Therefore, these users must manually enter the account identifier correctly. Summary of the Invention

[0006] Embodiments disclosed herein provide systems, methods, articles of manufacture, and computer-readable media for tapping a contactless card onto a computing device to securely generate a virtual card number that can be autofilled in a form field. According to one example, a first application can output a form including a payment field. The operating system (OS) can receive a uniform resource locator (URL) including encrypted data from the contactless card. A second application can be dynamically downloaded and installed from the received URL. The second application can send the encrypted data to an authentication server, which verifies the encrypted data. The second application can receive a virtual account number, an expiration date associated with the virtual account number, and a CVV associated with the virtual account number from a virtual account server. The second application can provide the virtual account number, expiration date, and CVV to the autofill service of the OS. The autofill service of the OS can autofill the virtual account number in the payment field of the first application. Brief Description of the Drawings

[0007] Figure 1A - Figure 1C An embodiment of a system is shown that taps a contactless card on a computing device to securely generate a virtual card number that can be automatically filled in a form field.

[0008] Figure 2A - Figure 2D An embodiment is shown that taps a contactless card on a computing device to securely generate a virtual card number that can be automatically filled in a form field.

[0009] Figure 3 An embodiment of a first logical flow is shown.

[0010] Figure 4 An embodiment of a second logical flow is shown.

[0011] Figure 5 An embodiment of a third logical flow is shown.

[0012] Figure 6 An embodiment of a fourth logical flow is shown.

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

[0014] The embodiments disclosed herein provide secure techniques for using a contactless card to generate card data (e.g., account number, expiration date, and / or card verification value (CVV)) that can be automatically filled into a form on a computing device without an application (e.g., a banking application, an account management application, a payment application, etc.) being pre-installed on the device. Generally, when a computing device is outputting a form that includes a card data field, a contactless card can enter the communication range of the computing device, for example, via a tap gesture. Doing so causes the contactless card to generate a uniform resource locator (URL) that is sent to the computing device. At least a portion of the URL can be directed to an application server that hosts one or more applications and / or application segments. An application can include an application available via an app store, and a segment of an application can include a portion of the application (e.g., one or more pages, one or more functions, etc.). For example, an application segment can be an on-demand application such as an instant application and / or a progressive web application. One or more application segments associated with the URL can be downloaded to the computing device and executed on the computing device.

[0015] The URL generated by the contactless card may further include data used by the authentication server as part of the verification process. For example, the URL may include encrypted data that is decrypted by the server as part of the verification process. The downloaded application segment may receive the URL and extract the encrypted data. Then, the downloaded application may send the encrypted data to the authentication server for verification. Once verified, the authentication server may instruct the virtual account server to generate card data for the account associated with the contactless card. The card data may include a virtual account number, expiration date, CVV, and the user's address. The virtual account number may be an account number different from the account number associated with the contactless card. The generated card data may then be sent to the application segment executing on the computing device. The application segment may provide the card data to the autofill service of the OS. Then, the autofill service may automatically fill the card data into the corresponding payment field of the form.

[0016] Advantageously, the embodiments disclosed herein improve the security of all devices and associated data. For example, the embodiments disclosed herein provide security for applications installed through the app store when autofilling card data, without requiring the user to install the application from the app store on their computing device. Additionally, conventional methods require the user to manually enter the card data into the form. However, doing so may allow other users or devices to capture the card data when the user enters the card data into the form. By eliminating the need for the user to manually enter the card data into the form, the security of the card data is enhanced.

[0017] Generally referring to the symbols and terms used herein, one or more portions of the following detailed description may be presented in terms of program procedures executable on a computer or computer network. These process descriptions and representations are used by those skilled in the art to most effectively convey the substance of their work to other members of the art. A process is herein, and generally, considered to be a self-consistent sequence of operations leading to a desired result. These operations are operations 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, transmitted, combined, compared, and otherwise manipulated. Primarily for reasons of generality, it has proven convenient at times to refer to these signals as bits, values, elements, symbols, characters, items, numbers, or the like. However, it should be noted that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

[0018] In addition, these manipulations are typically referred to by terms such as addition or comparison, which are usually 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, in most cases such capabilities of a human operator are not required or desired. 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 according to the teachings herein, and / or include devices or digital computers specially constructed for the desired purpose. The various embodiments also relate to devices or systems for performing these operations. These devices may be specially constructed for the desired purpose. From the description given, the structure required for the various such machines will be apparent.

[0019] Now referring to the drawings, where like reference numerals are always used 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 thereof. However, it is apparent that the novel embodiments may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate their description. The aim is to cover all modifications, equivalents, and alternatives within the scope of the claims.

[0020] Figure 1A A schematic diagram of an exemplary system 100 consistent with the disclosure is depicted. As shown, system 100 includes one or more contactless cards 101, one or more mobile devices 110, an authentication server 120, a virtual account server 140, and an application server 150. Contactless card 101 represents any type of payment card, such as a credit card, debit card, ATM card, gift card, and the like. Contactless card 101 may include one or more chips (not depicted), such as radio frequency identification (RFID) chips, which are configured to communicate with mobile device 110 via NFC, EMV standards, 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 communication, such as EMV standards, Bluetooth, and / or Wi-Fi. Mobile device 110 represents any type of network-enabled computing device, such as a smart phone, tablet computer, wearable device, laptop computer, portable gaming device, and the like. Servers 120, 140, 150 represent any type of computing device, such as a server, workstation, computer cluster, cloud computing platform, virtualized computing system, and the like.

[0021] As shown, the memory 111 of mobile device 110 includes an instance of an operating system (OS) 112. Example operating systems 112 include and Operating system. As shown, OS 112 includes an autofill service 114, a web browser 115, and one or more other applications 116. The autofill service 114 injects data into the views of other applications (e.g., web browser 115 and / or other applications 116) to populate forms in the other applications. The autofill service 114 can also retrieve user data from the views in the applications and store the data for later use. The autofill service 114 is used herein as a reference example and should not be considered a limitation of the present disclosure. The present disclosure equally applies to other types of code that autofill form fields in applications and / or web pages by injecting data into form fields, such as accessibility services. The web browser 115 is an application that allows the mobile device 110 to access information via a network 130 (e.g., via the Internet). In operation, the web browser 115 can access content that includes one or more forms 127. For example, the web browser 115 can load a bank card management page that includes one or more forms 127 having fields for card data (e.g., name field, card number field, expiration date field, CVV field, billing address field, shipping address field, etc.). The other applications 116 represent any application that includes one or more forms 129 having fields for card data (e.g., name field, card number field, expiration date field, CVV field, billing address field, shipping address field, etc.). For example, the other applications 116 include dedicated merchant applications for processing purchases, applications for services (e.g., taxi service, delivery service, etc.), and the like. Each example of the other applications 116 includes one or more forms 129 having fields for card data.

[0022] As another example, a user can make a purchase from a merchant's website using the web browser 115 and / or other applications 116 provided by the merchant. To complete the transaction, the user must provide card data to one or more forms 127 in the web browser 115 and / or forms 129 in the other applications 116. Using the web browser 115 and / or other applications 116 as reference examples herein should not be considered a limitation of the present disclosure, as the present disclosure equally applies to all types of applications that include forms having fields for card data and all types of forms having fields for card data.

[0023] Typically, a user may encounter forms 127, 129 that include one or more fields for card data (e.g., name field, card number field, expiration date field, CVV field, billing address field, shipping address field, etc.). Conventionally, users are required to manually enter their name, card number, expiration date, CVV, and / or address information. Some mobile operating systems allow such data to be automatically filled into the form, but other mobile operating systems impose restrictions on automatically filling such data. Additionally, in operating systems that allow data in the form to be automatically filled, the user must be authenticated through a dedicated application to do so. For example, existing solutions require the user to install an account management application provided by the issuer of the contactless card 101 and authenticate in the application to automatically fill the card data in forms 127, 129. Advantageously, however, the embodiments disclosed herein solve such problems by leveraging the contactless card 101 to trigger the generation of a virtual account number, expiration date, and / or CVV that can be copied to the autofill service 114 of the OS 112 without an application (such as an account management application) pre-installed on the device 110.

[0024] To this end, the user can tap the non-contact card 101 on the mobile device 110, so that the non-contact card 101 is sufficiently close to the card reader 119 of the mobile device 110 to enable NFC data transfer between the communication interface 107 of the non-contact card 101 and the card reader 119 of the mobile device 110. In some embodiments, the mobile device 110 can trigger the card reader 119 via an application programming 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 the user interface (such as a form field). Additionally and / or alternatively, the mobile device 110 can trigger the card reader 119 based on periodically polling the card reader 119. More generally, the mobile device 110 can use any feasible method to trigger the card reader 119 to communicate. After communication is established between the mobile device 110 and the non-contact card 101, the applet 103 executed on the processor (not shown) of the non-contact card 101 generates data via the communication interface 107 and sends it to the mobile device 110. In some embodiments, the data generated by the non-contact card 101 can include a URL 106. The URL can be directed to the application server 150 or some other location hosting one or more account applications 151. When the OS 112 receives the URL 106, the OS can dynamically download the account application 151 from the URL 106 and dynamically install the account application 151 on the device. The URL 106 can also be a universal link URL (or deep link URL) that opens a local resource (such as one or more specific pages of the associated account application 151). The page of the account application 151 that should be opened when executed on the mobile device 110 can be specified as a parameter of the URL.

[0025] More generally, the URL 106 represents one or more URLs (and / or uniform resource identifiers (URIs)) directed to one or more account applications 151 of the application server 150. The applet 103 can select the URL 106 based on any suitable selection technique (such as randomly, based on data received from the mobile device 110, etc.). The account application 151 can include on-demand applications that can be dynamically downloaded and installed on the mobile device 110. As shown, the account application 151 includes an instant application 152 and a progressive web application 153. An instant application is a non-persistent application that can be dynamically downloaded and installed on the mobile device 110. An example of the instant application 152 is Instant App. An instant app 152 is an on-demand app that can be installed and executed immediately on a mobile device 110 upon download completion. Additionally, the instant app 152 corresponds to a subset of apps selected based on a specific function to be performed, while the remainder of the app can be downloaded later (or as part of background processing). For example, the instant app 152 can be a subset of an overall account management app that performs various functions, and the instant app 152 includes one or more parts of the account management app and / or a subset of the functions provided by the account management app.

[0026] Generally, a progressive web app is an on-demand app that is executed in a web browser 115 and persists when executed on a mobile device 110. For example, a progressive web app is allocated storage on the mobile device 110 and can be updated in the background when new features are added to the progressive web app. An example of a progressive web app 153 is an Android progressive web app. As stated, the progressive web app 153 can be dynamically downloaded and automatically executed in the web browser 115 upon download completion. The progressive web app 153 corresponds to a subset of apps selected based on a specific function to be performed. For example, the progressive web app 153 can be a subset of an overall account management app that performs various functions, and the progressive web app 153 includes one or more parts of the account management app and / or a subset of the functions provided by the account management app.

[0027] In some embodiments, the account app 151 includes one or more parts (or segments) of another app (e.g., an account management app, etc.). Thus, in other words, the account app 151 can include a subset (or all) of pages and / or functions of other apps. For example, a first account app 151 can include a page that allows a customer to view their bank account balance and a page that allows the customer to send an email to customer service while excluding other functions provided by a full account management app (e.g., payment plans, loan requests, etc.). Advantageously, the first account app 151 is able to perform related functions without having the bank's account management app pre-installed on the mobile device 110. More generally, the account app 151 can be collectively regarded as a cloud-based "app bundle" that can be accessed, and a subset of the bundle can be quickly downloaded to the mobile device 110. Thus, the app bundle can collectively include all the functions provided by the account management app, but only a subset of the account app 151 that is needed to perform one or more required operations is downloaded to the mobile device 110.

[0028] The URL 106 generated by the applet 103 may further include encrypted data 105 as a parameter. As described in more detail below, the authentication server 120 may use the encrypted data 105 to verify data generated by the contactless card 101. For example, the applet 103 of the contactless card 101 may use a cryptographic algorithm to generate a cryptographic payload of the encrypted data 105 based at least in part on a private key 104 stored in the memory 102 of the contactless card 101. In such an embodiment, the private key 104 and some other data segments (e.g., customer identifier, account identifier, etc.) may be provided as inputs to the cryptographic algorithm, the output of which is the encrypted data 105. Generally, the applet 103 may use any type of cryptographic algorithm and / or system to generate the encrypted data 105, and the use of a particular cryptographic algorithm as an example herein should not be construed as a limitation of the present disclosure. In some embodiments, the applet 103 may use key diversification techniques to perform encryption 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 entire content of the above patent application is incorporated herein by reference.

[0029] As stated, the applet 103 of the contactless card 101 can include encrypted data 105 as a parameter of the URL 106, thereby generating a URL with encrypted data 108. For example, if the URL to the application server 150 and / or the account application 151 is "http: / / www.example.com / accountapp", and the encrypted data 105 is "ABC123", then the URL with encrypted data 108 can be "http: / / www.example.com / accountapp?data=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 106. For example, the encrypted data 105 can be a string of binary data (e.g., zeros and ones), which 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. This is done by converting the binary encrypted data 105 in ASCII string format to a base 64 representation (e.g., "ABC123" in the previous example) to represent the binary encrypted data 105 in ASCII string format. Further, the URL 106 can include an indication of which page of the application 151 to open at installation. Continuing with the previous example, the page identifier "1" (or other page identifier, such as a page name, etc.) can be added as a parameter to the URL 106, and the URL with encrypted data 108 can be "http: / / www.example.com / accountapp?data=ABC123&p=1".

[0030] Once generated, the applet 103 can send a URL with encrypted data 108 to the mobile device 110 via NFC, for example. In one embodiment, when received by the OS 112, the OS 112 causes the web browser 115 to access the URL with encrypted data 108. Doing so causes information describing the mobile device 110 to be sent along with the request to access the URL with encrypted data 108. For example, the information can include attributes of the mobile device 110, such as the operating system version, hardware capabilities, and software capabilities. In response, the application server 150 can send the account application 151 associated with the URL with encrypted data 108 to the mobile device 110. In some embodiments, the application server 150 selects the account application 151 based on the received attributes of the mobile device 110. For example, if the OS 112 of the mobile device 110 does not support the progressive web application 153, the application server 150 can select the corresponding instant application 152 as the account application 151. In some embodiments, if the application server 150 selects the instant application 152 as the account application 151, the application server 150 can cause the mobile device 110 to open the app store application (e.g., one of the other applications 116) to download the instant application 152. Examples of app stores include Play Store, App Store, Appstore, etc.

[0031] In some embodiments, when the OS 112 receives a URL with encrypted data 108, the URL is directed to the instant application 152. In some such embodiments, the instant application 152 is downloaded through the app store. Thus, instead of opening the web browser 115, the OS 112 opens the corresponding app store application 116. In some embodiments, the app store application 116 is opened in the background of the OS 112 without opening the app store application 116 in the foreground of the OS 112. In such embodiments, the instant application 152 is downloaded in the background of the OS 112. Whether appearing in the foreground or background of the OS 112, the app store application 116 downloads, installs, and executes the instant application 152. However, in some embodiments, the web browser 115 can be used to download such instant applications 152, regardless of where the instant application 152 is stored.

[0032] Additionally and / or alternatively, the application server 150 may select the account application 151 based on the portions of the application required to perform a given function. For example, the application server 151 may determine, based on the encrypted data 105 in the URL having the encrypted data 108, that the function includes one or more of the following: extracting the encrypted data 105, decoding the encrypted data 105, sending the decoded encrypted data 105 to the authentication server 120, receiving virtual card data 126 from the VAN generator 142, and providing the virtual card data 126 to the autofill service 114. Accordingly, the application server 150 may select one or more account applications 151 that include the functions required to perform the described function. For example, the application server 150 may select one or more instant applications 152 that include the following functions: extracting the encrypted data 105, decoding the encrypted data 105, sending the decoded encrypted data 105 to the authentication server 120, receiving virtual card data 126 from the VAN generator 142, and providing the virtual card data 126 to the autofill service 114. In some embodiments, the application server 150 may send additional portions of the application to the mobile device 110 (e.g., as part of a background download).

[0033] Similarly, the application server 150 may select one or more progressive web applications 153 based on the portions of the application required to perform a given function. For example, the progressive web application 153 may be optimized for a given task and / or function. As another example, the progressive web application 153 may include a subset of the core progressive web application 153 that performs the required function (and / or additional functions). The core progressive web application 153 may include the full functionality of an account management application. Accordingly, continuing the previous example, the application server 150 may select one or more progressive web applications 153 that are optimized to extract the encrypted data 105, decode the encrypted data 105, send the decoded encrypted data 105 to the authentication server 120, receive virtual card data 126 from the VAN generator 142, and provide the virtual card data 126 to the autofill service 114. Similarly, the application server 150 may select a subset of the core progressive web application 153, where the subset includes the following functions: extracting the encrypted data 105, decoding the encrypted data 105, sending the decoded encrypted data 105 to the authentication server 120, receiving virtual card data 126 from the VAN generator 142, and providing the virtual card data 126 to the autofill service 114.

[0034] Figure 1B An embodiment is depicted in which the example account application 151-1 has been dynamically downloaded and installed in the memory 111 of the mobile device 110. The account application 151 may be an instant application 152 and / or a progressive web application 153. InFigure 1B For clarity, some elements of Figure 1A are not depicted. As stated, the account application 151-1 can be selected by the application server 150 based on one or more desired functions, functions performed by the account application 151-1, and / or parameters of the mobile device 110. Although depicted as executing in the memory 111 (e.g., as an instant application 152), if the account application 151-1 is a progressive web application 153, an instance of the progressive web application 153 of the account application 151-1 can execute in the web browser 115. In one embodiment where the account application 151-1 is a progressive web application 153, the progressive web application 153 can determine to download the instant application 152 from the application server 150 and install it on the mobile device 110.

[0035] In addition, regardless of whether the account application 151-1 is an instant application 152 or a progressive web application 153, the account application 151-1 includes pages or functions sufficient to perform the desired functions (e.g., the functions described herein). More specifically, once downloaded to the mobile device 110, the account application 151-1 can open one or more pages (e.g., pages specified by one or more parameters of the URL 106), receive a URL with encrypted data 108 as input, extract the encrypted data 105 from the URL with encrypted data 108, and send the encrypted data 105 to the authentication server 120 via the network 130. In addition, the account application 151-1 can convert the encrypted data 105 to an original encoding format (e.g., from ASCII base64 to binary) before sending the binary encrypted data 105 to the authentication server 120. As described in more detail below, the account application 151-1 can receive virtual card data 126 from the VAN generator 142 and provide the virtual card data 126 to the autofill service 114.

[0036] Once received, the authentication application 123 can authenticate the encrypted data 105. For example, the authentication application 123 can attempt to decrypt the encrypted data 105 using a copy of the private key 104 stored in the memory 122 of the authentication 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, where each contactless card 101 is manufactured to include a unique private key 104 (and the authentication server 120 stores a corresponding copy of each unique private key 104). Thus, the authentication application 123 can successfully decrypt the encrypted data 105, thereby verifying the encrypted data 105. For example, as stated, the encrypted data 105 can be generated using a customer identifier. 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 the result of the decryption yields the customer identifier associated with the account in the account data 124, the authentication application 123 verifies the encrypted data 105 and instructs the VAN generator 142 to generate virtual card data 126 for the account associated with the contactless card 101. If the authentication application 123 is unable to decrypt the encrypted data to produce the expected result (e.g., the customer identifier for the account associated with the contactless card 101), the authentication application 123 does not verify the encrypted data 105. Due to the failed verification, the authentication application 123 does not instruct the VAN generator 142 to generate virtual card data 126 to protect the security of the associated account.

[0037] Figure 1B The embodiment depicted in reflects one in which the authentication application 123 verifies the encrypted data 105 and instructs the virtual account number (VAN) generator 142 in the memory 141 of the virtual account server 140 to generate virtual card data 126. The virtual card data 126 can include a virtual account number, expiration date, and / or CVV for the account associated with the contactless card 101. In some embodiments, the VAN generator 142 generates the virtual account number, expiration date, and / or CVV. In other embodiments, the VAN generator 142 generates the virtual account number and selects an existing expiration date and / or CVV (e.g., from the account data 124). For example, 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. The card data 126 can further include the name of the account holder and one or more known addresses associated with the contactless card 101.

[0038] In at least one embodiment, card data 126 including a virtual account number generated by VAN generator 142 is restricted to a particular merchant or group of merchants. The virtual account number and / or card data 126 may further include other restrictions (e.g., time restrictions, quantity restrictions, etc.). Once generated, VAN generator 142 may send the virtual card data 126 to account application 151-1 executing on mobile device 110. VAN generator 142 may provide the virtual card data 126 to account application 151-1 via any suitable method, such as a push notification, a text message, an email, one or more data packets, etc.

[0039] Once received by account application 151-1, account application 151-1 may provide, for example, the virtual account number, expiration date, CVV, and address of the virtual card data 126 to autofill service 114 of OS 112 via an application programming interface (API) of autofill service 114. Thus, account application 151-1 also includes the function of receiving the virtual card data 126 and providing the virtual card data 126 to autofill service 114. As Figure 1B shown, autofill service 114 now stores the virtual card data 126, including the virtual account number, expiration date, and CVV. As stated, the virtual card data 126 may further include the account holder's name, billing address, and / or shipping address. Doing so allows autofill service 114 to inject the virtual card data 126 into form 127 of web browser 115 and form 129 of other application 116, respectively.

[0040] Figure 1C An embodiment is depicted in which autofill service 114 autofills the virtual card data 126 into form 127 of web browser 115 and form 129 of other application 116. As referenced Figure 2A - Figure 2D in more detail, autofill service 114 may autofill each element of the virtual card data 126 into the corresponding fields of forms 127, 129. In at least one embodiment, the user may be prompted to approve the autofilling of the virtual card data 126 into forms 127, 129.

[0041] Figure 2AFIG. 200 is a schematic diagram depicting an example embodiment in which a contactless card 101 is tapped to generate virtual card data to be filled into an example form using an autofill service 114. As shown, a web browser 115 outputs a page at URL 201. The page at URL 201 includes a form (e.g., a payment form) having form fields 202 - 204 and 209, where field 202 corresponds to an account number field, field 203 corresponds to an expiration date field, field 204 corresponds to a CVV field, and field 209 corresponds to an address field. The address field 209 can be a billing address and / or a shipping address. The form may include additional elements not depicted for clarity. As shown, a notification 205 is output by the OS 112 and / or a different service (if installed). The notification 205 instructs the user to tap the contactless card 101 on the mobile device 110. In one embodiment, the user selects the notification 205 before tapping the contactless card 101 on the mobile device 110. However, in some embodiments, the notification 205 is not output, and the user taps the contactless card 101 on the mobile device 110 without an instruction from the notification 205.

[0042] In one example, when the account number field 202 (or another field) receives focus (e.g., is selected by the user), the OS 112 outputs the notification 205. To determine that a field has received focus, the OS 112 can analyze the hypertext markup language (HTML) attributes of the account number field 202 to determine that the account number field 202 has received focus. As another example, the OS 112 outputs the notification 205 when determining that the form includes one or more payment fields. Additionally, the OS 112 can analyze the metadata of the account number field 202 to determine that the field 202 is associated with an account number. For example, the OS 112 can determine based on the metadata that the account number field 202 is configured to receive 16 characters as input. As another example, the metadata can assign a name to the form field 202 similar to a name associated with an account number field (e.g., "accountnumber", "account_number", etc.). As another example, the metadata of a form field can 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. Thus, the OS 112 can output the notification 205 to tap the contactless card 101 on the mobile device 110 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.

[0043] As stated, once the contactless card 101 is tapped onto the mobile device 110, the OS 112 sends an indication to the communication interface 107 of the contactless card 101 via the card reader 119 (e.g., via NFC, Bluetooth, RFID, and / or EMV protocol, etc.). This indication can specify to generate a URL with encrypted data. As stated, the applet 103 can use the data of the contactless card (e.g., customer identifier) and the private key 104 as inputs to a cryptographic algorithm to generate encrypted data to generate the encrypted data 105. The applet 103 can encode the encrypted data 105 into an encoding format compatible with the URL. The applet 103 can then select the URL 106 and include the encoded encrypted data 105 as a parameter of the URL 106. The applet 103 can further add an indication of one or more pages of the account application 151 as a parameter to the URL. Doing so ensures that the account application 151 opens to the correct page at execution time by receiving the URL as an input (e.g., as an "oncreate" input provided to the account application 151 at execution time). Then, the applet 103 can send the URL with the encrypted data to the mobile device 110 via the communication interface 107.

[0044] Figure 2BFIG. 210 is a schematic diagram depicting an embodiment in which the OS 112 of the mobile device 110 receives a URL having encrypted data generated by the contactless card 101. As shown, the OS 112 has caused the web browser 115 to open an example URL 206 that points to the application server 150. In an embodiment, in the case where the payment form fields 202-204 are in one of the other applications 116, the OS 112 opens the web browser 115 and causes the web browser 115 to access the URL 206. The application server 150 can then receive the request and initiate the transmission of the account application 151 associated with the URL 206. As stated, the account application 151 can be an instant application 152, a progressive web application 153, or any other application not pre-installed on the mobile device 110. Generally, the application server 150 selects the account application 151 based on the required functionality and the functionality performed by the account application 151. In some embodiments, the application server 150 selects the account application 151 based on attributes of the mobile device 110 described in the received URL 206. For example, if the OS 112 of the mobile device 110 does not support the instant application 152 but supports the progressive web application 153, the application server 150 can send the account application 151 as the progressive web application 153 to the mobile device 110. Other example attributes that describe the mobile device 110 include the detected software version installed in the OS 112, the speed of the network connection of the mobile device 110, the remaining battery life of the mobile device 110, etc. Thus, for example, if the mobile device 110 has a slow network connection and / or little remaining battery life, the application server 150 can select the account application 151 with the smallest size that can perform the required functionality.

[0045] Figure 2C FIG. 220 is a schematic diagram depicting an embodiment in which the instant application 152 version of the account application 151 is downloaded and installed on the mobile device 110. As shown, the account application 151 opens a page that reflects that the encrypted data 105 has been extracted and decoded from the URL 206. The page of the account application 151 is opened based on the parameter "p = 1" in the URL 206. The account application 151 can then send the extracted and decoded encrypted data 105 to the authentication server 120 for authentication. As shown, the authentication server 120 authenticates the encrypted data 105 and instructs the VAN generator 142 to generate a virtual card number, expiration date, and CVV. The VAN generator 142 then sends the generated data to the account application 151, which outputs a URL 208 that redirects to the previous application (e.g., the web browser 115 and / or other application 116) using the payment form. Other graphical objects can be used instead of the link 208, and the use of the link 208 should not be considered to limit the present disclosure.

[0046] Figure 2D FIG. 230 is a schematic diagram depicting an embodiment in which a user has selected link 208 in account application 151 to return to web browser 115. As shown, autofill service 114 has autofilled example data into form fields 202 - 204 in web browser 115. More specifically, autofill service 114 has autofilled a virtual account number into form field 202, an expiration date into form field 203, a CVV into form field 204, and the account holder's address into form field 209. Once autofilled, the user can select purchase button 211 to process payment for the purchase. Advantageously, data is autofilled into the form fields without the user having to manually enter the data and without a dedicated app for autofilling data that needs to be pre - installed on device 110. In some embodiments, autofill service 114 may output a notification (not shown) to the user that must be selected before autofilling data into form fields 202 - 204 and 209.

[0047] In some embodiments, autofill service 114 detects form fields (e.g., form fields 202 - 204, 209), detects the content in a notification (e.g., a text message notification) having a type that matches the type of the detected form fields, and provides the content parsed from the notification as autofill suggestions in the keyboard. Doing so allows autofill service 114 to automatically fill data from the notification into the corresponding form fields.

[0048] Figure 3 An embodiment of logic flow 300 is shown. Logic flow 300 may represent some or all of the operations performed by one or more embodiments described herein. For example, logic flow 300 may include some or all of the operations to generate virtual card data using a contactless card and autofill a virtual account number into a form using autofill service 114. Embodiments are not limited to this context.

[0049] As shown, logic flow 300 begins at block 305, where mobile device 110 that does not include an installed account management application outputs a first application that includes a payment form having payment fields. The first application may be one of web browser 115 that includes form 127 and / or other application 116 that includes form 129. The payment fields may include one or more of an account number field, an expiration date field, a CVV field, one or more name fields, and one or more address fields (e.g., billing address, shipping address, etc.). For example, OS 112 may analyze the metadata of the form fields to determine that one or more of the fields are associated with an account number, expiration date, CVV, billing address, etc. As another example, OS 112 may determine based on the metadata that the field is configured to receive 16 characters as input.

[0050] In some embodiments, the user can tap on the payment field of the form in the web browser 115 to give one of the payment fields focus. For example, the user can tap on 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 technique 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, for instance based on the "autofocus" HTML attribute applied to the payment field in the source code, when the form is loaded, the payment field can automatically receive focus. Once the payment field receives focus, the account application 113 and / or the OS 112 can output a notification specifying that the user should tap the contactless card 101 on the mobile device 110.

[0051] At block 310, the user taps the contactless card 101 on the mobile device 110 to cause the contactless card 101 to generate encrypted data and send it as part of a URL to one of the application server 150 and / or the account application 151. The OS 112 can send an indication to the contactless card 101 via the NFC reader 119 specifying to generate and send the encrypted data as part of a URL.

[0052] At block 315, the applet 103 of the contactless card uses the private key 104, input data (e.g., customer identifier), and a cryptographic algorithm to generate encrypted data. The applet 103 can then include the encrypted data as a parameter of the URL. The applet 103 can further encode the encrypted data before appending the encoded encrypted data as a parameter of the URL. Additionally, the URL can be a universal link URL that has a parameter specifying one or more pages of the account application 151 to open when downloaded. Further still, the URL can identify the first part of the instant app 152 and / or the progressive web app 153 that needs to be downloaded. Doing so allows the identified pages to be opened when the app 151 is downloaded to be downloaded first, while other pages that are not immediately opened are downloaded later.

[0053] At block 320, the applet 103 can send a URL including encrypted data to the mobile device 110. At block 325, the OS 112 directs the web browser 115 to access the URL received from the contactless card 101 to dynamically download and install (and / or execute) a second app (such as one of the account apps 151), where the second app is an instant app 152 and / or a progressive web app 153. The application server 150 can then select one or more of the account apps 151 and send them to the mobile device 110. As stated, in accessing the URL received from the contactless card 101, the web browser 115 can send information describing the mobile device 110 (e.g., an indication of the type of the web browser 115, the version of the web browser, the type of the OS 112, and the version of the OS 112, etc.). Thus, the application server 150 can select the account apps 151 based on the types of apps supported by the mobile device 110. In addition, the application server 150 can select the account apps 151 based on the types of functions that the account apps 151 must be configured to perform. Once received, the OS 112 executes the received account app 151. For example, the OS 112 can load the progressive web app 153 into the web browser 115. As another example, the OS 112 can execute the instant app. Regardless of the type of the account app 151, the OS 112 receives a URL with encrypted data from the application server 150 and provides the URL with encrypted data as an input to the app.

[0054] At block 330, the account app 151 extracts the encrypted data from the URL and sends the encrypted data to the authentication app 123 of the authentication server 120 for verification. As stated, in some embodiments, the account app 151 can decode the encrypted data before sending the encrypted data to the authentication server 120. At block 335, the authentication app 123 uses the private key in the memory of the authentication server 120 to decrypt the encrypted data to verify the encrypted data. At block 340, the authentication app 123 sends an indication to the VAN generator 142, and the indication specifies to generate card data including a virtual account number, an expiration date, and a CVV. At block 345, the VAN generator 142 generates a virtual account number, an expiration date, and a CVV. At block 350, the VAN generator 142 sends the virtual account number, the expiration date, and the CVV to the mobile device 110. The VAN generator 142 can further include the name of the account holder, a billing address, and a shipping address, which can be locally stored by the VAN generator 142 and / or received from the authentication server 120.

[0055] At block 355, a second application (e.g., the downloaded account application 151) provides the received data to the autofill service 114 of the OS 112. Additionally, the user can return to the first application (e.g., the web browser 115 and / or other applications 116). At block 360, the autofill service can then autofill the virtual account number, expiration date, CVV, name, and address stored in the autofill service 114 into the payment fields of the form. At block 365, the user submits the autofilled form including the card data generated by the VAN generator 142. For example, the submission of the form can update the payment information (e.g., in the user's account), complete a purchase, etc. Advantageously, the form is autofilled and the purchase can be completed without the account management application (or other applications communicating with the contactless card 101 and / or the authentication server 120) being pre-installed on the device.

[0056] Figure 4 An embodiment of a logical flow 400 is shown. The logical flow 400 can represent some or all of the operations performed by one or more embodiments described herein. For example, the logical flow 500 can include some or all of the operations performed by the application server 150 to select the account application 151 to send to the mobile device 110. The embodiments are not limited to this context.

[0057] As shown, the logical flow 400 begins at block 405, where the application server 150 receives attribute data from the mobile device 110. Generally, when following a URL generated by the contactless card 101, the web browser 115 includes data describing the mobile device 110 in a hypertext transfer protocol (HTTP) request. The application server 150 can analyze the received data to determine, for example, the type of the mobile device 110, the type and / or version of the OS 112, the type and / or version of the web browser 115, etc. At block 410, the application server 150 determines whether the mobile device 110 is compatible with the instant application 152 and / or the progressive web application 153 based on the attribute data of the mobile device 110. For example, the instant application 152 may require a specific type and version of the OS for compatibility, while the progressive web application 153 may require a specific type and version of the OS and the web browser for compatibility. The device attributes indicate whether the mobile device 110 meets these requirements.

[0058] At block 415, the application server 150 selects one or more of the instant application 152 and / or the progressive web application 153 based on the determination made at block 410. For example, if the mobile device 110 is compatible with the instant application, the application server 150 may select the instant application 152 as the account application 151. Additionally, as stated, the application server 150 selects one or more of the instant application 152 and / or the progressive web application 153 based on the required functions to be performed on the mobile device 110 (e.g., extracting encrypted data, sending the encrypted data to the authentication server, receiving virtual card data from the VAN generator 142, and providing the received virtual card data to the autofill service 114). At block 420, the application server 150 provides the URL generated by the contactless card 101 as a parameter for downloading the account application 151 selected at block 415. At block 425, the application server 150 sends the selected account application 151 and the URL to the mobile device 110. Doing so causes the selected application to be dynamically downloaded and installed on the mobile device 110.

[0059] Figure 5 An embodiment of a logical flow 500 is shown. The logical flow 500 may represent some or all of the operations performed by one or more of the embodiments described herein. For example, the logical flow 500 may include some or all of the operations performed by the contactless card 101 to generate a URL with encrypted data 108. The embodiments are not limited to this context.

[0060] As shown, the logical flow 500 begins at block 505, where the applet 103 of the contactless card generates encrypted data 105. As stated, the encrypted data 105 is the output of a cryptographic algorithm based on the private key 104 and input data (e.g., a customer identifier). At block 510, the applet 103 encodes the encrypted data 105 according to an encoding format (e.g., ASCII base64). At block 515, the applet 103 generates a URL that includes the encoded encrypted data and one or more application pages of the target account application 151 as parameters. The URL may be directed to one or more of the application server 150 and / or the account application 151. At block 520, the contactless card 101 sends the URL generated at block 515 to the mobile device 110. Upon receiving the URL, the OS 112 causes the web browser 115 to access the URL. Doing so may cause the account application 151 to be dynamically downloaded and installed on the mobile device 110.

[0061] 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 performed by an account application 151 executing on a mobile device 110. The embodiments are not limited to this context.

[0062] As shown, the logic flow 600 begins at block 605, where Figure 3 a second application (e.g., the account application 151) receives a URL including encoded encrypted data as input. At block 610, the account application 151 opens a page of the account application 151 specified in the URL. For example, the account application 151 may open one or more pages that are configured to: extract the encoded encrypted data from the URL, decode the encrypted data, send the encrypted data to an authentication server, receive virtual card data from a VAN generator 142, and provide the received virtual card data to an autofill service 114. As stated, the account application 151 may be an instant application 152 and / or a progressive web application 153.

[0063] At block 615, the account application 151 extracts the encoded encrypted data from the URL, for example, based on the parameter name in the URL. At block 620, the account application 151 decodes the encrypted data into an unencoded format (e.g., binary). At block 625, the account application 151 sends the decoded encrypted data to an authentication server 120. At block 630, the account application 151 receives virtual card data (e.g., one or more of a virtual card number, expiration date, CVV, name, billing address, and shipping address) from a VAN generator 142. At block 635, the account application 151 provides the virtual card data to an autofill service 114.

[0064] 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 previously. 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 implementing one or more components of system 100. In some embodiments, the computing system 702 may represent, for example, the mobile device 110, the authentication server 120, the virtual account server 140, and / or the application server 150 of system 100. The embodiments are not limited to this context. More generally, the computing architecture 700 is configured to implement all of the logic, applications, systems, methods, devices, and functions described with reference to FIGS. 1 - Figure 6 described.

[0065] As used in this application, the terms "system" and "component" and "module" are intended to refer to computer-related entities: hardware, combinations 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 disk drive, multiple storage drives (of optical and / or magnetic storage media), an object, an executable file, an execution thread, a program, and / or a computer. By way of illustration, an application running on a server and the server can both be components. One or more components can reside in a process and / or an execution thread, and a component can be located on one computer and / or distributed between two or more computers. Additionally, components can be communicatively coupled to each other via various types of communication media to coordinate operations. The coordination can involve one-way or two-way exchange of information. For example, a component can transmit information in the form of signals transmitted via 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 employ data messages. Such data messages can be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

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

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

[0068] The system bus 708 provides an interface for system components, which includes but is not limited to system memory 706 to the processor 704. The system bus 708 can be any one of several types of bus structures, and these bus structures can be further interconnected to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any one of various commercially available bus architectures. The interface adapter can be connected to the system bus 708 via 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), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and the like.

[0069] The system memory 706 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), polymer memory (such as ferroelectric polymer memory), two-way memory, 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 any other type of storage medium suitable for storing information. In Figure 7 the embodiment shown, the system memory 706 can include non-volatile memory 710 and / or volatile memory 712. The basic input / output system (BIOS) can be stored in the non-volatile memory 710.

[0070] The computing system 702 may include various types of computer-readable storage media in the form of one or more lower-speed memory units, including an internal (or external) hard disk drive (HDD) 714, a floppy disk drive (FDD) 716 for reading from or writing to a removable disk 718, and an optical disk drive 720 for reading from or writing to a removable optical disk 722 (e.g., CD-ROM or DVD). The HDD 714, FDD 716, and optical disk drive 720 may be connected to the system bus 708 via an HDD interface 724, an FDD interface 726, and an optical disk drive interface 728, respectively. The HDD interface 724 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies. The computing system 702 is generally configured to implement all of the logic, systems, methods, apparatuses, and functions described herein with reference to FIGS. 1- Figure 6 as described.

[0071] The drives and associated computer-readable media provide volatile and / or non-volatile storage of data, data structures, computer-executable instructions, etc. For example, multiple 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, 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 applets 103, private keys 104, URLs 106, URLs with encrypted data 108, operating systems 112, autofill services 114, web browsers 115, other applications 116, authentication applications 123, and VAN generators 142.

[0072] The user may input commands and information into the computing system 702 via 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., capacitive, resistive, etc.), a trackball, a touchpad, a sensor, a stylus, and the like. These and other input devices are typically connected to the processor 704 via an input device interface 742 coupled to the system bus 708, but may be connected via other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.

[0073] 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 can be internal or external to the computing system 702. In addition to the monitor 744, a computer typically also includes other peripheral output devices such as speakers, printers, etc.

[0074] The computing system 702 can operate in a network environment using a logical connection via wired and / or wireless communication to one or more remote computers such as the remote computer 748. The remote computer 748 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 with respect to the computing system 702, although for simplicity only the memory / storage device 750 is shown. 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 commonplace in offices and companies and facilitate enterprise-wide computer networks such as an Intranet, all of which can be connected to a global communication network (e.g., the Internet). In an embodiment, the network 130 of FIG. 1 is one or more of the LAN 752 and the WAN 754.

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

[0076] When used in a WAN networking environment, the computing system 702 can include a modem 758, or be connected to a communication server on the WAN 754, or have other means for establishing communication on the WAN 754, such as via the Internet. The modem 758 can be internal or external and can be a wired and / or wireless device that is connected to the system bus 708 via an input device interface 742. In a network environment, program modules or portions thereof depicted with respect to the computing system 702 can be stored in the remote memory / storage device 750. It should be understood that the network connections shown are exemplary, and other means of establishing a communication link between computers can be used.

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

[0078] Various embodiments can be implemented using hardware elements, software elements, or a combination of both. Examples 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, chip sets, etc. 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, processes, software interfaces, application program interfaces (APIs), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether to use hardware elements and / or software elements to implement an embodiment can vary according to many factors, such as the desired computing rate, power level, thermal tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance limitations.

[0079] One or more aspects of at least one embodiment can be implemented by representative instructions stored on a machine-readable medium representing various logics within a processor, which when read by the machine cause the machine to fabricate the logic to perform the techniques described herein. Such a representation (referred to as an “IP core”) can be stored on a tangible machine-readable medium and provided to various customers or manufacturing facilities to be loaded into a manufacturing machine for the logic or processor. For example, some embodiments can be implemented using a machine-readable medium or article that can store instructions or instruction sets that, if executed by a machine, can cause the machine to perform methods and / or operations in accordance with the embodiments. Such a machine can include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, or the like, 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, writable or rewritable media, digital or analog media, hard disk, floppy disk, compact disc read only memory (CD-ROM), recordable compact disc (CD-R), rewritable compact disc (CD-RW), optical disc, magnetic media, magneto-optical media, removable memory card or disk, various types of digital versatile discs (DVD), magnetic tape, cassette tape, or the like. 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, and the like, which are implemented using any suitable high-level, low-level, object-oriented, visual, compiled, and / or interpreted programming language.

[0080] For purposes of illustration and description, the foregoing description of example embodiments has been presented. 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. It is intended that the scope of the disclosure not be limited by this detailed description, but rather be defined by the claims appended hereto. Future filed applications claiming priority to this application may claim the disclosed subject matter in a different manner and can generally include any collection of one or more limitations, as disclosed herein in various ways or otherwise evidenced.

Claims

1. An apparatus, comprising: Processor circuit; and a memory storing instructions which, when executed by the processor circuit, cause the processor circuit to perform the following operations: A first application executing on the processor circuit outputs a payment form, which includes an account number field, an expiration date field, and a card verification value (CVV) field; An operating system (OS) executing on the processor circuit receives a uniform resource locator (URL) from a communication interface of a contactless card, the URL including encrypted data generated by the contactless card at least partially based on a private key for the contactless card stored in a memory of the contactless card; A second application is executed on the processor circuit, and the second application is received by the OS from the URL; The second application sends the encrypted data to an authentication server, and the authentication server verifies the encrypted data by decrypting the encrypted data at least partially based on a private key for the contactless card stored in a memory of the authentication server; Based on the verification of the encrypted data by the authentication server, the second application receives a virtual account number from a virtual account server; The second application receives an expiration date associated with the virtual account number and a CVV associated with the virtual account number; The second application provides the virtual account number, the expiration date, and the CVV to an autofill service of the OS; and The autofill service of the OS autofills the virtual account number into the account number field, autofills the expiration date into the expiration date field, and autofills the CVV into the CVV field.

2. The apparatus according to claim 1, wherein, The first application includes at least one of the following: (i) a web browser, (ii) a native OS application, and (iii) an application available in an app store, wherein the second application includes at least one of the following: (i) a progressive web application executed in the web browser, (ii) an instant application, and (iii) an application available outside the app store, and the second application includes a subset of pages of an account management application, wherein the expiration date and the CVV include one or more of the following: (i) an expiration date and a CVV generated by the virtual account server, and (ii) an expiration date and a CVV of the contactless card received from an account database, wherein the memory stores instructions which, when executed by the processor circuit, cause the processor circuit to: Submit the form, which includes the virtual account number in the account number field, the expiration date in the expiration date field, and the CVV in the CVV field.

3. The apparatus according to claim 2, wherein the memory stores instructions that, when executed by the processor circuitry, cause the processor circuitry to perform the following operations: The OS sends at least one attribute of the OS to an application server hosting the second application at the URL; and The application server selects, based on the at least one attribute of the OS and the required functionality, one of the progressive web application and the instant application that is compatible with the OS and is configured to perform the required functionality; and The application server sends the selected one of the progressive web application and the instant application to the apparatus.

4. The apparatus according to claim 2, wherein the second application includes the progressive web application, and wherein the memory stores instructions that, when executed by the processor circuitry, cause the processor circuitry to perform the following operations: The OS receives the progressive web application in response to receiving the URL, wherein, The URL includes a universal link URL to the progressive web application; Execute the progressive web application in the web browser; The progressive web application determines to receive the instant application; Receive the instant application; and Execute the instant application in the OS, and the instant application: Receives the virtual account number, the expiration date, and the CVV; and Provides the virtual account number, the expiration date, and the CVV to the autofill service.

5. The apparatus according to claim 1, wherein the memory stores instructions that, when executed by the processor circuitry, cause the processor circuitry to perform the following operations: The second application receives a URL including the encrypted data, the encrypted data being encoded in an encoded format; The second application decodes the encrypted data into an unencoded format; and The second application sends the decoded encrypted data to the authentication server.

6. The apparatus according to claim 5, wherein an applet executes in the memory of the contactless card to: Generate the encrypted data; Encode the encrypted data according to the encoded format; and Generate a URL including the encrypted data encoded according to the encoded format.

7. The apparatus according to claim 1, wherein Provide the virtual account number, expiration date, and CVV to an application programming interface (API) of the autofill service, wherein the communication interface of the contactless card is configured to support at least one of near field communication (NFC), Bluetooth, and Wi-Fi.

8. A method, comprising: A first application executed on a processor circuit of a device outputs a payment form, which includes an account number field, an expiration date field, and a card verification value (CVV) field; An operating system (OS) executed on the processor circuit receives a uniform resource locator (URL) from a communication interface of a contactless card, which includes encrypted data generated by the contactless card based at least in part on a private key for the contactless card stored in a memory of the contactless card; A second application is executed on the processor circuit, and the second application is received by the OS from the URL; The second application sends the encrypted data to an authentication server, and the authentication server verifies the encrypted data by decrypting the encrypted data based at least in part on a private key for the contactless card stored in a memory of the authentication server; Based on the authentication server's verification of the encrypted data, the second application receives a virtual account number from a virtual account server; The second application receives an expiration date associated with the virtual account number and a CVV associated with the virtual account number; The second application provides the virtual account number, expiration date, and CVV to the autofill service of the OS; and The autofill service of the OS automatically fills the virtual account number into the account number field, the expiration date into the expiration date field, and the CVV into the CVV field.

9. The method according to claim 8, wherein The first application includes at least one of the following: (i) a web browser, (ii) a native OS application, and (iii) an application available in an app store, wherein the second application includes at least one of the following: (i) a progressive web application executed in the web browser, (ii) an instant application, and (iii) an application available outside the app store, and the second application includes a subset of pages of an account management application, wherein the expiration date and the CVV include one or more of the following: (i) an expiration date and a CVV generated by the virtual account server, and (ii) an expiration date and a CVV of the contactless card received from an account database, The method further includes: Submit the form, which includes the virtual account number in the account number field, the expiration date in the expiration date field, and the CVV in the CVV field.

10. The method according to claim 9, further comprising: The OS sends at least one attribute of the OS to an application server hosting the second application at the URL; And The application server selects, based on the at least one attribute of the OS and the required functionality, one of the progressive web application and the instant application that is compatible with the OS and is configured to execute the required functionality; and The application server sends the selected one of the progressive web application and the instant application to the device.

Images