Mobile Web Browser Authentication and Checkout Using Contactless Cards

Abstract

The browser's seller page can receive a selection of a first financial institution. The seller page can generate a Uniform Resource Identifier (URI) for the application. At least a portion of the URI can be registered with the application and the first financial institution in the mobile operating system. In response to receiving a selection of the URI, the mobile OS can launch the application, and the application can authenticate the account's credential information. The application can associate a user ID parameter and a session ID parameter with the account and can receive a ciphertext from the contactless card. The application can receive an indication from the server that the server has verified the ciphertext. The OS can launch the browser, and the browser can refresh the page. The refreshed page can include a virtual card number (VCN) in a first form field. A transaction can be processed based on the VCN.

Description

Background Art

[0001] The account identifier of a payment card can include long numbers and / or strings. Thus, it can be difficult for a user to manually enter the account identifier correctly. In fact, users often make mistakes and enter incorrect account numbers into the payment interface on a computing device. Further, processes have been developed that allow a camera or other malicious party to capture and identify the account identifier entered into the device, posing a security risk. Additionally, when online transactions are processed using conventional techniques, the transactions are treated as "card-not-present transactions", resulting in higher processing fees and an increased risk of fraud.

Summary of the Invention

[0002] System, method, apparatus, and computer-readable medium for authentication and checkout of a mobile web browser using a contactless card. In one aspect, the method includes receiving, by a seller web page within a web browser executing on a processor of a mobile device, a selection of a first financial institution from among a plurality of financial institutions, the seller web page including a plurality of form fields related to a transaction; generating, by the seller web page, a uniform resource identifier (URI) directed to an application, the URI including a seller identifier (ID) parameter, a session ID parameter associated with the transaction, a user ID parameter, and an action ID parameter, at least a portion of the URI being registered with the application and the first financial institution within a mobile operating system (OS) executing on the mobile device; in response to receiving a selection of the URI, launching, by the mobile OS, the application; authenticating, by the application, login credentials for an account associated with the first financial institution; associating, by the application, the user ID parameter and the session ID parameter with the account; receiving, by the application, a ciphertext from a contactless card associated with the account; receiving, by the application from a server, an indication that the server has verified the ciphertext; launching, by the mobile OS based on the indication, the web browser; refreshing, by the web browser, the seller web page, the refreshed seller web page including a virtual card number (VCN) in a first form field of the plurality of form fields; and processing, by the seller web page, the transaction based at least in part on the VCN of the first form field.

Brief Description of the Drawings

[0003] To easily identify the description of any particular element or act, the most significant digit or digits of the reference number refer to the number of the figure in which the element is first introduced.

Fig. 1A

Fig. 1B

Fig. 1C

Fig. 1D

Fig. 1E

Fig. 1F

Fig. 2A

Fig. 2B

Fig. 2C

Fig. 2D

Fig. 2E

Fig. 2F

Fig. 3

Fig. 4

Fig. 5

Fig. 6A

Fig. 6B

Fig. 7

Fig. 8

Best Mode for Carrying Out the Invention

[0004] The embodiments disclosed in this specification provide techniques for secure authentication and checkout in applications using contactless cards. For example, a user can use a mobile web browser on a mobile device to add one or more items to their shopping cart for purchase. On the checkout page, the user can select the option to use an automated checkout process. The user can select a first financial institution from a list of financial institutions presented by the web page. The web page can then generate a Uniform Resource Identifier (URI) directed to the application based on the selection. The application may be registered with the first financial institution in the mobile operating system (OS). The application may be an account management application provided by the first financial institution. The browser may include, as parameters of the URI, a seller identifier (ID) parameter, a user ID parameter, a session ID parameter, and an action ID parameter as parameters of the URI. The OS can process the URI to launch the application.

[0005] The application can process the URI parameters and determine to output the application's account authentication page based on the action ID. The authentication page can include one or more functions for authenticating the account via login / password, biometrics, etc. Once authenticated, the account application can associate a user ID and a session ID with the account (e.g., in an account database stored by the application and / or the server). Then, the application can instruct the user to tap their contactless card on the device, and upon tapping, the contactless card generates a ciphertext. The application can read the ciphertext and send the ciphertext to a server associated with a first financial institution for verification. Additionally, the application may send the URI parameters to the server.

[0006] Then, the server can verify the ciphertext (e.g., based at least in part on decrypting the ciphertext). Once verified, the server can generate a virtual card number (VCN), the expiration date of the VCN, and the card verification value (CVV) of the VCN. The server can limit the use of the VCN to a vendor associated with the transaction based on the vendor ID. Then, the server can send the VCN, CVV, expiration date, and contact information (e.g., the name, address, phone number, email address, etc. of the account holder) to a server associated with the vendor. The server can further send the session ID and user ID to the vendor server. In at least one embodiment, the vendor ID includes a URI directed to the vendor server. In other embodiments, the vendor server is identified based on the vendor ID.

[0007] The seller server can receive information from a server associated with a first financial institution and identify a browsing session based on the session ID and / or user ID. The seller server can then cause the information received from the server to be entered into one or more form fields on the checkout page. In some embodiments, the seller server can push these values to the mobile web browser. In other embodiments, the seller server causes the checkout page to be reloaded. When reloaded, the form fields can include payment information (e.g., VCN, expiration date, CVV) received from the server associated with the first financial institution as well as any other personal information (e.g., name, address, email address, phone number, etc.).

[0008] Furthermore, the server associated with the first financial institution can send the decryption result to the account application. The decryption result can indicate that the server verified (or decrypted) the ciphertext and generated the VCN. Based on the decryption result, the account application can return the device to the mobile web browser. The checkout page can be refreshed in the web browser (e.g., by the seller server and / or the mobile device). When refreshed, the payment information and personal information can be entered into the form on the web page. The user can then submit the form to process the payment in the web browser.

[0009] Advantageously, the embodiments disclosed herein provide a secure automated checkout process using a contactless card. By leveraging the cryptography generated by the contactless card, the embodiments of the present disclosure can minimize the risk of fraud and securely verify the identity of the user. Further, doing so ensures that the automated checkout is only executed when the user has access to the contactless card that facilitates the verification of the ciphertext at the server. Additionally, certain restrictions imposed on web browsers can be avoided. For example, some operating systems and / or web browsers may not allow the web browser to communicate directly with the account application. Thus, by using the VCN sent to the seller's backend, these restrictions can be overcome and the payment information for the purchase can be automatically imported into the web form. Further, by providing the disclosed automated functionality to the web browser, many different websites can utilize this functionality without the need for integration into all websites or applications. Still further, when a transaction is processed in accordance with the embodiments disclosed herein, the transaction is processed as a "card-present transaction" which has a lower transaction fee and a lower risk of fraud than a "card-not-present transaction", thereby reducing costs.

[0010] Reference is generally made to the notations and nomenclatures used in this specification, and one or more portions of the following detailed description may be presented with respect to program procedures executed on a computer or a network of computers. The descriptions and representations of these procedures are used by those skilled in the art to most effectively convey the substance of their work to other skilled persons. A procedure is here generally considered to be a self-consistent sequence of operations that brings about a desired result. These operations are those requiring physical manipulation of physical quantities. Although not necessarily so, usually these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It is clearly convenient at times, mainly for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc. However, it should be noted that all of these terms and similar terms are to be associated with appropriate physical quantities and are nothing more than convenient labels applied to those quantities.

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

[0012] Reference is now made to the drawings, in which like reference numerals are used throughout to refer to like elements. In the following description, numerous specific details are set forth in order to provide a thorough understanding. It will be apparent, however, 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 the description. The intention is to cover all modifications, equivalents, and alternatives falling within the scope of the claims of the patent.

[0013] FIG. 1A shows an exemplary computing architecture 100, also referred to as a system that harmonizes with the disclosed embodiments. The computing architecture 100 shown in FIGS. 1A - 1E has a limited number of elements in a specific connection configuration, but it will be understood that the computing architecture 100 may include more or fewer elements in alternative connection configurations as desired for a given implementation.

[0014] The computing architecture 100 includes one or more computing devices 102, one or more authentication servers 106, one or more contactless cards 104, and one or more vendor servers 108. The contactless card 104 represents any type of card such as a credit card, debit card, ATM card, gift card, payment card, smart card, etc. The contactless card 104 can include one or more communication interfaces 124, such as a radio frequency identification (RFID) chip configured to communicate with a communication interface 124 (also referred to herein as a "card reader", "wireless card reader", and / or "wireless communication interface") of the computing device 102 via NFC, EMV standards, or other short - range protocols in wireless communication. Although NFC is used as an exemplary communication protocol herein, the present disclosure is equally applicable to other types of wireless communication such as EMV standards, Bluetooth, and / or Wi - Fi.

[0015] Computing device 102 represents any number and type of computing devices such as smartphones, tablet computers, wearable devices, laptops, portable gaming devices, virtual computing systems, seller terminals, point-of-sale systems, servers, desktop computers, and the like. Although a mobile device can be used as an example of computing device 102, it should not be considered as limiting the present disclosure. Authentication server 106 and seller server 108 represent any type of computing device such as a server, workstation, computing cluster, cloud computing platform, virtual computing system, and the like. Although not shown for clarity, each of computing device 102, contactless card 104, authentication server 106, and seller server 108 includes, for example, one or more processor circuits for executing programs, code, and / or instructions.

[0016] As shown, memory 110 of contactless card 104 includes applet 112, counter 114, master key 116, diversification key 118, and unique customer identifier (ID) 120. Applet 112 is executable code configured to perform the operations described herein. Counter 114, master key 116, diversification key 118, and customer ID 120 are used to provide security to system 100 as will be described in more detail below.

[0017] As shown in the illustration, the memory 126 of the authentication server 106 includes an authentication application 128 and an account database 130. The account database 130 generally includes information regarding account holders (e.g., one or more users), one or more accounts of the account holders, and one or more contactless cards 104 of the accounts. For each contactless card associated with a financial institution associated with the authentication server 106, the authentication server 106 can store corresponding instances of the master key 116 and the counter 114.

[0018] As shown, the memory 134 of the computing device 102 includes an instance of an operating system 136. Examples of operating systems include the Android (registered trademark) OS, iOS (registered trademark), macOS (registered trademark), Linux (registered trademark), and Windows (registered trademark) operating systems. As shown, the operating system 136 includes an account application 138 and a web browser 140. The account application 138 enables a user to perform various account-related operations such as activation of a payment card, viewing of account balance, purchase of goods, processing of payments, etc. In some embodiments, the user can authenticate using authentication credentials to access specific functions of the account application 138. For example, the authentication credentials can include a username (or login) and password, biometric credentials (e.g., fingerprint, Face ID, etc.). The web browser 140 is an application that enables the computing device 102 to access information via a network 154 (e.g., via the Internet). For example, using the web browser 140, the user can access one or more resources of the seller server 108, such as a web page 142 stored in the memory 152 of the seller server 108, which may be one of a plurality of web pages hosted by the seller server 108 (or another hosting entity). Although a web browser is used herein as an example, the techniques of the present disclosure are equally applicable to other types of applications (e.g., a dedicated shopping application provided by a seller, other types of applications, etc.).

[0019] More generally, when accessing a web page provided by the seller server 108, a user can select one or more products, services, or other items for purchase via the web browser 140. For example, the user may wish to purchase a basketball and a soccer ball and can add those items to the shopping cart. To complete the purchase, the web page 142 can include a form having one or more payment fields. The payment fields can include fields such as account number, expiration date, CVV, customer name, customer billing address, customer email address, customer phone number, and the like. However, certain restrictions can prevent the autofill of data into these payment fields. For example, the OS and / or the web browser 140 may restrict the account application 138 from providing data to be autofilled into the form. Also, the user may not have an account with the seller server 108. Advantageously, however, the embodiments disclosed herein provide a solution for overcoming these restrictions using an automatic checkout process.

[0020] In some embodiments, the web page 142 can include selectable elements for initiating an automated checkout process. In some embodiments, a seller can provide an automated checkout process for one or more of a plurality of financial institutions. Thus, if multiple financial institutions are supported, the web page 142 can present a list of financial institutions to the user when a selectable element is selected. The user can then select a financial institution (e.g., the financial institution that issued the contactless card 104) from the list. By doing so, the web page 142 and / or the web browser 140 can generate a Uniform Resource Identifier (URI) 144. At least a portion of the URI 144 can be directed to the account application 138 based on the account application 138 registered with the OS. Examples of the URI 144 and / or a portion thereof can include "example: / / automatedcheckout" or "www.example.com / automatedcheckout". Further, the URI 144 can include one or more parameters. The parameters can include a seller ID parameter, a user ID parameter, a session ID parameter, and an action ID parameter. If only one financial institution is supported, the user does not need to select that institution as a condition for generating the URI 144. The web page 142 and / or the web browser 140 can then provide the URI 144 to the operating system 136 for processing. In some embodiments, the URI 144 is displayed and selected by the user before being provided to the operating system 136.

[0021] The seller ID parameter may be associated with the seller providing the web page 142 and / or the seller server 108. Thus, the account application 138 can uniquely identify each of the plurality of sellers using the respective seller ID parameter of the plurality of seller ID parameters. By doing so, the account application 138 can identify the address of the seller server 108 associated with the seller ID and / or further identify the address of any web page 142 associated with the seller ID. The user ID parameter may be a unique identifier of the user associated with the browsing session. Since the user may not be logged in and / or may not have an account with the seller server 108, the user ID can uniquely identify the user. The session ID parameter can identify the browsing session in the web browser 140 with respect to the seller server 108. For example, the session ID parameter can be used to identify a shopping cart, previously visited pages, the current page displayed in the web browser 140 (e.g., the web page 142), and so on. The action ID can generally specify an action or operation to be performed by the account application 138. For example, in some embodiments, the action ID can instruct the account application 138 to open an authentication page and / or an automated checkout page for an automated checkout process. Thus, the URI 144 may be a deep link to one or more pages of the account application 138. Examples of the URI 144 can include "example: / / automatedcheckout?merchID=123&sessID=ABC&userID=XYZ&actID=456" or "www.example.com / ?merchID=123&sessID=ABC&userID=XYZ&actID=456". In some embodiments, the URI 144 may be an Android Universal Link or an Apple® App Link.

[0022] In some embodiments, the operating system 136, web browser 140, and / or web page 142 can determine whether the account application 138 is installed on the computing device 102. The operating system 136, web browser 140, and / or web page 142 can use any practicable technique to determine whether the account application 138 is installed. For example, in iOS, the operating system 136, web browser 140, and / or web page 142 can use the canOpenURL() method to determine whether it can open a URI directed to the account application 138. This method can generally return an indication of whether the URI can be opened. By doing so, the operating system 136, web browser 140, and / or web page 142 can determine that the account application 138 is installed on the computing device 102.

[0023] In some operating systems such as Android OS, the operating system 136, web browser 140, and / or web page 142 can use a content provider service to determine whether the account application 138 is installed on the device. For example, the operating system 136, web browser 140, and / or web page 142 can provide a URI directed to the account application 138 to the content provider service, and the content provider service can return an indication of whether the URI can be opened. By doing so, the operating system 136, web browser 140, and / or web page 142 can determine that the account application 138 is installed on the computing device 102.

[0024] If the account application 138 is not installed on the device 102, the operating system 136 can download and install the account application 138 on the device 102. In some embodiments, the account application 138 can be an instant application, an app clip, a progressive web application, or any other non-persistent application. In other embodiments, a persistent version of the account application 138 is installed from an application store on the computing device 102.

[0025] Using the account application 138 available on the computing device 102, the OS can process the URI 144, whereby the OS can open, access, launch, or display the account application 138. By doing so, the URI 144 including parameters is further provided to the account application 138. Based on the action ID parameter of the URI 144, the account application 138 can open an account authentication page to facilitate the autofill technology described herein.

[0026] In some embodiments, the operating system 136, the web browser 140, and / or the web page 142 can determine whether the account application 138 is installed on the computing device 102 prior to providing a selectable element for initiating an automatic checkout and / or generating the URI 144. In such embodiments, if the account application 138 is not installed on the computing device 102, the web page 142 and / or the web browser 140 may refrain from providing the selectable element and / or the automatic checkout process. Similarly, in some embodiments, if the account application 138 is not installed on the computing device 102, the web browser 140 and / or the web page 142 may refrain from generating the URI 144.

[0027] As described above, in some embodiments, the account application 138 may not be installed on the computing device 102. Thus, in some embodiments, the web page 142 can encode a graphical representation of the URI 144 (including the seller ID parameter, user ID parameter, and session ID parameter) that can be displayed on the web page 142. The graphical representation can generally be used to initiate the autofill techniques described herein without requiring the user to select the URI 144 and / or select a financial institution from a list. The graphical representation can include a matrix code (also referred to as a matrixed code, matrix barcode, etc.). Examples of matrix codes include, but are not limited to, Quick Response (QR) codes, app clip codes, etc. Thus, in such embodiments, a camera (not shown) or other optical reader of the computing device 102 can detect, for example, a matrix code encoding the URI 144 within one or more images. When the matrix code is detected, the operating system 136, web browser 140, and / or web page 142 can decrypt the URI 144 and determine whether the account application 138 is installed on the computing device 102 based on the URI 144 as described herein. If the account application 138 is not installed on the computing device 102, the OS 136 can download the account application 138 and install the account application 138 on the computing device 102. In some embodiments, the account application 138 is downloaded based on approval input received from the user. As described above, the downloaded application can include a persistent or non-persistent (e.g., instant application, app clip, progressive web application, etc.) version of the account application 138.Thereafter, the downloaded account application 138 may be accessed, launched, or displayed. As described above, the parameters of the URI 144 may be provided to the account application 138 that opens the account authentication page to facilitate the autofill techniques described herein. Embodiments are not limited to these contexts.

[0028] FIG. 1B shows an embodiment in which the OS accesses the URI 144 and the account application 138 loads the account authentication page. As described above, the URI 144 may be accessed based on the selection of the URI 144 and / or based on the detection of a graphical representation (e.g., a matrix code) of the URI 144 by the camera. Generally, the account authentication page enables the user to authenticate their account, for example, via login and password, biometrics, etc. The account application 138 and / or the authentication server 106 can authenticate the received authentication credentials.

[0029] Once authenticated, the account application 138 can associate the user ID parameter and the session ID parameter of the URI 144 with the authenticated account (and / or send the user ID parameter and the session ID parameter to the authentication server 106 for association with the account). The account application 138 can then instruct the user to tap the contactless card 104 on the computing device 102 (or bring the contactless card 104 within the communication range of the communication interface 124 of the device 102). By doing so, the applet 112 of the contactless card 104 can generate the ciphertext 122.

[0030] The ciphertext 122 may be based on the customer ID 120 of the contactless card 104. The ciphertext 122 may be generated based on any suitable encryption technique. In some embodiments, the applet 112 may include an identifier (e.g., the customer ID 120, the identifier of the contactless card 104, and / or any other unique identifier) that is not encrypted as part of a data package that includes the ciphertext 122. In at least one embodiment, the data package is an NDEF file.

[0031] As described above, the computing architecture 100 is configured to implement key diversification to protect data that can be referred to herein as key diversification techniques. Generally, the same master key 116 (also referred to as a master symmetric key) is provided to the authentication server 106 (or another computing device) and the contactless card 104. More specifically, each contactless card 104 is programmed with a separate master key 116 that has a corresponding pair within the authentication server 106. For example, when the contactless card 104 is manufactured, a unique master key 116 can be programmed into the memory 110 of the contactless card 104. Similarly, the unique master key 116 can be stored in the customer record associated with the contactless card 104 within the account database 130 of the authentication server 106 (and / or in a different secure location such as a hardware security module (HSM) 132). The master key 116 may be kept secret from all parties other than the contactless card 104 and the authentication server 106, thereby enhancing the security of the system 100. In some embodiments, the applet 112 of the contactless card 104 can use the master key 116 and data as inputs to an encryption algorithm to encrypt and / or decrypt data (e.g., the customer ID 120). For example, the customer ID 120 can be encrypted with the master key 116 to obtain the ciphertext 122. Similarly, the authentication server 106 can encrypt and / or decrypt data related to the contactless card 104 using the corresponding master key 116.

[0032] In some embodiments, the master key 116 of the contactless card 104 and the authentication server 106 can be used with the counter 114 to enhance security using key diversification. The counter 114 includes a value synchronized between the contactless card 104 and the authentication server 106. For example, the counter 114 can include a number that changes each time data is exchanged between the contactless card 104 and the authentication server 106 (and / or between the contactless card 104 and the computing device 102). Generally, the applet 112 can generate the diversified key 118 by providing the master key 116, the unique customer ID 120, and a diversification factor as inputs to an encryption algorithm. In some embodiments, the diversification factor is the counter 114. The diversified key 118 can then be used to encrypt some data such as the diversification factor (e.g., the counter 114) or other confidential data. The applet 112 and the authentication server 106 may be configured to encrypt the same type of data to facilitate the decryption and / or verification process of the ciphertext 122.

[0033] More generally, when preparing to send data (e.g., to authentication server 106 and / or computing device 102), applet 112 of contactless card 104 can increment counter 114. Next, applet 112 of contactless card 104 can provide master key 116, customer ID 120, and counter 114 as input to the cryptographic algorithm, and the cryptographic algorithm generates diversified key 118 as output. The cryptographic algorithm can include an encryption algorithm, a hash-based message authentication code (HMAC) algorithm, a cipher-based message authentication code (CMAC) algorithm, etc. Non-limiting examples of the cryptographic algorithm can include symmetric encryption algorithms such as 3DES or AES107, symmetric HMAC algorithms such as HMAC-SHA-256, and symmetric CMAC algorithms such as AES-CMAC. Examples of key diversification techniques are described in more detail in U.S. Patent Application No. 16 / 205,119, filed on November 29, 2018. The above-mentioned patent application is hereby incorporated by reference in its entirety.

[0034] Next, applet 112 can use diversified key 118 and data as input to the cryptographic algorithm to encrypt some data (e.g., unique customer ID 120, counter 114, command, and / or any other data). For example, encrypting unique customer ID 120, diversified key 118 can result in encrypted unique customer ID 120 (e.g., ciphertext 122).

[0035] In some embodiments, for example, based on one or more portions of the input to the cryptographic function, two diversification keys 118 can be generated. In some embodiments, the two diversification keys 118 are generated based on two different master keys 116, a unique customer ID 120, and a counter 114. In such embodiments, a message authentication code (MAC) is generated using one of the diversification keys 118, and the MAC may be encrypted using the other of the diversification keys 118. The MAC may be generated based on confidential data, the unique customer ID 120, the counter 114, and any other appropriate data input to the MAC algorithm. More generally, the applet 112 and the authentication server 106 may be configured to generate the MAC based on the same data. In some embodiments, the ciphertext 122 is included in a data package such as an NDEF file. The account application 138 can then read the data package containing the ciphertext 122 via the communication interface 124 of the computing device 102.

[0036] FIG. 1C shows an embodiment in which the account application 138 sends a data package containing the ciphertext 122 to the authentication server 106. As shown, the account application 138 can further send URI parameters 146 to the authentication server 106. The URI parameters 146 can include a vendor ID parameter, a user ID parameter, and a session ID parameter. The authentication server 106 can then associate the user ID and session ID with an account in the account database 130 (if not already done).

[0037] The authentication server 106 can provide the ciphertext 122 to the authentication application 128 and / or the HSM 132 for verification based at least in part on an instance of the master key 116 stored in the authentication server 106. In some embodiments, the authentication application 128 and / or the HSM 132 can identify the master key 116 and the counter 114 using the unencrypted customer ID 120 provided to the server 106 along with the ciphertext 122. In some examples, the authentication application 128 can provide the master key 116, the unique customer ID 120, and the counter 114 as inputs to a cryptographic algorithm that outputs one or more diversified keys 118. The resulting diversified key 118 can correspond to the diversified key 118 of the contactless card 104 that can be used to decrypt the ciphertext 122 and / or verify the decrypted MAC. For example, the authentication server 106 can generate a MAC based on the same data as the applet 112, such as, for example, confidential data, the unique customer ID 120, and / or the counter 114. If the MAC generated by the authentication server 106 matches the decrypted MAC within the ciphertext 122, the authentication server 106 can verify or authenticate the ciphertext 122.

[0038] Regardless of the verification technique used, the authentication application 128 and / or the HSM 132 can verify or authenticate the ciphertext 122 by successfully decrypting the ciphertext 122 and verifying the MAC.

[0039] If the decryption is successful, the authentication application 128 can send a decryption result indicating that the server has decrypted and / or verified the ciphertext 122 to the account application 138. Further, the authentication server 106 can generate a VCN, expiration date, and CVV for the transaction. The VCN is generally a disposable account number associated with the account, but the VCN is different from the account number of the contactless card 104. The authentication server 106 may restrict the use of the VCN to the seller (e.g., based on the seller ID). By doing so, it is ensured that the VCN can only be used to process payments with the seller. For example, if different sellers request to process transactions using the VCN or if the user requests to process transactions with different sellers using the VCN, the server can reject these transactions. Further, the authentication server 106 can impose time limits, quantity limits, location limits, etc. on the VCN. The authentication server 106 can reject transactions that do not comply with these limits. The authentication server 106 can then send the VCN, expiration date, and CVV to the seller server 108. Further, the authentication server 106 can send the session ID, user ID, and contact information (e.g., username, billing address, shipping address, email address, phone number, etc.) to the seller server 108.

[0040] However, if the authentication application 128 cannot decrypt the ciphertext 122 to obtain the expected result (e.g., the customer ID 120 of the account associated with the contactless card 104), the authentication application 128 does not verify the ciphertext 122. In such an example, the authentication application 128 decides to end the automatic checkout process. The authentication application 128 can send an indication of decryption failure to the computing device 102.

[0041] FIG. 1D shows an embodiment in which the authentication application 128 sends the decryption result 148 to the account application 138 and sends the payment information 150 to the seller server 108. The decryption result 148 generally reflects whether the ciphertext 122 has been decrypted. In the example shown in FIG. 1D, the decryption result 148 can indicate the authentication server 106 that has decrypted or verified the ciphertext 122. By doing so, the account application 138 can determine that the ciphertext 122 has been successfully decoded and / or verified before continuing with the autofill process, thereby improving security.

[0042] The payment information 150 can generally include a VCN, the expiration date of the VCN, the CVV of the VCN, a session ID, a user ID, and the user's contact information (e.g., username, billing address, shipping address, email address, phone number, etc.). In some embodiments, the URI 144 can include an indication of the address of the seller server 108 as a parameter. Thereby, the authentication server 106 can send the payment information 150 to the seller server 108 based on the address. In other embodiments, the authentication server 106 can store a list of addresses of multiple different sellers where each entry is indexed by a respective seller ID. In such an example, the authentication server 106 can identify the address of the seller server based on the seller ID within the URI 144.

[0043] Once received, the seller server 108 can identify the user's browsing session based on the user ID and / or session ID. By doing so, the seller server 108 can enter, input, or fill in the received payment information 150 into one or more form fields of the web page 142 corresponding to the session ID and / or user ID. For example, the seller server 108 can enter the VCN into the card number form field, the expiration date into the expiration date form field, and the CVV into the CVV form field. More generally, the seller server 108 can store the payment information 150 for later use.

[0044] In response to receiving the decryption result 148, the account application 138 can return the computing device 102 to the web browser 140. For example, the account application 138 can instruct the operating system 136 to launch the web browser 140. As another example, the account application 138 can output a selectable element directed to the web browser 140 that causes the operating system 136 to launch the web browser 140 upon selection.

[0045] In some embodiments, the user may not return to the web browser 140 within the threshold time and may further or alternatively not complete a purchase using the VCN. The time may be measured based on the time point of VCN generation. In such embodiments, the authentication server 106 and / or the seller server 108 can send a notification to the computing device 102 that can remind the user to complete a purchase using the VCN. The notification can include a push notification, an email, a text message, etc. Accordingly, the authentication server 106 and the seller server 108 can exchange timing information (e.g., to determine whether the time threshold has been exceeded), indicate whether the purchase has been completed, and communicate to cause the sending of a notification to the computing device 102.

[0046] FIG. 1E shows an embodiment in which the web page 142 is refreshed to include payment information 150 in a form field of the web page 142. The web page 142 may be refreshed according to any technique. For example, the user can refresh the web page 142 in the web browser 140, whereby the seller server 108 sends the web page 142 including the payment information 150 entered in the form field. As another example, the seller server 108 can automatically reload the web page 142 to the web page 142, such as a server-initiated refresh. As yet another example, the seller server 108 may send executable instructions (e.g., JavaScript, etc.) to the web browser 140 to update the web page 142 to include the payment information 150 in the form field.

[0047] Regardless of the technology used to refresh web page 142, once refreshed, web page 142 includes payment information 150 automatically entered into form fields. For example, the account number field can include a VCN, the expiration date field can include an expiration date, the CVV field can include a CVV, one or more name fields can include the name of the account owner, the billing address field can include the account billing address, the email field can include the account email address, the phone number field can include the account phone number, and so on.

[0048] Furthermore, the refreshed web page 142 further maintains the browsing session from web browser 140. For example, web page 142 including a payment form can be rendered within web browser 140, enabling the user to purchase one or more items previously added to their shopping cart within web browser 140. Continuing with the above example, web browser 140 can load web page 142 reflecting the user's shopping cart including a basketball and a soccer ball.

[0049] Advantageously, payment information 150 is automatically entered into one or more payment fields of web page 142 upon refresh. The user can optionally modify the information entered into the form fields. The user can then submit the form including payment information 150 to complete the purchase.

[0050] FIG. 1F shows an embodiment in which web browser 140 and / or web page 142 generates a transaction package 156 for processing a payment using payment information 150 entered in a form field of web page 142. Generally, transaction package 156 may be sent according to the Hypertext Transfer Protocol (HTTP). When received, seller server 108 can process the payment for the transaction using payment information 150. Since the VCN is associated or limited to the seller, authentication server 106 can approve the transaction based at least in part on the VCN used as payment for the transaction with the seller. Next, seller server 108 can create a transaction record 160 regarding the transaction in transaction database 158. Thereafter, a confirmation of the transaction may be displayed on web browser 140.

[0051] Since the transaction is processed using a VCN generated by authentication server 106, even if the transaction is conducted online, the transaction can be processed as a “card-present transaction”. Advantageously, doing so reduces the transaction processing fee and further reduces the risk of fraud. Thus, in some embodiments, a seller can offer a discount (e.g., a rebate, a price reduction, etc.) for a purchase completed using the automated mobile web authentication and checkout process disclosed herein. Embodiments are not limited to these contexts.

[0052] In some embodiments, the seller server 108 can enable the user to create an account after (or even simultaneously with) the completion of the purchase. In such embodiments, the seller server 108 can create an account based at least in part on the account owner name and contact information (e.g., address, phone number, email address, etc.) received from the authentication server 106. In some embodiments, the seller server 108 can further create an account using the user ID parameter of the URI 144 to identify the user. The user can further provide any other additional information (e.g., login / password, biometrics, other attributes, etc.) to create the account.

[0053] In some embodiments, by storing the payment information 150, the seller server 108 does not need to use the payment information 150 within the transaction package 156 to process the transaction. Instead, in such embodiments, the seller server 108 processes the transaction based on the stored payment information 150, and the transaction package 156 functions as the user's consent to use the stored payment information 150 to process the purchase. However, if the user edits any of the payment information 150 presented on the web page 142, the seller server 108 can process the transaction using the payment information 150 edited by the user.

[0054] FIG. 2A is a schematic diagram 210 showing an exemplary embodiment of automatic mobile web browser authentication and checkout using a contactless card. As shown, FIG. 3A shows a mobile computing device 102 executing a web browser 140. The web browser 140 can display a web page such as web page 142. For example, the web page 142 may be a web page that enables a user to place an order and provide payment information regarding the order via one or more form fields. As shown, the web page 142 includes a payment form having fields 201-207, where field 201 is a name field, field 202 is an account number field, field 203 is an expiration date field, field 204 is a CVV field, field 205 is an address field, field 206 is an email address field, and field 207 is a phone number field.

[0055] The web page 142 further includes a selectable element 208 that enables the user to initiate an automatic checkout process for server-side entry of payment information into the form fields 201-207. Embodiments are not limited to this context.

[0056] FIG. 2B is a schematic diagram 210 showing an embodiment in which the user selects the element 208 to initiate the automatic checkout process. As shown, the web page 142 prompts the user to select a financial institution from a list of financial institutions that support automatic checkout. The user can then select one of the financial institutions from the list. By doing so, the web browser 140 can generate a URI (e.g., URI 144) directed to the account application 138, whereby the computing device 102 opens or displays the account application 138. The parameters of the URI can include a vendor ID, a user ID, a session ID, and an action ID.

[0057] Figure 2C is a schematic diagram 220 showing an embodiment in which a URI is accessed and an account application 138 is loaded onto a computing device 102. Based on the parameters of the URI (e.g., action ID), the account application 138 outputs an authentication page that requests the user to authenticate their account using a login / password for an automatic checkout process. For example, the user can enter a username in field 221, enter a password in field 222, and select a submit button 223 to submit the username and password for verification. The account application 138 can then authenticate the credentials (or further / alternatively, send the credentials to an authentication server 106 for authentication).

[0058] Figure 2D is a schematic diagram 230 reflecting an embodiment in which the user successfully logs into their account. Once authenticated, the account application 138 and / or the authentication server 106 can associate a user ID and a session ID with the authenticated account (e.g., by storing an association instruction in the account database 130). In some embodiments, the account application 138 includes an instance of the account database 130. The account application 138 can then instruct the user to tap the contactless card 104 on the computing device 102.

[0059] Next, the user can tap the contactless card 104 on the computing device 102. Thereby, the contactless card 104 generates a ciphertext to be verified by the authentication server 106. As shown in the figure, the authentication server 106 verifies the ciphertext. By doing so, the authentication server 106 can generate payment information (e.g., VCN, expiration date, CVV, name, address, contact information, session ID, user ID, etc.) and send it to the seller server 108. By doing so, the seller server 108 can associate the payment information with the user ID and / or session ID. Further, the seller server 108 can perform the entry of the payment information into the form fields of the web page 142 started by the server.

[0060] The authentication server 106 can further send an instruction to the account application 138 specifying that the server has verified the ciphertext, a VCN has been generated, and the VCN has been sent to the seller server 108 along with other information. Thereafter, the account application 138 can cause the operating system 136 to resume to the web browser 140, or bring the web browser 140 to the front of the computing device 102. For example, the account application 138 can determine a URI for the web browser 140 based on the seller ID parameter and / or action ID parameter. By doing so, the account application 138 can cause the computing device 102 to resume to the web browser 140 to complete the automatic checkout.

[0061] FIG. 2E is a schematic diagram 240 showing a web page 142 including data entered in form fields 201-207 by the seller server 108. As shown, the user's name is entered in the name field 201, the VCN is entered in the account number field 202, the expiration date is entered in the expiration date field 203, the CVV is entered in the CVV field 204, the address is entered in the address field 205, the email address is entered in the email address field 206, and the phone number is entered in the phone number field 207.

[0062] Next, the user can complete the purchase using the submit button, whereupon the seller server 108 processes the payment using the VCN and related data. In some embodiments, the user can edit the information entered in form fields 201-207. The embodiments are not limited to this context.

[0063] FIG. 2F is a schematic diagram 250 showing a confirmation web page 142 within the web browser 140. The confirmation page generally reflects that the purchase has been completed using the VCN and related data automatically entered in form fields 201-207.

[0064] Since the transaction is processed using the VCN generated by the authentication server 106, even if the transaction is conducted online, the transaction can be processed as a "card present transaction". Advantageously, doing so reduces the transaction processing fee and further reduces the risk of fraud. The embodiments are not limited to this context.

[0065] The operations of the disclosed embodiments can be further described with reference to the following figures. Some of the drawings can include a logical flow. Such figures presented herein can include a particular logical flow, but it should be understood that the logical flow only provides an example of how the overall functions described herein can be implemented. Further, unless otherwise indicated, a given logical flow need not be executed in the order presented. Further, in some embodiments, not all of the operations shown in the logical flow are required. Further, a given logical flow may be implemented by hardware elements, software elements executed by a processor, or any combination thereof. Embodiments are not limited to this context.

[0066] Figure 3 shows an embodiment of a logical flow or routine 300. The logical flow 300 can represent some or all of the operations performed by one or more of the embodiments described herein. For example, the logical flow 300 can include some or all of the operations for secure authentication and checkout in the mobile web browser 140 that uses the contactless card 104. Embodiments are not limited to this context.

[0067] In block 302, routine 300 receives a selection of a first financial institution among a plurality of financial institutions by a seller web page 142 within a web browser 140 that is executed on a processor of the mobile computing device 102, where the seller web page 142 includes a plurality of form fields related to a transaction. In block 304, routine 300 generates a URI 144 directed to an application such as the account application 138 by the seller web page 142. The URI 144 can include a seller identifier (ID) parameter, a session ID parameter associated with the transaction, a user ID parameter, and an action ID parameter, and at least a portion of the URI is registered with the account application 138 within the mobile operating system 136 that is executed on the mobile device and the first financial institution.

[0068] In block 306, routine 300 launches account application 138 by mobile operating system 136 in response to receiving the selection of URI 144. In block 308, routine 300 authenticates the login qualification information of the account associated with the first financial institution by account application 138. In block 310, routine 300 associates the user ID parameter and the session ID parameter with the account by account application 138. In block 312, routine 300 receives a ciphertext (e.g., ciphertext 122) from contactless card 104 associated with the account by account application 138. In block 314, routine 300 receives an instruction from authentication server 106 by account application 138 specifying that authentication server 106 has verified ciphertext 122. In block 316, routine 300 launches web browser 140 by mobile operating system 136 based on the instruction. In block 318, routine 300 refreshes seller web page 142 by web browser 140. The refreshed seller web page 142 includes a virtual card number (VCN) in a first form field among a plurality of form fields. The remaining form fields can include other attributes such as expiration date, CVV, and customer contact information (e.g., name of the account holder, address, phone number, email address, etc.). In block 320, routine 300 processes a transaction by seller web page 142 based at least in part on the VCN within the first form field.

[0069] FIG. 4 shows one embodiment of a logical flow or routine 400. 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 400 can include some or all of the operations for secure authentication and checkout in the mobile web browser 140 that uses the contactless card 104. Embodiments are not limited to this context.

[0070] In block 402, the routine 400 generates a URI 144 directed to the account application 138 by the seller web page 142. The URI 144 includes a session identifier (ID), a seller ID, an action ID, and a user ID associated with the transaction. At least a portion of the URI 144 is registered within an application and a financial institution in the mobile operating system 136 running on the mobile computing device 102. The seller web page 142 includes a plurality of form fields associated with the transaction. In block 404, the routine 400 launches the account application 138 by the mobile operating system 136 based on the selection of the URI 144. In block 406, the routine 400 associates the user ID and the session ID with the account by the account application 138 based on the account qualification information.

[0071] In block 408, routine 400 transmits, by account application 138, the seller ID, session ID, user ID, and ciphertext 122 received by account application 138 from contactless card 104 to authentication server 106. In block 410, routine 400 receives, by account application 138 from authentication server 106, an instruction specifying that authentication server 106 has verified ciphertext 122. In block 412, routine 400 generates, by authentication server 106, based on the verification of ciphertext 122, a virtual card number (VCN), an expiration date associated with the VCN, and a card verification value (CVV) associated with the VCN, and authentication server 106 restricts the use of the VCN to the seller and / or seller server 108 based on the seller ID. In block 414, routine 400 transmits, by authentication server 106, to seller server 108 associated with the web page, based on the seller ID, verification of the ciphertext, and authentication of the qualification information, the VCN, expiration date, CVV, account owner name, and contact information (e.g., address, phone number, email address, etc.). In block 416, routine 400 refreshes, by web browser 140, seller web page 142, and the refreshed seller web page 142 includes the VCN, expiration date, CVV, account owner name, and contact information in each of a plurality of form fields. In block 418, routine 400 submits a transaction, by seller web page 142, based at least in part on the VCN, expiration date, CVV, account owner name, and contact information within the form fields.

[0072] Figure 5 shows one embodiment of a logical flow or routine 500. Logical flow 500 can represent some or all of the operations performed by one or more embodiments described herein. For example, logical flow 500 can include some or all of the operations for secure authentication and checkout in a dedicated seller application that uses contactless card 104. The embodiments are not limited to this context.

[0073] As described above, the web browser 140 represents any kind of application. Thus, FIG. 5 reflects an embodiment in which an application dedicated to secure authentication and checkout using the contactless card 104 is used. In block 502, routine 500 receives a selection of a first financial institution among a plurality of financial institutions by a first application executed on a processor of the mobile device. In block 504, routine 500 generates, by the first application, a uniform resource identifier (URI) directed to a second application, and at least a portion of the URI is registered with the second application and the first financial institution in a mobile operating system (OS) executed on the mobile device. The URI can include parameters of the URI 144 such as, for example, a user ID, a session ID, a seller ID, and / or an action ID.

[0074] In block 506, routine 500 launches a second application by the mobile OS based on the URI. In block 508, routine 500 receives a ciphertext from a contactless card associated with the account by the second application. The second application can send the ciphertext and any URI parameters to a first server associated with the issuer of the contactless card. In block 510, routine 500 generates a virtual card number (VCN), the expiration date of the VCN, and the card verification value (CVV) of the VCN by the first server based on the verification of the ciphertext. In block 512, routine 500 sends the VCN, expiration date, CVV, and contact information of the account associated with the contactless card by the first server to a second server associated with the vendor providing the first application. The first server can further send the user ID, session ID, vendor ID, and / or action ID to the second server. In block 514, routine 500 generates an account with the vendor by the second server based on the VCN, expiration date, CVV, and contact information. By doing so, the second server can store payment information for later use. In block 516, routine 500 processes a transaction regarding the account with the vendor by the second application based at least in part on the stored VCN, expiration date, and CVV. For example, at a later point in time, the user can log in to their account with the vendor in the first application. The user can specify in the first application to purchase a sandwich from the vendor. Without the need to provide payment information to the first application, the vendor can process the purchase of the sandwich using the stored VCN, expiration date, CVV associated with the account.

[0075] FIG. 6A is a schematic diagram 600 showing an exemplary configuration of a contactless card 104 that can include a payment card such as a credit card, debit card, or gift card. The contactless card 104 is issued by a service provider and is displayed as a service provider's mark 602 on the front or back of the contactless card 104. In some examples, the contactless card 104 is not related to a payment card and is not limited thereto, but can include an identity card. In some examples, the transaction card can include a dual interface contactless payment card, a reward card, and the like. The contactless card 104 can include a substrate 604 that can include a single layer or one or more laminates composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 104 may have physical characteristics compliant with the ID-1 format of the ISO / IEC 7816 standard, or the transaction card may comply with the ISO / IEC 14443 standard. However, it is understood that the contactless card 104 according to the present disclosure can have various characteristics, and the present disclosure does not require implementing the transaction card as a payment card.

[0076] Furthermore, the contactless card 104 can include identification information 606 displayed on the front and / or back of the card, and contact pads 608. The contact pads 608 may include one or more pads and may be configured to establish contact with another client device such as an ATM, a user device, a smartphone, a laptop, a desktop, or a tablet computer by a transaction card. The contact pads may be designed according to one or more standards such as the ISO / IEC 7816 standard and can enable communication according to the EMV protocol. Furthermore, the contactless card 104 can include a processing circuit, an antenna, and other components as further described in FIG. 6B. These components may be arranged behind the contact pads 608 or at other locations on the substrate 604, for example, within different layers of the substrate 604, and may be electrically and physically connected to the contact pads 608. Furthermore, the contactless card 104 may include a magnetic strip or tape arranged on the back of the card (not shown in FIG. 6A). Furthermore, the contactless card 104 can include a near field communication (NFC) device connected to an antenna that can communicate via the NFC protocol. Embodiments are not limited to this.

[0077] As shown in FIG. 6B, the contact pads 608 of the contactless card 104 may include a processing circuit 610 for storing, processing, and communicating information including a processor 612, a memory 110, and one or more communication interfaces 124. It is understood that the processing circuit 610 may include additional components including a processor, a memory, an error and parity / CRC check unit, a data encoder, an anti-collision algorithm, a controller, a command decoder, a security primitive, and anti-counterfeiting hardware as necessary to perform the functions described herein.

[0078] Memory 110 may be a read-only memory such as, for example, RAM, ROM, and EEPROM, a write-once memory, or a read / write memory, and contactless card 104 may include one or more of these memories. The read-only memory may be factory-programmable as read-only or once-programmable. Being once-programmable provides opportunities to read multiple times after being written once. The write-once memory may be programmed after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten but can be read multiple times. The read / write memory can be programmed and reprogrammed multiple times after leaving the factory. Further, the read / write memory can be read multiple times after leaving the factory. In some cases, memory 110 may be an encrypted memory that utilizes an encryption algorithm executed by processor 612 to encrypt data.

[0079] Memory 110 may be configured to store one or more applets 112, one or more counters 114, a customer ID 120, one or more master keys 116, and one or more diversification keys 118. The one or more applets 112 may include one or more software applications configured to execute on one or more contactless cards 104, such as Java (registered trademark) Card applets. However, it is understood that the applets 112 are not limited to Java Card applets and may instead be any software application operable on a contactless card or other device having limited memory. The one or more counters 114 may include numeric counters sufficient to store integers. The customer ID 120 can include a unique alphanumeric identifier assigned to a user of the contactless card 104, and the identifier can distinguish the user of the contactless card 104 from other users of other contactless cards 104. In some examples, the customer ID 120 can identify both the customer and the account assigned to that customer and can further identify the contactless card 104 associated with the customer's account.

[0080] Although the processor 612 and memory elements of the exemplary embodiments described above have been described with reference to the contact pads 608, the present disclosure is not limited thereto. It is understood that these elements may be implemented external to the contact pads 608, may be completely separated from the contact pads 608, or may be implemented as additional elements in addition to the elements of the processor 612 and memory 110 disposed within the contact pads.

[0081] In some examples, the contactless card 104 can include one or more antennas 614. The one or more antennas 614 may be disposed within the contactless card 104, around the processing circuitry 610 of the contact pads 608. For example, the one or more antennas 614 may be integral with the processing circuitry 610, and the one or more antennas 614 may be used with an external booster coil. As another example, the one or more antennas 614 may be external to the contact pads 608 and the processing circuitry 610.

[0082] In one embodiment, the coil of the contactless card 104 can function as the secondary of an air-core transformer. The terminal can communicate with the contactless card 104 by means of a chopped power or amplitude modulation. The contactless card 104 can infer data transmitted from the terminal using the gap in the power connection of the contactless card 104, which can be functionally maintained via one or more capacitors. The contactless card 104 can return communication by switching the load to the coil of the contactless card 104 or by load modulation. The load modulation can be detected by the coil of the terminal by interference. More generally, using the antenna 614, the processor 612, and / or the memory 110, the contactless card 104 provides a communication interface for communicating via NFC, Bluetooth, and / or Wi-Fi communication.

[0083] As described above, the contactless card 104 may be built on a software platform operable on a smart card such as a JavaCard or other device having limited memory, and one or more applications or applets may be securely executed. An applet 112 can be added to the contactless card to provide one-time passwords (OTPs) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet 112 may be configured to respond to one or more requests, such as a short-range wireless data exchange request from a reader (such as a mobile NFC reader of a mobile computing device 102 or a point-of-sales terminal), and generate an NDEF message containing a cryptographically secure OTP encoded as an NDEF text tag. The NDEF message can include a ciphertext 122 and any other data.

[0084] An example of an NDEF OTP is an NDEF short record layout (SR = 1). In such an example, one or more applets 112 can be configured to encode the OTP as a well-known type text tag of NDEF type 4. In some examples, the NDEF message can include one or more records. The applet 112 can be configured to add one or more static tag records in addition to the OTP record.

[0085] In some examples, one or more applets 112 can be configured to emulate an RFID tag. The RFID tag can include one or more polymorphic tags. In some examples, each time the tag is read, different cryptographic data can be presented that can indicate the authenticity of the contactless card. Based on one or more applets 112, the NFC reading of the tag can be processed, the data can be sent to a server such as a server of a banking system, and the data can be verified at the server.

[0086] In some examples, the contactless card 104 and the server can include specific data such that the card can be properly identified. The contactless card 104 can include one or more unique identifiers (not shown). Each time a read operation is performed, the counter 114 can be configured to increment. In some examples, each time data from the contactless card 104 is read (e.g., by a mobile device), the counter 114 is sent to the server for verification, and it is determined whether the counter 114 is equal to the server's counter (as part of the verification).

[0087] One or more counters 114 may be configured to prevent replay attacks. For example, if a ciphertext is obtained and replayed, the ciphertext is immediately rejected if the counter 114 is read, or used, or overlooked. If the counter 114 is not used, it may be replayed. In some examples, the counter incremented on the contactless card 104 is different from the counter incremented for the transaction. Since there is no communication between the applets 112 on the contactless card 104, the application transaction counter 114 cannot be determined. In some examples, the contactless card 104 may include a first applet 440-1 that may be a transaction applet and a second applet 440-2. Each applet 440-1 and 440-2 may include its own counter 114.

[0088] In some examples, the counter 114 may lose synchronization. In some examples, the counter 114 may be incremented to account for accidental reads that initiate a transaction, such as a diagonal read, but the application does not process the counter 114. In some examples, NFC may be enabled when the mobile device 10 wakes up, and the computing device 102 may be configured to read available tags, but no action is taken in response to the read.

[0089] To maintain synchronization of the counter 114, an application such as a background application may be executed that detects a wake-up of the computing device 102 and advances the counter 114 in synchronization with a server of a banking system indicating a read that occurred due to the detection. In other examples, hashed one-time passwords may be utilized such that a window of mis-synchronization may be accepted. For example, the counter 114 may be configured to advance when within a range of 10 thresholds. However, when within a range of a different number of thresholds, such as within a range of 10 or 1000, a request to perform re-synchronization may be processed, which requires the user to tap, gesture, or otherwise indicate one or more times via the user's device via one or more applications. If the counter 114 increases in an appropriate sequence, the user can know that they did so.

[0090] The key diversification techniques described herein with reference to the counter 114, the master key, and the diversification key are an example of the encryption and / or decryption of key diversification techniques. This exemplary key diversification technique should not be considered as limiting the present disclosure, as the present disclosure is equally applicable to other types of key diversification techniques.

[0091] In the creation process of the contactless card 104, two cryptographic keys can be uniquely assigned to each card. The cryptographic keys can include symmetric keys that can be used for both encryption and decryption of data. The Triple DES (3DES) algorithm may be used by EMV and implemented by hardware within the contactless card 104. By using a key diversification process, one or more keys can be derived from the master key based on uniquely identifiable information for each entity that requires a key.

[0092] In some instances, to overcome the drawbacks of the vulnerable 3DES algorithm, a session key (such as a unique key per session) can be derived, but instead of using a master key, a unique card-derived key and a counter can be used as diversification data. For example, each time the contactless card 104 is in operation, different keys may be used for creating a message authentication code (MAC) and performing encryption. This results in three layers of encryption. The session key can be generated by one or more applets and derived by using an application transaction counter with one or more algorithms (as defined in EMV 4.3 Book 2 A1.3.1 Common Session Key Derivation).

[0093] Furthermore, the increment for each card may be unique and may be assigned by personalization or algorithmically assigned by some identification information. For example, odd-numbered cards may increment by two, and even-numbered cards may increment by five. In some instances, the increment may vary in successive reads such that one card may increment sequentially by 1, 3, 5, 2, 2, ···. This particular sequence or algorithm sequence may be defined at the time of personalization or may be defined from one or more processes derived from a unique identifier. This can make it more difficult for a replay attacker to generalize from a small number of card instances.

[0094] The authentication message may be delivered as the content of a text NDEF record in hexadecimal ASCII format. In another example, the NDEF record may be encoded in hexadecimal format.

[0095] Figure 7 shows an NDEF Short Record Layout (SR=1) data structure 700 according to an exemplary embodiment. One or more applets may be configured to encode the OTP as a well-known type of text tag of NDEF type 4. In some examples, the NDEF message may include one or more records. The applet may be configured to add one or more static tag records in addition to the OTP record. Exemplary tags include, but are not limited to, tag type: well-known type, text, English encoding (en); applet ID: D2760000850101; function: read-only access; encoding: the authentication message can be encoded as ASCII hexadecimal; type-length-value (TLV) data may be provided as a personalization parameter that can be used to generate the NDEF message. In one embodiment, the authentication template may include a first record with a known index for providing actual dynamic authentication data. The data structure 700 can include the ciphertext 122 and any other data provided by the applet 112.

[0096] Figure 8 shows an embodiment of an exemplary computer architecture 800 suitable for implementation of the various embodiments as described above. In one embodiment, the computer architecture 800 may include or be implemented as part of the computing architecture 100.

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

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

[0099] As shown in FIG. 8, the computer architecture 800 includes a computer 812 having a processor 802, a system memory 804, and a system bus 806. The processor 802 may be any of a variety of commercially available processors. The computer 812 may represent the computing device 102 and / or the authentication server 106.

[0100] The system bus 806 provides an interface for system components such as, but not limited to, the system memory 804 to the processor 802. The system bus 806 may be any of several types of bus structures that can further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. An interface adapter can be connected to the system bus 806 via a slot architecture. Exemplary slot architectures 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.

[0101] Computer architecture 800 can include or implement various products. The products can include a computer-readable storage medium for storing logic. Examples of computer-readable storage media can include any tangible medium capable of storing electronic data, such as volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, and the like. Examples of logic can include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like. Further, embodiments may be at least partially implemented as instructions included in a non-transitory computer-readable medium readable and executable by one or more processors to enable performance of the operations described herein or as instructions on a non-transitory computer-readable medium.

[0102] The system memory 804 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, polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon oxide nitride oxide silicon (SONOS) memory, magnetic or optical cards, arrays of devices such as Redundant Array of Independent Disks (RAID) drives, solid state memory devices (e.g., USB memory, solid state drive (SSD)), and any other type of storage medium suitable for storing information. In the illustrated embodiment shown in FIG. 8, the system memory 804 can include non-volatile 808 and / or volatile 810. The basic input / output system (BIOS) can be stored in the non-volatile 808.

[0103] The computer 812 can include various types of computer-readable storage media in the form of one or more low-speed memory units, including an internal (or external) hard disk drive 814, a magnetic disk drive 816 for reading and writing a removable magnetic disk 818, and an optical disk drive 820 for reading and writing a removable optical disk 822 (e.g., CD-ROM or DVD). The hard disk drive 814, the magnetic disk drive 816, and the optical disk drive 820 can be connected to the system bus 806 by an HDD interface 824, an FDD interface 826, and an optical disk drive interface 828, respectively. The HDD interface 824 for external drive implementation can include at least one or both of universal serial bus (USB) and IEEE 1394 interface technologies.

[0104] The drive and associated computer-readable media provide volatile and / or non-volatile memory devices such as data, data structures, computer-executable instructions, and the like. For example, several program modules including an operating system 830, one or more applications 832, other program modules 834, and program data 836 can be stored on the drive as well as in non-volatile 808 and volatile 810. In one embodiment, one or more applications 832, other program modules 834, and program data 836 can include, for example, various applications and / or components of system 100.

[0105] A user can input commands and information into computer 812 via one or more wired / wireless input devices, such as a pointing device like keyboard 838 and mouse 840. Other input devices can include a microphone, infrared (IR) remote control, radio frequency (RF) remote control, game pad, stylus pen, card reader, dongle, fingerprint reader, glove, graphic tablet, joystick, keyboard, retina reader, touch screen (e.g., capacitive, resistive, etc.), trackball, track pad, sensor, stylus, and the like. These input devices and other input devices are often connected to processor 802 via an input device interface 842 connected to system bus 806, but may also be connected by other interfaces such as a parallel port, IEEE 1394 serial port, game port, USB port, IR interface, and the like.

[0106] Monitor 844 or other type of display device is also connected to system bus 806 via an interface such as video adapter 846. Monitor 844 can be internal or external to computer 812. In addition to monitor 844, a computer typically includes other peripheral output devices such as speakers, printers, and the like.

[0107] Computer 812 can operate in a network environment using a logical connection via wired and / or wireless communication to one or more remote computers, such as remote computer 848. Remote computer 848 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 computer 812, but for simplicity, only memory and / or storage device 850 is shown. The illustrated logical connections include wired / wireless connections to local area network 852 and / or a larger network, such as wide area network 854. Such LAN and WAN network environments are common in offices and enterprises, facilitate enterprise-scale computer networks such as intranets, and all of them can be connected to a global communication network such as the Internet.

[0108] When used in the network environment of local area network 852, computer 812 is connected to local area network 852 via a wired and / or wireless communication network interface or network adapter 856. Network adapter 856 can facilitate wired and / or wireless communication to local area network 852 where a wireless access point can be placed for communication with the wireless function of network adapter 856.

[0109] When used in the network environment of the wide area network 854, the computer 812 can include a modem 858, or be connected to a communication server on the wide area network 854, or have other means for establishing communication via the wide area network 854, such as through the Internet. The modem 858, which may be internal or external and may be a wired and / or wireless device, is connected to the system bus 806 via the input device interface 842. In a networked environment, the program modules shown with respect to the computer 812 and portions thereof may be stored in remote memory and / or storage device 850. It will be understood that the network connections shown are exemplary and that other means of establishing a communication link between computers may be used.

[0110] The computer 812 is operable to communicate with wired and wireless devices or entities using standards of the IEEE 802 family, such as a wireless device operably arranged for wireless communication (e.g., IEEE 802.11 wireless modulation techniques). This includes, among other things, at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth (trademark) wireless technologies. Thus, the communication may be of a pre-defined structure similar to a conventional network, or simply an ad hoc communication between at least two devices. A Wi-Fi network uses wireless technologies called IEEE 802.11 (a, b, g, n, ac, ax, etc.) to provide a secure and reliable high-speed wireless connection. Wi-Fi networks can be used to connect computers to each other, to the Internet, and to wired networks (using IEEE 802.3 related media and functions).

[0111] Referring to FIGS. 1-7, the various elements of the device as described above can include various hardware elements, software elements, or a combination of both. Examples of hardware elements include devices, logic devices, components, processors, microprocessors, circuits, processors, 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), memory units, logic gates, registers, semiconductor devices, chips, microchips, chip sets, etc. Examples of software elements include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (APIs), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. However, the determination of whether an embodiment is implemented using hardware elements and / or software elements can vary according to any number of factors such as the desired computational speed, power level, heat tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints desired for a given implementation.

[0112] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium that represents various logic within a processor and causes a machine, when read by the machine, to create logic for performing the techniques described herein. Such representations, known as “IP cores,” may be stored on a tangible machine-readable medium and supplied to various customers or manufacturing facilities and loaded onto manufacturing machines that fabricate the logic or processor. Some embodiments may be implemented using, for example, a machine-readable medium or article that can store instructions or instruction sets that, when executed by a machine, can cause the machine to perform the methods and / or operations according to the embodiments. Such machines can include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and can be implemented using any suitable combination of hardware and / or software. The machine-readable medium or article can include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium, and / or storage unit, such as memory, removable or non-removable media, erasable or non-erasable media, 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), tape, cassette, etc. The instructions can include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc., implemented using any suitable high-level, low-level, object-oriented, visual, compiled, and / or interpreted programming language.

[0113] The foregoing description of the exemplary embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Many modifications and variations are possible in light of the disclosure. The scope of the disclosure is intended to be limited not by this detailed description, but rather by the appended claims. Applications that claim the priority of this application and that may be filed in the future can claim the disclosed subject matter in a different manner and can generally include any combination of one or more of the limitations variously disclosed or demonstrated herein.

Claims

1. Receiving, by a seller web page within a web browser running on a processor of a mobile device, a selection of a first financial institution among a plurality of financial institutions, wherein the seller web page includes a plurality of form fields related to a transaction; Generating, by the seller web page, a uniform resource identifier (URI) directed to an application, wherein the URI includes a session identifier (ID) parameter and a user ID parameter related to the transaction, and at least a portion of the URI is registered with the application and the first financial institution within a mobile operating system (OS) running on the mobile device; In response to receiving a selection of the URI, launching, by the mobile OS, the application; Authenticating, by the application, login qualification information of an account associated with the first financial institution; Associating, by the application, the user ID parameter and the session ID parameter with the account; Receiving, by the application, a ciphertext from a contactless card associated with the account; Receiving, by the application from a server, an indication that the server has verified the ciphertext; Launching, by the mobile OS based on the indication, the web browser; Refreshing, by the web browser, the seller web page, wherein the refreshed seller web page includes a virtual card number (VCN) in a first form field among the plurality of form fields; Processing, by the seller web page, the transaction based at least in part on the VCN in the first form field A method comprising the above steps.

2. The step of associating the user ID parameter and the session ID parameter with the account comprises by the application, in (i) an account database stored on the mobile device, or (ii) an account database stored by the server, associating the user ID parameter and the session ID parameter with the account including The step of associating the user ID parameter and the session ID parameter with the account is the method according to claim 1, which associates the account with a browsing session for the transaction in the web browser.

3. The URI further includes a seller ID parameter of the seller associated with the seller web page and an action ID parameter, the VCN is generated by the server based on the authentication of the login credential information and the verification of the ciphertext, the use of the VCN is limited to the seller associated with the seller web page, the server transmits the VCN to a seller server associated with the seller, and the application loads an authentication page of the application based on the action ID parameter. The method according to claim 1.

4. The step of transmitting, by the application, the user ID parameter, the session ID parameter, the seller ID parameter, and the action ID parameter to the server further including The server further generates the VCN based on the user ID parameter, the session ID parameter, the seller ID parameter, and the action ID parameter. The method according to claim 3.

5. Prior to the step of processing the transaction the step of receiving, by the mobile device, a notification from (i) a seller server associated with the seller web page, or (ii) one or more of the servers further including The notification is received based on the fact that the transaction is not processed within a threshold time for the generation of the VCN. The method according to claim 1.

6. The URI is a Universal Link or App Link directed to the application The method includes, prior to the step of launching the application A step of determining by the mobile OS that the application is not installed on the mobile device; A step of downloading the application by the mobile OS; A step of installing the application on the mobile device by the mobile OS The method according to claim 1, further comprising.

7. The web browser determines that the application is installed on the mobile device based on a function provided by the mobile OS, and the refreshed seller web page includes (i) a name associated with the account in a second form field among the plurality of form fields, (ii) an expiration date associated with the VCN in a third form field among the plurality of form fields, (iii) a card verification value (CVV) associated with the VCN in a fourth form field among the plurality of form fields, (iv) a phone number associated with the account in a fifth form field among the plurality of form fields, and (v) an email address associated with the account in a sixth form field among the plurality of form fields. The method according to claim 1.

8. A non-transitory computer-readable storage medium, When executed by a processor of a mobile device, Receiving, by a seller web page in a web browser, a selection of a first financial institution among a plurality of financial institutions, wherein the seller web page includes a plurality of form fields related to a transaction; Generating, by the seller web page, a uniform resource identifier (URI) for an application, wherein the URI includes a session identifier (ID) parameter and a user ID parameter associated with the transaction, and at least a portion of the URI is registered with the application and the first financial institution within a mobile operating system (OS) running on the mobile device; In response to receiving a selection of the URI, a step of launching the application by the mobile OS; The step of authenticating the login qualification information of the account associated with the first financial institution by the application; The step of associating the user ID parameter and the session ID parameter with the account by the application; The step of receiving a ciphertext from the contactless card associated with the account by the application; The step of receiving, by the application from the server, an indication indicating that the server has verified the ciphertext; The step of starting the web browser by the mobile OS based on the indication; The step of refreshing the seller web page by the web browser, wherein the refreshed seller web page includes a virtual card number (VCN) in a first form field among the plurality of form fields; The step of processing the transaction by the seller web page based at least in part on the VCN of the first form field; A computer-readable storage medium including instructions for causing the processor to execute the above.

9. The step of associating the user ID parameter and the session ID parameter with the account includes: Associating the user ID parameter and the session ID parameter with the account in (i) an account database stored on the mobile device, or (ii) an account database stored by the server, by the application; Including; The computer-readable storage medium according to claim 8, wherein the step of associating the user ID parameter and the session ID parameter with the account associates the account with a browsing session for the transaction in the web browser.

10. The URI further includes a seller ID parameter of the seller associated with the seller web page and an action ID parameter, the VCN is generated by the server based on the authentication of the login credentials and the verification of the ciphertext, the use of the VCN is limited to the seller associated with the seller web page, the server sends the VCN to a seller server associated with the seller, and the application loads an authentication page of the application based on the action ID parameter. The computer-readable storage medium according to claim 8.

11. The instructions further cause the processor to perform a step of sending, by the application, the user ID parameter, the session ID parameter, the seller ID parameter, and the action ID parameter to the server ; The server further generates the VCN based on the user ID parameter, the session ID parameter, the seller ID parameter, and the action ID parameter. The computer-readable storage medium according to claim 10.

12. The instructions further cause the processor to perform a step of receiving, by the mobile device, a notification from (i) a seller server associated with the seller web page or (ii) one or more of the servers prior to processing the transaction ; The notification is received based on the transaction not being processed within a threshold time for generation of the VCN. The computer-readable storage medium according to claim 8.

13. The URI is a Universal Link or an App Link directed to the application, The instructions further cause the processor to perform, prior to starting the application, a step of determining by the mobile OS that the application is not installed on the mobile device, a step of downloading the application by the mobile OS, and a step of installing the application on the mobile device by the mobile OS ; ; ; The computer-readable storage medium according to claim 8.

14. The web browser determines that the application is installed on the mobile device based on a function provided by the mobile OS, and the refreshed seller web page includes (i) the name associated with the account in a second form field among the plurality of form fields, (ii) the expiration date associated with the VCN in a third form field among the plurality of form fields, (iii) the card verification value (CVV) associated with the VCN in a fourth form field among the plurality of form fields, (iv) the phone number associated with the account in a fifth form field among the plurality of form fields, and (v) the email address associated with the account in a sixth form field among the plurality of form fields. A computer-readable storage medium according to claim 8.

15. A processor, A memory for storing instructions Comprising: When the instructions are executed by the processor, Receiving, by a seller web page within a web browser, a selection of a first financial institution among a plurality of financial institutions, wherein the seller web page includes a plurality of form fields related to a transaction; Generating, by the seller web page, a uniform resource identifier (URI) directed to an application, wherein the URI includes a session identifier (ID) parameter and a user ID parameter associated with the transaction, and at least a part of the URI is registered with the application and the first financial institution within a mobile operating system (OS) running on the processor; In response to receiving a selection of the URI, starting the application by the mobile OS; Authenticating, by the application, login qualification information of an account associated with the first financial institution; Associating, by the application, the user ID parameter and the session ID parameter with the account; Receiving, by the application, a ciphertext from a contactless card associated with the account; Receiving, by the application, from the server, an indication indicating that the server has verified the ciphertext; Starting, by the mobile OS based on the indication, the web browser; Refreshing, by the web browser, the seller web page, wherein the refreshed seller web page includes a virtual card number (VCN) in a first form field among the plurality of form fields; Processing, by the seller web page, the transaction based at least in part on the VCN of the first form field; A computing device that causes the processor to execute the above steps.

16. The step of associating the user ID parameter and the session ID parameter with the account includes: Associating, by the application, the user ID parameter and the session ID parameter with the account in (i) an account database stored by the device or (ii) an account database stored by the server; including; The computing device according to claim 15, wherein the step of associating the user ID parameter and the session ID parameter with the account associates the account with a browsing session for the transaction in the web browser.

17. The URI further includes a seller ID parameter of the seller associated with the seller web page and an action ID parameter. The VCN is generated by the server based on the authentication of the login credential information and the verification of the ciphertext. The use of the VCN is limited to the seller associated with the seller web page. The server sends the VCN to a seller server associated with the seller. The application loads the authentication page of the application based on the action ID parameter. The computing device according to claim 15.

18. The instructions include: Sending, by the application, the user ID parameter, the session ID parameter, the seller ID parameter, and the action ID parameter to the server. further cause the processor to The server further generates the VCN based on the user ID parameter, the session ID parameter, the seller ID parameter, and the action ID parameter. The computing device according to claim 17. **Claim 19** The instructions Prior to the step of processing the transaction, (i) receiving a notification from a seller server associated with the seller web page, or (ii) one or more of the servers further cause the processor to The notification is received based on the transaction not being processed within a threshold time for the generation of the VCN. The computing device according to claim 15. **Claim 20** The URI is a Universal Link or App Link directed to the application, The instructions Prior to the step of launching the application, determining by the mobile OS that the application is not installed on the device; downloading the application by the mobile OS; installing the application on the device by the mobile OS further cause the processor to perform. The computing device according to claim 15.

Images