On-demand applications that extend web services

Abstract

Systems, methods, products, and computer-readable media. A web browser on a device can receive a selection of a uniform resource locator (URL). An operating system can download an application from an application server based on the URL. The application can identify a plurality of applications installed on the device and select a first institution corresponding to a first application. The application can receive a cryptogram from a contactless card associated with the first institution and transmit the cryptogram to an authentication server. The application can receive an authentication result identifying an authentication server that decrypted the cryptogram. The web browser can receive an account number, an expiration date associated with the account number, and a card verification value (CVV) associated with the account number based on decryption of the cryptogram. The web browser can provide the account number, the expiration date, and the CVV to a server associated with the application.

Description

[Technical field]

[0001] This application claims priority to U.S. patent application Ser. No. 17 / 235,082, entitled "On-Demand Applications for Augmenting Web Services," filed April 20, 2021. The contents of the aforementioned patent application are incorporated herein by reference in their entirety.

[0002] TECHNICAL FIELD The embodiments disclosed herein relate generally to computer platforms, and more particularly, to computer platforms that extend web-based services with on-demand applications. [Background technology]

[0003] Some web-based platforms host web pages of different entities. However, the functionality provided by a particular web page may be limited compared to the functionality provided by a dedicated application store application of a particular entity. For example, the web page may not be able to securely process customer data and / or requests. This issue is often exacerbated when using a mobile web browser to access the web pages because mobile web browsers have limited functionality compared to other types of web browsers. Thus, security and other risks may exist when using services provided by a web-based platform. Summary of the Invention

[0004]

[0005] Embodiments disclosed herein provide systems, methods, products, and computer-readable media for extending web services with on-demand applications. In one example, a web browser on a device can receive a selection of a uniform resource locator (URL). An operating system can download the application from an application server based on the URL. The application can identify a plurality of applications installed on the device and select a first institution corresponding to a first application. The application can receive a cryptogram from a contactless card associated with the first institution and transmit the cryptogram to an authentication server. The application may receive an authentication result identifying the authentication server that decrypted the cryptogram. The web browser can receive an account number, an expiration date associated with the account number, and a card verification value (CVV) associated with the account number based on decryption of the cryptogram. The web browser can provide the account number, the expiration date, and the CVV to a server associated with the application. [Brief description of the drawings]

[0005] [Figure 1A] FIG. 1A illustrates a system according to an embodiment. [Figure 1B] FIG. 1B illustrates a system according to an embodiment. [Figure 1C] FIG. 1C illustrates a system according to an embodiment. [Figure 1D] FIG. 1D illustrates a system according to an embodiment. [Figure 1E] FIG. 1E illustrates a system according to an embodiment. [Figure 2A] FIG. 2A illustrates a system according to an embodiment. [Figure 2B] FIG. 2B illustrates a system according to an embodiment. [Figure 2C] FIG. 2C illustrates a system according to an embodiment. [Figure 2D] FIG. 2D illustrates a system according to an embodiment. [Figure 2E] FIG. 2E illustrates a system according to an embodiment. [Figure 3A] FIG. 3A shows a first logic flow. [Figure 3B] FIG. 3B shows a first logic flow. [Figure 4] FIG. 4 shows a second logic flow. [Figure 5A] FIG. 5A shows an example of a contactless card. [Figure 5B] FIG. 5B shows an example of a contactless card. [Figure 6] FIG. 6 shows an example of a data structure. [Figure 7] FIG. 7 shows the computer architecture. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0006] The embodiments disclosed herein provide techniques for extending web services with on-demand applications. In general, a web service may include multiple web pages hosted by an e-commerce platform. Each web page may be associated with a respective one of multiple merchants present on the e-commerce platform. When a user accesses one of the web pages using a web browser on a device, the user may select one or more items for purchase. To improve security of the checkout process, the embodiments disclosed herein may present a uniform resource locator (URL) in the web page directed to an application hosted by an application server. The URL may include one or more additional parameters, such as a merchant identifier (e.g., a merchant identifier associated with the web page), a cart identifier for the transaction, and / or any other data elements. The application may be an on-demand application associated with the e-commerce platform that processes payment for the purchase. In response to the selection of the URL, the web browser and / or the device's operating system (OS) may access the URL. This may cause the on-demand application to be downloaded and executed on the device.

[0007] The on-demand application may then identify one or more applications installed on the device. The applications may include one or more financial institution applications. The on-demand application may then select a first financial institution application from the one or more applications. The user may provide their email address as input to the on-demand application. The on-demand application may then send the email address to a server of a financial institution associated with the first financial institution application. The server may use the email address to identify a phone number associated with the account in an account database. The server then sends a one-time passcode (OTP) to the identified phone number. Upon receiving the OTP, the user may provide the OTP to the on-demand application. The on-demand application may compare the user-provided OTP with the instance of the OTP received from the server.

[0008] If the comparison results in a match, the on-demand application can prompt the user to tap the contactless card to the device. In response, the user can tap the contactless card to the device and the on-demand application can operate a card reader on the device. This can cause or generate a cryptogram on the contactless card. This cryptogram can be included as part of a data package, such as an NFC Forum Data Exchange Format (NDEF) file. The on-demand application can read the data package via NFC and send the data package to a server for decryption. In some embodiments, the on-demand application can send additional metadata with the data package, such as a cart identifier, a merchant identifier, etc. The server can attempt to decrypt the cryptogram using the received data package.

[0009] Once the server decrypts the cryptogram, the server may send a response to the on-demand application. The response may include information indicating that the cryptogram was decrypted or authenticated. Additionally, once the server decrypts the cryptogram, the server may generate payment information for the purchase on the web browser. The payment information may include a virtual account number (VAN), an expiration date, a card verification value (CVV), and other information such as the user's address. The server may provide the payment information to a web server. The web server then pushes the payment information to the web browser, which populates one or more form fields in the web browser. The web browser may then be used to submit payment for the purchase using the payment information.

[0010] In some embodiments, the cookie may be stored on the device, for example, by the on-demand application in response to the server's decryption of the cryptogram and / or by the web browser in response to receiving the payment information. The cookie may be used to authenticate the user in subsequent transactions. For example, if the user attempts a second purchase, the user may again select a URL that uses the on-demand application. The on-demand application may be downloaded (if not available on the device) and executed. The on-demand application may identify a cookie stored on the device. The on-demand application may identify a first financial institution based on the cookie and instruct a server associated with the first financial institution to generate another VAN, expiration date, and CVV. Advantageously, based on the identification of the cookie, the user does not need to tap the card to the device to facilitate the server's decryption of another cryptogram. The second purchase may be completed using the different VAN, expiration date, and CVV.

[0011] Advantageously, embodiments disclosed herein provide techniques to extend web services using on-demand applications. Because an e-commerce platform may host websites offered by thousands (or more) of merchants, the e-commerce platform cannot reasonably provide a dedicated application for each merchant. However, by leveraging on-demand applications, the e-commerce platform can extend the functionality provided by the web pages. This may include rapid payment processing by using payment information that is automatically downloaded and inserted into one or more payment forms. By utilizing cryptograms generated by contactless cards, embodiments of the present disclosure can securely verify the identity of a user while minimizing the risk of fraud. Furthermore, by using a web browser, no dedicated client application is required for data communication with contactless cards. Using a web browser has the advantage that the functionality described herein can be extended to various entities and any number of users without the need for a dedicated application. Furthermore, by providing a simplified payment process, more transactions are processed by the server, thereby improving system performance.

[0012] With general reference to the notation and nomenclature used herein, one or more portions of the following detailed description may be presented in terms of program procedures executed on a computer or network of computers. These procedural descriptions and representations are used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. A procedure here is generally conceived to be a self-consistent sequence of operations leading to a desired result. These operations are those requiring physical manipulation of physical quantities. Usually, but not limited to, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It is sometimes convenient, primarily for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be noted, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

[0013] Further, these operations are often referred to in terms such as adding or comparing and are commonly associated with mental operations performed by a human operator. However, no such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein forming part of one or more of the embodiments. Rather, these operations are machine operations. Useful machines for performing the operations of the various embodiments include digital computers selectively activated or configured by a computer program stored therein written in accordance with the teachings herein, and / or include apparatus or digital computers specially constructed for the required purposes. Various embodiments also relate to apparatus or systems for performing these operations. These apparatus may be specially constructed for the required purposes. The required structure for a variety of these machines will be apparent from the description given.

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

[0015] 1A illustrates an example system 100 consistent with disclosed embodiments. Although system 100 illustrated in FIGS. 1A-1E has a limited number of elements in a particular topology, it will be understood that system 100 may include more or fewer elements in alternative topologies depending on a given implementation.

[0016] As shown, the system 100 includes one or more contactless cards 101, one or more computing devices 110, one or more financial institution servers 120, one or more payment processing servers 140, one or more electronic commerce servers 150, and one or more electronic commerce servers 150. The contactless card 101 represents any type of payment card, such as a credit card, a debit card, an ATM card, a gift card, etc. The contactless card 101 may include one or more communication interfaces 109, such as a radio frequency identification (RFID) chip, that communicates with a communication interface 118 (also referred to herein as a "card reader," "wireless card reader," and / or "wireless communication interface") of the computing device 110 via NFC, EMV standard, or other short-range protocol in wireless communication. Although NFC is used herein as an example of a communication protocol, the present disclosure is equally applicable to other types of wireless communication, such as EMV standard, Bluetooth, and / or Wi-Fi.

[0017] Computing device 110 represents any number and type of computing devices, such as smartphones, tablet computers, wearable devices, laptops, portable gaming devices, virtualized computer systems, merchant terminals, point of sale systems, servers, desktop computers, etc. Servers 120, 140, 150, and 160 represent any number and type of computing devices, such as servers, workstations, computer clusters, cloud computer platforms, virtualized computer systems, etc. Although not shown for clarity, computing device 110, contactless card 101, and servers 120, 140, 150, and 160 each include one or more processor circuitry that executes programs, code, and / or instructions.

[0018] As shown, memory 102 of contactless card 101 includes applet 103, counter 104, master key 105, diversification key 106, and unique customer identifier (ID) 107. Applet 103 is executable code that performs the operations described herein. Counter 104, master key 105, diversification key 106, and customer ID 107 are used to provide security for system 100, as described in more detail below.

[0019] As shown, memory 111 of mobile device 110 includes an instance of operating system (OS) 112. Examples of operating systems 112 include Android® OS, IOS®, macOS®, Linux®, and Windows® operating systems. As shown, OS 112 includes a web browser 113 and one or more applications 114. Web browser 113 is an application that allows device 110 to access information over network 130 (e.g., via the Internet). Applications 114 represent any type of application, including applications associated with one or more financial institutions and / or financial institution servers 120.

[0020] As shown, the memory 122 of the server 120 includes an authentication application 123. A given server 120 and / or authentication application 123 may be associated with a financial institution, e.g., a bank, that issues the contactless card 101. Thus, multiple different servers 120 and / or authentication applications 123 may be present in the system 100. As described in more detail herein, the authentication application 123 facilitates the generation of payment information for one or more contactless cards 101 via the web browser 113 and on-demand application 161 and / or communicates with the financial institution server 120 without requiring the device 110 to include an application dedicated to reading data from the contactless card 101. This allows the web browser 113 and / or web page 151 to process transactions without a given web page 151 including functionality to read data from the contactless card 101 and / or communicate with the financial institution server 120.

[0021] Generally, a user may use the web browser 113 to view one or more web pages 151 on the e-commerce server 150. The web pages 151 may include HyperText Markup Language (HTML) pages, JavaScript® pages, and / or any other pages. The e-commerce server 150 may generally provide a platform for separate merchants, or sellers, who sell goods, services, items, and the like. Thus, each seller is associated with at least one web page 151.

[0022] Generally, while browsing, a user may select one or more goods and / or services to purchase from one or more merchants present on the e-commerce platform 150. Once the user selects the desired goods and / or services, the user may encounter an interface (e.g., a cart page, a checkout page, etc.) of a web page 151-1 to complete the transaction in the web browser 113. Traditionally, the user is required to manually enter their name, card number, expiration date, CVV, and / or address information into the form of the web page 151-1 of the web browser 113 to complete the purchase. Furthermore, while the device 110 may be capable of reading this information from the contactless card 101 via the communication interface 118, the web browser 113 and / or the web page 151-1 may not support such functionality. For example, the web browser 113 and / or the web page 151-1 may not be able to control the communication interface 118. Similarly, web browser 113 and / or web page 151-1 may not be able to use authentication application 123 to communicate with communication interface 118 to utilize the necessary security features.

[0023] Advantageously, however, the web page 151-1 may include a URL 153 that initiates a secure payment process for the transaction. Typically, the URL 153 is directed to one of the on-demand applications 161 on the application server 160. In some embodiments, the URL 153 may specify one or more parameters. For example, the parameters may include a merchant identifier, a transaction (or shopping cart) identifier, an identifier of the application 161, and the like. An example of a URL 153 is "http: / / www.example.com / app123?merchantid=abc&cartid=123", where "app123" identifies the application 161, "merchantid=abc" identifies the merchant, and "cartid=123" identifies the transaction and / or shopping cart. The merchant identifier may be a unique identifier associated with the merchant and / or a web page 151 associated with the merchant that resides in the e-commerce server 150. For example, the e-commerce server 150 hosts web pages for entities A, B, and C, for example. In such an example, each entity A, B, and C is associated with a respective unique identifier. The transaction identifier uniquely identifies a given transaction (e.g., an item selected for purchase, a shopping cart, etc.) and is associated with an account on the e-commerce server 150. For example, the transaction identifier may be a unique alphanumeric identifier, a unique session alphanumeric identifier, a file, etc.

[0024] FIG. 1B illustrates an embodiment in which a user selects URL 153 in a web browser to complete a transaction using contactless card 101 without manually entering payment information into web browser 113 and / or web page 151-1. In response to the selection of URL 153, OS 112 can dynamically download on-demand application 161-1 and dynamically install on-demand application 161-1 on the device. URL 153 can further be a universal link URL (or deep link URL) that opens a resource (e.g., one or more specific pages of an associated on-demand application 161). The page of on-demand application 161 to be opened upon execution on mobile device 110 can be specified as a parameter of URL 153. Similarly, a merchant identifier and / or a transaction identifier can be provided to on-demand application 161 via a parameter of URL 153.

[0025] On-demand applications 161 are non-persistent applications that may be dynamically downloaded and executed on mobile device 110. Examples of on-demand applications 161 include Android® Instant Applications, Apple® App Clips, and Progressive Web Applications. More generally, on-demand applications 161 include a subset of the functionality provided by applications 114 associated with a financial institution server. For example, on-demand applications 161 may include functionality to read data from contactless card 101 and transmit the data to authentication application 123 on financial institution server 120 for verification. However, on-demand applications 161 may omit other functionality (e.g., viewing account balances, transferring funds, etc.) provided by complete applications 114 provided by the financial institution. In some embodiments, a given on-demand application 161 may be associated with a separate e-commerce platform and / or server 150 of multiple e-commerce platforms and / or servers 150.

[0026] In the embodiment shown in FIG. 1B, the on-demand application 161-1 may identify one or more of the applications 114 installed on the device. This may enable the on-demand application 161-1 to determine the issuer of the contactless card 101. In general, the on-demand application 161-1 may search for applications 114 associated with financial institutions and / or financial institution servers 120. If one application 114 is identified, the on-demand application 161-1 may select the financial institution server 120 associated with that application. This association may be defined in a table or other data structure in the on-demand application 161-1. In an embodiment in which the application 114 is not identified, the on-demand application 161-1 may include a list of financial institutions (e.g., ranked based on popularity among all users) and iteratively select each financial institution (and / or associated server 120) in ranked order until the correct financial institution associated with the contactless card 101 is identified.

[0027] In embodiments in which the on-demand application 161-1 identifies multiple financial institution applications 114 installed on the device 110, the on-demand application 161-1 can select one of the financial institution applications 114 and associated financial institution server 120. The on-demand application 161-1 can select one of the applications 114 using any rules and / or selection logic. For example, the on-demand application 161-1 can select the most recently used application 114, the most frequently accessed application 114, etc. In some embodiments, the on-demand application 161-1 calculates a score for each application 114 based, for example, on the most recently used, the most frequently used, etc. The on-demand application 161-1 then selects the application 114 with the highest score.

[0028] Once the on-demand application 161-1 selects a financial institution application 114 and / or financial institution server 120, the on-demand application 161-1 may search for a cookie on the device 110. If the cookie is found, the on-demand application 161-1 may prompt the user to enter their email address (or some other identifier) ​​as part of a one-time passcode (OTP) registration flow. Once provided, the on-demand application 161-1 may send the email address (and / or a hash of the email address) to the selected financial institution server 120. In response, the authentication application 123 may identify a phone number associated with the email address in the account data 124.

[0029] The authentication application 123 can then generate an OTP and send it to the device 110 using the identified phone number. The OTP may use any alphanumeric string. The user can then provide the OTP as input to the on-demand application 161-1. The on-demand application 161-1 then sends the received input to the authentication application 123, which compares the input to the generated OTP. The authentication application 123 may return the result of the comparison to the on-demand application 161-1. However, in some embodiments, the authentication application 123 provides the generated OTP to the on-demand application 161-1, which performs the comparison. Regardless of the entity performing the comparison, if the comparison results in a match, the user can be enrolled in automatic payments using the contactless card 101 on the e-commerce platform. In some embodiments, the on-demand application 161-1 can save a cookie (not shown) that enrolls the user in automatic payments in response to a comparison that results in a match. If the comparison does not result in a match, the process stops and the user's request to check out using automatic payment via contactless card 101 is restricted.

[0030] 1C illustrates an embodiment in which the OTP provided by the user matches the OTP generated by the authentication application 123 and the on-demand application 161-1. In response to determining a match and / or receiving an indication of a match from the authentication application 123, the on-demand application 161-1 instructs the user to tap the contactless card 101 to the device 110. The user may tap the contactless card 101 to the device 110 (or alternatively, may place the contactless card 101 within communication range of the card reader 118 of the device 110). In general, once the contactless card 101 is placed within communication range of the communication interface 118 of the device 110, the on-demand application 161-1 instructs the applet 103 of the contactless card 101 to generate a cryptogram 115. The cryptogram 115 may be generated based on any suitable cryptographic technique. In some embodiments, the applet 103 may include the ciphertext and the unencrypted customer ID 107 (and / or any other unique identifier) ​​in a data package. In at least one embodiment, the data package including the ciphertext 115 and the unencrypted customer ID 107 is an NDEF file.

[0031] As mentioned above, the system 100 implements key diversification to protect data, which may be referred to herein as a key diversification technique. In general, the server 120 (or another computing device) and the contactless card 101 may be provided with the same master key 105 (also referred to as a master symmetric key). More specifically, each contactless card 101 is programmed with a separate master key 105 that has a corresponding pair in the server 120 associated with the financial institution that issues the contactless card 101. For example, when the contactless card 101 is manufactured, a unique master key is created. Similarly, the unique master key 105 may be stored in the customer record associated with the contactless card 101 in the account data 124 of the server 120 (and / or stored in another secure location, such as a hardware security module (HSM) 125). The master key 105 may be kept secret from all parties other than the contactless card 101 and the server 120, thereby enhancing the security of the system 100. In some embodiments, the applet 103 of the contactless card 101 can encrypt and / or decrypt data (e.g., customer ID 107) using the master key 105 and the data as inputs to an encryption algorithm. For example, encrypting the customer ID 107 with the master key 105 results in ciphertext 115. Similarly, the server 120 can encrypt and / or decrypt data associated with the contactless card 101 using the corresponding master key 105.

[0032] In other embodiments, the master key 105 of the contactless card 101 and the server 120 can be used in combination with the counter 104 to enhance security using key diversification. The counter 104 comprises a value that is synchronized between the contactless card 101 and the server 120. The counter value 104 may comprise a numerical value that changes each time data is exchanged between the contactless card 101 and the server 120 (and / or the contactless card 101 and the device 110). When preparing to send data (e.g., to the server 120 and / or the device 110), the applet 103 of the contactless card 101 can increment the counter value 104. The applet 103 of the contactless card 101 can then provide the master key 105 and the counter value 104 as inputs to an encryption algorithm that generates the diversified key 106 as an output. The encryption algorithm may include an encryption algorithm, a hash-based message authentication code (HMAC) algorithm, a cipher-based message authentication code (CMAC) algorithm, etc. Non-limiting examples of encryption algorithms may include symmetric encryption algorithms such as 3DES or AES107, symmetric HMAC algorithms such as HMAC-SHA-256, and symmetric CMAC algorithms such as AES-CMAC. Examples of important diversification techniques are described in further detail in U.S. Patent Application No. 16 / 205,119, filed November 29, 2018. The aforementioned patent application is incorporated herein by reference in its entirety.

[0033] Continuing with the key diversification example, the contactless card 101 can then encrypt the data (e.g., customer ID 107 and / or any other data) using the diversification key 106 and the data as inputs to an encryption algorithm. For example, encrypting the customer ID 107 with the diversification key 106 results in an encrypted customer ID (e.g., ciphertext 115). As previously mentioned, the ciphertext 115 can be included in a data package, such as an NDEF file. The on-demand application 161-1 can then read the data package including the ciphertext 115 via the communications interface 118.

[0034] Regardless of the encryption technique used, on-demand application 161-1 can transmit ciphertext 115 to server 120 over network 130. In some embodiments, on-demand application 161-1 further provides a merchant identifier. For example, the merchant identifier, transaction identifier, and other data elements specified in URL 153 may be provided as inputs to on-demand application 161-1.

[0035] The on-demand application 161-1 may further indicate to the server 120 that the ciphertext 115 has been read from the contactless card 101 via the card reader 118 of the device 110. Once received, the authentication application 123 may attempt to authenticate the ciphertext 115. For example, the authentication application 123 may attempt to decrypt the ciphertext 115 using a copy of the master key 105 stored on the server 120. In some embodiments, the authentication application 123 may use an unencrypted customer ID 107 included in the data package to identify the master key 105 and the counter value 104. In some examples, the authentication application 123 may provide the master key 105 and the counter value 104 as inputs to an encryption algorithm that generates a diversified key 106 as an output. The resulting diversified key 106 may correspond to the diversified key 106 of the contactless card 101 and may be used to decrypt the ciphertext 115.

[0036] Regardless of the decryption technique used, the authentication application 123 may successfully decrypt the ciphertext 115 and thereby verify or authenticate the ciphertext 115 (e.g., by comparing the customer ID 107 generated by decrypting the cipher to a known customer ID stored in the account data 124 and / or based on an indication of successful decryption using the keys 105 and / or 106). Although the keys 105, 106 are shown stored in the memory 122, the keys 105, 106 may be stored elsewhere, such as in the secure element and / or HSM 125. In such an embodiment, the secure element and / or HSM 125 may use the keys 105 and / or 106 and a cryptographic function to decrypt the ciphertext. Similarly, the secure element and / or HSM 125 may generate the diversified key 106 based on the master key 105 and the counter value 104, as described above. If the decryption is successful, the authentication application 123 may cause payment information to be generated and / or transmitted for the transaction. In some embodiments, the authentication application 123 may send a decryption result (also called an “authentication result” or “verification result”) to the web browser 113 and / or the on-demand application 161-1 indicating whether the decryption was successful or unsuccessful.

[0037] However, if authentication application 123 cannot decrypt ciphertext 115 to obtain the expected result (e.g., customer ID 107 for the account associated with contactless card 101), then authentication application 123 does not verify the ciphertext. In such an example, authentication application 123 decides to refrain from generating or providing payment information for the transaction. Authentication application 123 can send an indication of the decryption failure to web browser 113 and / or on-demand application 161-1. Web page 151-1 and / or on-demand application 161-1 can then display to the user that the decryption failed, thereby causing the automatic payment to fail.

[0038] 1D illustrates an embodiment in which authentication application 123 successfully decrypts cryptogram 115, thereby verifying (or authenticating) cryptogram 115. In response, authentication application 123 transmits decryption result 116 indicating that authentication application 123 successfully decrypted cryptogram 115 and that payment information 117 was generated and / or transmitted for the requested purchase. Payment information 117 may include the contactless card 101 account number (e.g., primary account number (PAN)), expiration date, and CVV. In some embodiments, payment information 117 further includes the user's name, billing address, and / or shipping address. In some embodiments, the account number is a disposable virtual account number (VAN).

[0039] As shown, server 120 may send payment information 117 directly to device 110, for example as a push notification, an SMS message, or the like. In such an embodiment, OS 112 may copy one or more elements of information 117 to a clipboard (not shown). The clipboard may paste information 117 into one or more form fields of web page 151-1. Additionally and / or alternatively, OS 112 may provide payment information 117 to an autofill service (not shown) that automatically fills in form fields of web page 151-1 with payment information 117. The user may have an opportunity to review and approve the purchase using the received payment information 117. However, in some embodiments, the purchase is automatically processed on web page 151-1 without requiring further user input. In some embodiments, as described in more detail elsewhere, server 120 sends payment information 117 to on-demand application 161-1, and the purchase is completed using on-demand application 161-1.

[0040] Additionally and / or alternatively, as shown, server 120 may transmit payment information 117 to electronic commerce server 150. In such an embodiment, server 120 may transmit a merchant identifier and / or a transaction identifier to electronic commerce server 150, thereby allowing electronic commerce server 150 to identify the session with web browser 113. Electronic commerce server 150 may then automatically populate one or more form fields in web page 151-1 of web browser 113. However, in some such embodiments, payment information 117 is not transmitted to device 110. Instead, payment information 117 received from server 120 is used to automatically process the transaction with payment processing server 140. Once payment information is transmitted to device 110, the user may have the opportunity to review and approve the purchase using payment information 117 received at web browser 113. However, in some embodiments, the purchase is automatically processed at web page 151-1 without requiring further user input.

[0041] 1E illustrates an embodiment in which a purchase is processed using payment information 117. As illustrated, web browser 113 may send payment information 117 (e.g., in an HTTP request) to e-commerce server 150 and / or payment server 150. However, in some embodiments, web browser 113 sends the payment information to e-commerce server 150, and web page 151-1 (or another component of e-commerce server 150) provides payment information 117 to a payment processor. E-commerce server 150 may then generate a transaction record 154 for the transaction in transaction database 152. Similarly, payment processing server 140 may generate a transaction record 142 in payment processing data 141.

[0042] Once payment for the transaction has been processed, the e-commerce server 150 may send a confirmation 170 to the web browser 113. The confirmation 170 may be part of the web page 151. The confirmation 170 generally indicates that payment for the transaction has been received and that the transaction has been processed. Additionally, as shown, the memory 111 of the device 110 includes a cookie 171. As previously discussed, the cookie 171 may be stored by the on-demand application 161-1 following the OTP confirmation and / or by the web browser 113 based on the OTP confirmation 170. The cookie 171 may be used to authenticate the user for subsequent transactions without requiring OTP and / or cryptographic verification. The cookie 171 may generally include some other identifier, such as a token or a combination of a token and identifier of the device 110.

[0043] For example, if the user were to attempt a second purchase, the user could again select URL 153 to use on-demand application 161-1. On-demand application 161-1 could be downloaded (if not available on the device) and executed. On-demand application 161-1 could identify cookie 171 stored on the device. In response, on-demand application 161-1 could decide to abort the generation and / or validation of the OTP. On-demand Application On-demand application 161-1 could identify a first financial institution based on cookie 171 and instruct server 120 associated with the first financial institution to generate a second VAN, an expiration date for the second VAN, and a CVV for the second VAN. Advantageously, based on the identification of the cookie, the user would not need to tap the card to the device to facilitate decryption of another cryptogram by the server. The second VAN, expiration date, and CVV could then be used to complete the second purchase as described herein.

[0044] Advantageously, purchases are securely processed using the web browser 113 and web pages 151 without requiring the device 110 to run a dedicated client application provided by an entity associated with the contactless card 101 (e.g., application 114 provided by a financial institution associated with the contactless card 101). Furthermore, each web page 151 need not include the functionality to read data from different cards and / or communicate with different servers 120. Additionally, the security of the card 101 and / or associated account is enhanced by the use of a cryptogram generated by the card 101 as a condition of the purchase.

[0045] 2A is a schematic diagram 200 illustrating an example computing device 110 consistent with disclosed embodiments. More specifically, FIG. 2A illustrates an embodiment in which a web browser 113 displays a checkout web page 151-2. As shown, the web page 151-2 includes a selectable element 201 for initiating a payment using a contactless card 101. The selectable element 201 may correspond to a URL, such as URL 153, directed to one of the on-demand applications 161. The URL may include a merchant identifier, a transaction (or cart) identifier, and other relevant parameters. Once selected, the device 110 may download the on-demand application 161 at the URL.

[0046] FIG. 2B is a schematic diagram 210 illustrating an embodiment in which an on-demand application 161-2 is downloaded and executed on device 110. As shown, on-demand application 161-2 provides a welcome page and URL 202 to initiate a payment using contactless card 101. FIGS. 2A-2E reflect an embodiment in which a user has previously completed an OTP verification process and a cookie 171 has been stored on the device based on the OTP verification. Thus, on-demand application 161-2 can identify and verify cookie 171 on device 110 and decide to forego the request for the user's email to initiate the OTP flow.

[0047] 2C is a schematic diagram 220 reflecting an embodiment in which a user selects URL 202. As shown, on-demand application 161-2 instructs the user to tap contactless card 101 to computing device 110 to process a payment. When card 101 comes within communication range of card reader 118, on-demand application 161-2 controls card reader 118 to instruct applet 103 of contactless card 101 to generate diversified key 106 as described above and to use generated diversified key 106 to generate ciphertext (e.g., encrypted customer ID 107). Applet 103 may further generate an NDEF file or other data package that includes the ciphertext and unencrypted identifiers, such as unencrypted customer ID 107, merchant ID, transaction ID, etc. In such an embodiment, on-demand application 161-2 may provide the merchant ID and / or transaction ID to applet 103.

[0048] The on-demand application 161-2 may then read the data package or NDEF file, for example, via NFC. Once read, the on-demand application 161-2 may send the data package to the server 120 for processing. The on-demand application 161-2 may select the server 120 based on the cookie 171. The on-demand application 161-2 may optionally process the data package, for example, to format the data package, add a merchant ID, and add a transaction. The on-demand application 161-2 may further indicate to the server 120 that the cryptogram was read from the contactless card 101 via the card reader 118 of the device 110.

[0049] Upon receipt, the authentication application 123 may attempt to verify the cryptogram in the data package. In at least one embodiment, the unencrypted customer ID 107 provided by the applet 103 may be used by the authentication application 123 to identify the associated account, counter value 104, and / or master key 105 in the account data 124. The authentication application 123 attempts to decrypt the cryptogram by providing the master key 105 and the incremented counter value 104 as inputs to an encryption algorithm that generates a diversified key 106 as an output. The resulting diversified key 106 may correspond to an instance of the diversified key 106 generated by the contactless card 101 to create the cryptogram and may be used to decrypt the cryptogram. In general, the authentication application 123 may send a decryption result to the web browser 113 and / or the on-demand application 161-2 indicating whether the decryption was successful or unsuccessful. If the decryption was successful, the authentication application 123 may generate a virtual account number (VAN), an expiration date for the VAN, and a CVV for the VAN. The authentication application 123 may then transmit the generated data to the device 110 and / or any suitable components thereof.

[0050] FIG. 2D is a schematic diagram 230 illustrating an embodiment in which server 120 decrypts a cryptogram generated by contactless card 101 and read by on-demand application 161-2. As shown, on-demand application 161-2 can output an approval page based on the decryption results received from server 120 in response to decrypting the cryptogram. On-demand application 161-2 can then include a selectable element 205 requesting user approval to share or otherwise use the payment information for the transaction. Once selected, on-demand application 161-2 can process the purchase using the payment information received from server 120. For example, on-demand application 161-2 can transmit the merchant identifier, transaction identifier, account holder name, VCN, expiration date, CVV, billing address, and / or shipping address to e-commerce server 150 and / or payment processing server 140 for processing. However, in some embodiments, server 120 provides payment information generated by server 120 to web browser 113 in response to a selection of selectable element 205, as described in more detail herein. In doing so, the web browser 113 may transmit the payment information to the e-commerce server 150 and / or the payment processing server 140 for processing.

[0051] 2E is a diagram 240 illustrating an embodiment in which the web browser 113 outputs a confirmation to a web page 151-2. The confirmation page may be displayed based on a confirmation 170 received from the electronic commerce server 150. The confirmation may generally include details regarding the processed transaction.

[0052] The operation of the disclosed embodiments is further described with reference to the following figures. Some of the figures may include logic flows. Although such figures presented herein may include specific logic flows, it will be understood that the logic flows only provide examples of how the general functions as described herein may be implemented. Furthermore, the specified logic flows do not necessarily have to be executed in the order presented, unless otherwise specified. Furthermore, in some embodiments, not all operations shown in the logic flows are required. Furthermore, a given logic flow may be implemented by a hardware element, a software element executed by a processor, or any combination thereof. The embodiments are not limited in this respect.

[0053] 3A-3B illustrate one embodiment of a logic flow 300. The logic flow 300 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 300 may include some or all of the operations of augmenting a transaction initiated in a web browser 113 using an on-demand application 161. The embodiments are not limited in this context.

[0054] At block 305, the web page 151 rendered on the browser 113 of the device 110 may include a URL, such as URL 153 directed to the on-demand application 161. The user may select the URL 153, which may further include parameters describing one or more attributes of the transaction, such as a merchant identifier, a transaction identifier, etc. At block 310, upon selection of the URL, the device 110 downloads and executes the on-demand application 161. At block 315, the on-demand application 161 may scan the device 110 to identify applications 114 registered with one or more financial institutions on the device. The on-demand application 161 may select one of the identified applications 114 based, for example, on one or more attributes of each application 114 and / or a score calculated for each application by the on-demand application 161 based on the attributes. The attributes may include, but are not limited to, recent use of the application 114, the most frequently used applications 114, the number of times the application 114 was used within a given time period, the size of the financial institution, the number of clients of the financial institution, etc. The selected application 114 can be associated with at least one financial institution server 120. If the application 114 is not identified, the on-demand application 161 can select one or more financial institution servers 120 based on a list of financial institution servers stored by the on-demand application 161.

[0055] At block 320, the on-demand application 161 requests an email address from the user and receives input including the email address. The on-demand application 161 may send the email address to the financial institution server 120 identified at block 315. At block 330, the authentication application 123 of the selected financial institution server 120 receives the email address from the on-demand application 161. The authentication application 123 may use the email address to query the account data 124 to receive a phone number for the account associated with the email address. The authentication application 123 may then generate an OTP and send the OTP to the phone number, for example, via an SMS message.

[0056] At block 335, the user provides the received OTP as input to on-demand application 161. On-demand application 161 can verify the OTP entered by the user. For example, on-demand application 161 can receive the OTP generated by authentication application 123 and compare the received OTP to the input provided by the user. In such an example, on-demand application 161 can send the result of the comparison to authentication application 123. As another example, on-demand application 161 can send the input received from the user to authentication application 123. Authentication application 123 can compare the received input to the generated OTP and send the result of the comparison to on-demand application 161. Regardless of the entity performing the comparison, if the comparison results in a match, the email address may be verified, the account may be verified, and the user's account in account data 124 may be updated to reflect the registration of the purchase using web browser 113 and on-demand application 161.

[0057] At block 340, the on-demand application 161 instructs the user to tap the contactless card 101 to the device 110. When the user taps the card 101 to the device 110, the on-demand application 161 instructs the applet 103 to generate a cryptogram. In some embodiments, the on-demand application 161 provides a merchant ID and / or a transaction ID to the applet 103, which can include the merchant ID and / or the transaction ID in a data package (e.g., an NDEF file) that includes the cryptogram. The on-demand application 161 can then read the cryptogram included in the NDEF file. At block 345, the on-demand application 161 sends the cryptogram to the financial institution server 120 associated with the contactless card 101. At block 350, the on-demand application 161 receives a decryption result indicating that the authentication application 123 has decrypted the cryptogram, thereby authenticating and / or verifying the cryptogram. Based on the decryption, the authentication application 123 can generate the VCN, expiration date, and CVV for the account associated with the contactless card 101.

[0058] At block 355, the web browser 113 may receive payment information 117 generated by the authentication application 123 based on the verification of the OTP at block 335 and the decryption of the ciphertext at block 350. For example, the authentication application 123 may provide the payment information 117 to the e-commerce server 150 hosting the web page 151, and the web server of the e-commerce server 150 may provide the payment information 117 to the web browser 113. At block 360, the user may optionally approve the purchase using the payment information 117. However, in some embodiments, user approval is not required and the purchase is automatically completed using the received payment information 117.

[0059] 3B, in block 365, the web browser 113 may send at least the payment information 117 to the e-commerce server 150 and / or the payment processing server 140 to process the transaction. In block 370, the e-commerce server 150 and / or the payment processing server 140 processes the transaction using the server-generated payment information 117. In block 375, the transaction is completed and a confirmation is sent to the web browser 113. In block 380, the on-demand application 161 and / or the web browser 113 saves a cookie 171 on the device 110. The cookie 171 may use a token or other information to enable the on-demand application 161 to determine that the user has completed the OTP registration. The token may further be used to identify the financial institution and / or the financial institution server 120 associated with the card 101. As previously mentioned, in some embodiments, the cookie 171 may be stored following validation of the OTP in block 335.

[0060] 4 illustrates one embodiment of a logic flow 400. The logic flow 400 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 400 may include some or all of the operations of augmenting a transaction initiated in a web browser 113 using an on-demand application 161. The embodiments are not limited in this context.

[0061] At block 405, the web page 151 rendered on the browser 113 of the device 110 may include a URL, such as URL 153 directed to the on-demand application 161. The user may select the URL 153 to utilize the linked on-demand application 161 to complete the purchase. The URL 153 may further include parameters describing one or more attributes of the transaction, such as a merchant identifier, a transaction identifier, etc. At block 410, upon selection of the URL, the device 110 downloads and executes the on-demand application 161. At block 415, the on-demand application 161 identifies a cookie 171 that is stored in the memory of the device 110. This causes the on-demand application 161 to skip the OTP verification flow. At block 420, the on-demand application 161 identifies the financial institution and / or financial institution server 120 associated with the card 101.

[0062] At block 425, the on-demand application 161 requests payment information from the financial institution server 120 identified at block 420. The server 120 may then generate payment information 117 including the VCN, expiration date, and CVV. In some embodiments, the generation of the payment information 117 is contingent on the contactless card 101 generating another cryptogram and the server 120 verifying the cryptogram. At block 430, the web browser 113 and / or the e-commerce server 150 receive the payment information 117 generated at block 425. At block 435, the web browser 113 transmits the payment information 117 to the e-commerce server 150 and / or the payment processing server for processing the transaction. At block 440, the e-commerce server 150 and / or the payment processing server 140 processes the transaction. Doing so may include storing one or more transaction records related to the transaction and transmitting a confirmation of the purchase to the web browser 113.

[0063] FIG. 5A is a schematic diagram 500 illustrating an example configuration of a contactless card 101, which may include a payment card, such as a credit card, debit card, or gift card issued by a service provider, as displayed on its surface as a service provider indicia 502. In some examples, the contactless card 101 is not related to a payment card and may include, but is not limited to, an identification card. In some examples, the contactless card may include a dual interface contactless payment card, a loyalty card, and the like. The contactless card 101 may include a substrate 510, which may include a single layer or one or more laminated layers of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, contactless card 101 may have physical characteristics that conform to the ID-1 format of the ISO / IEC 7810 standard, and contactless cards may also conform to the ISO / IEC 14443 standard. However, it will be understood that contactless cards 101 according to the present disclosure may have different characteristics, and the present disclosure does not require that contactless cards be implemented as payment cards.

[0064] The contactless card 101 may also include identification information 515 displayed on the front and / or back of the card, and a contact pad 520. The contact pad 520 may include one or more pads to establish a connection with other clients, such as ATMs, user devices, smartphones, laptops, desktops, or tablet computers, via the contactless card. The contact pad may be designed according to one or more standards, such as the ISO / IEC 7816 standard, and may enable communication according to EMV protocols. The contactless card 101 may also include processing circuitry, an antenna, and other components, as further described in FIG. 5B. These components may be located behind the contact pad 520 or elsewhere on the substrate 510, e.g., on different layers of the substrate 510, and may be electrically and physically coupled to the contact pad 520. The contactless card 101 may also include a magnetic strip or tape that may be located on the back of the card (not shown in FIG. 5A). The contactless card 101 may also include a near field communication (NFC) device coupled to an antenna capable of communicating via an NFC protocol. The embodiments are not so limited.

[0065] As shown, the contact pad 520 of the contactless card 101 may include processing circuitry 525 for storing, processing, and communicating information, including a processor 530, memory 102, and one or more communication interfaces 109. It will be understood that the processing circuitry 525 may include additional components including processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and anti-tamper hardware as necessary to perform the functions described herein.

[0066] The memory 102 may be a read-only memory, a write-once read-multiple memory, or a read / write memory, e.g., RAM, ROM, and EEPROM, and the contactless card 101 may include one or more of these memories. Read-only memory may be programmable as read-only at the factory or programmable only once. One-time programmability allows it to be written once and read many times. Write-once / read-multiple memory may be programmed at some point after the memory chip leaves the factory. Once programmed, the memory cannot be rewritten, but it can be read many times. Read / write memory may be programmed and reprogrammed many times after leaving the factory. Read / write memory may also be read many times after leaving the factory. In some examples, the memory 102 may be an encrypted memory that utilizes an encryption algorithm executed by the processor 530 to encrypt data.

[0067] The memory 102 may be configured to store one or more applets 103, one or more counters 104, a master key 105, a diversified key 106, and a customer ID 107. The one or more applets 103 may include one or more applets 103. The one or more counters 104 may be any software application that runs on one or more contactless cards, such as a Java Card applet. However, it will be understood that the applet 103 is not limited to a Java Card applet, but may be any software application operable on a contactless card or other device having limited memory. The one or more counters 104 may comprise a numeric counter sufficient to store an integer number. The customer ID 107 may include a unique alphanumeric identifier assigned to a user of the contactless card 101, which identifier may distinguish the user of the contactless card from other contactless card users. In some examples, the customer ID 107 may identify both the customer and the account assigned to the customer, and may further identify the contactless card 101 associated with the customer's account.

[0068] Although the processor 530 and memory elements of the exemplary embodiments described above have been described with reference to the contact pad 520, the invention is not so limited. It will be appreciated that these elements may be implemented outside of the contact pad 520, may be implemented completely separate from the contact pad 520, or may be implemented as additional elements in addition to the processor 530 and memory 102 elements located within the contact pad 520.

[0069] In some examples, the contactless card 101 may include one or more antennas 555. The one or more antennas 555 may be disposed within the contactless card 101 and around the processing circuit 525 of the contact pad 520. For example, the one or more antennas 555 may be integral with the processing circuit 525, or the one or more antennas 555 may be used with an external booster coil. As another example, the one or more antennas 555 may be external to the contact pad 520 and the processing circuit 525.

[0070] In one embodiment, the coil of the contactless card 101 may function as the secondary of an air core transformer. The terminal may communicate with the contactless card 101 by interrupting the power or amplitude modulation. The contactless card 101 may use a gap in the power connection of the contactless card 101 to infer data sent from the terminal, which may be functionally maintained by one or more capacitors. The contactless card 101 may return communication by switching a load or load modulation on the coil. Load modulation may be detected on the terminal's coil due to interference. More generally, using the antenna 555, the processor 530, and / or the memory 102, the contactless card 101 provides a communication interface to communicate via NFC, Bluetooth, and / or Wi-Fi communications.

[0071] As described above, the contactless card 101 may be built on a software platform capable of running on a smart card or other device with limited memory, such as JavaCard, and may securely execute one or more applications or applets. An applet 103 may be added to the contactless card to provide a one-time password (OTP) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet 103 may respond to one or more requests, such as a near-field wireless data exchange request, from a reader, such as a mobile NFC reader (e.g., in a mobile device or point-of-sale terminal), and generate an NDEF message that includes the cryptographically secure OTP encoded as an NDEF text tag.

[0072] One example of an NDEF OTP is the NDEF Short Record Layout (SR=1). In such an example, one or more applets 103 may encode the OTP as a well-known type of text tag in NDEF Type 4. In some examples, the NDEF message may include one or more records, such as a ciphertext and an unencrypted customer ID 107 (or other unencrypted unique identifier for the card 101 and / or associated account). The applet 103 may add one or more static tag records in addition to the OTP records.

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

[0074] In some examples, the contactless card 101 and the server 120 may include specific data to allow the card to be properly identified. The contactless card 101 may include one or more unique identifiers (not shown). Each time a read operation is performed, the counter 104 may increment. In some examples, each time data from the contactless card 101 is read (e.g., by the computing device 110), the counter 104 is sent to the server for validation, and it is determined (as part of the validation) whether the counter 104 is equal to the value of the counter 104 on the server.

[0075] The one or more counters 104 may prevent replay attacks. For example, if a cryptogram is captured and replayed, the cryptogram is immediately rejected if the counter 104 is read, used, or passed on. If a counter 104 is not used, it may be replayed. In some examples, the counter incremented on the card is different from the counter incremented for the transaction. Because there is no communication between the applets 103 on the contactless card 101, the contactless card 101 cannot determine the application transaction counter 104. In some examples, the contactless card 101 may include a first applet 103-1, which may be a transaction applet, and a second applet 103-2, which may be an authentication applet that authenticates the call as disclosed herein. Each applet 103-1 and 103-2 may include a respective counter 104.

[0076] In some examples, the counter 104 may get out of sync. In some examples, the counter 104 may be incremented to account for an accidental read that initiates a transaction, such as an oblique read, but the application does not process the counter 104. In some examples, when the device 110 is woken up, NFC may be performed. Enabled, the device 110 may be configured to read an available tag, but no action is taken in response to the read.

[0077] To keep the counter 104 synchronized, an application such as a background application may be executed to detect when the device 110 wakes up and synchronize with a server (e.g., server 120) of the banking system where the detection to advance the counter 104 indicates that a read has occurred. In another example, a hashed one-time password may be utilized to accommodate a window of mis-synchronization. For example, if within a threshold of 10, the counter 104 may advance. However, if within a different threshold, e.g., 10 or 1000, a request to perform a re-synchronization via one or more applications, which the user taps, gestures, or indicates one or more times via the user's device, may be processed. If the counter 104 increments in the proper order, the user may know that an increment has occurred.

[0078] The key diversification technique described herein with reference to the counter 104, the master key, and the diversification key is one example of an encryption and / or decryption key diversification technique, and it should be apparent that this example key diversification technique should not be considered as limiting of the present disclosure, as the present disclosure is equally applicable to other types of key diversification techniques.

[0079] During the contactless card 101 creation process, two encryption keys may be uniquely assigned for each card. The encryption keys may include symmetric keys that can be used to both encrypt and decrypt data. The Triple DES (3DES) algorithm may be used by EMV and is implemented by hardware within the contactless card 101. A key diversification process may be used to derive the master key or keys based on uniquely identifiable information for each entity needing a key.

[0080] In some examples, to overcome deficiencies in the 5DES algorithm that are susceptible to vulnerabilities, a session key can be derived (such as a unique key per session), but rather than using a master key, a unique card derived key can be used, and a counter can be used as diversification data. For example, each time the contactless card 101 is used in operation, a different key can be used to create the message authentication code (MAC) and perform the encryption. This results in three layers of encryption. The session key can be derived using an application transaction counter generated by one or more applets and with one or more algorithms (defined in EMV 3.3 Book 2 A1.3.1 Common Session Key Derivation).

[0081] Additionally, the increments for each card are unique and may be assigned by personalization or algorithmically by some identifying information. For example, odd numbered cards may increment by 2 and even numbered cards may increment by 5. In some instances, the increments may vary even with sequential reading, such that a card is incremented by 1, 3, 5, 2, 2, ... repeatedly. The specific sequence or algorithmic sequence may be defined during personalization or from one or more processes derived from a unique identifier. This can make it difficult for a replay attacker to generalize from a small number of card instances.

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

[0083] FIG. 6 illustrates an NDEF short record layout (SR=1) data structure 600 according to an example embodiment. One or more applets may encode the OTP as a text tag of NDEF type 4 well-known type. 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. Non-limiting examples of tags are shown below: Tag type: well-known type, text, encoding English (en); Applet ID: D2760000850104; Capabilities: read-only access; Encoding: Authentication messages may be encoded as ASCII hex; type-length-value (TLV) data may be provided as personalization parameters that can be used to generate the NDEF message. In one embodiment, the authentication template may include a first record with a well-known index that provides the actual dynamic authentication data. In various embodiments, the payload of the data structure 600 may store ciphertext (e.g., the encrypted customer ID 107) and any other relevant data, such as the unencrypted customer ID 107 and / or some other unencrypted value that uniquely identifies the card 101 and / or the account associated with the card 101.

[0084] 7 illustrates an embodiment of an exemplary computer architecture 700 comprising a computer system 702 suitable for implementing various embodiments as described above. In one embodiment, the computer architecture 700 may include or be implemented as part of the computer system 100. In some embodiments, the computer system 702 may be, for example, the contactless card 101, the computing device 110, and the servers 120, 140, 150, and 160 of the system 101. The embodiments are not limited thereto. More generally, the computer architecture 700 is configured to implement all logic, applications, systems, methods, apparatus, and functions described herein with reference to FIGS. 1A-6.

[0085] The terms "system" and "component" as used in this application are intended to refer to any computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, an example of which is provided by the exemplary computer architecture 700. For example, a component may be, but is not limited to, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and / or magnetic storage media), an object, an executable file, a thread of execution, a program, and / or a computer. By way of example, both an application running on a server and the server may be a component. One or more components may reside within a process and / or thread of execution, and a component may be localized on one computer or distributed among two or more computers. Furthermore, components may be communicatively coupled to one another by various types of communication media to coordinate operations. Coordination may include unidirectional or bidirectional exchange of information. For example, components may communicate information in the form of signals communicated over the communication media. The information may be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, in further embodiments, it may instead be a data message. Such data messages may be transmitted over various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0086] Computer architecture 700 may include various typical computer elements, such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, power supplies, etc. However, embodiments are not limited to implementation with computer architecture 700.

[0087] 7, computer architecture 700 includes a processor 704, a system memory 706, and a system bus 708. The processor 704 may be any of various commercially available processors.

[0088] The system bus 708 provides a system component interface including, but not limited to, the system memory 706 to the processor 704. The system bus 708 may be any of several types of bus structures that may be further interconnected to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. Interface adapters may be connected to the system bus 708 through a slot architecture. Examples of slot architectures include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, (Enhanced) Industry Standard Architecture ((E)ISA), MicroChannel Architecture (MCA), NuBus, Peripheral Component Interconnect (Expanded) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and the like.

[0089] Computer architecture 700 may include or be implemented in a variety of articles of manufacture. The articles of manufacture may include a computer-readable storage medium that stores logic. Examples of computer-readable storage media may include tangible media capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re-writeable memory. Examples of logic may 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. Embodiments may also be implemented at least in part as instructions contained in or on a non-transitory computer-readable medium, which may be read and executed by one or more processors to enable performance of the operations described herein.

[0090] The system memory 706 may include 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, phase change non-volatile storage device (Ovonic-memory), phase change memory or ferroelectric memory, silicon oxide nitride oxide silicon (SONOS) memory, magnetic or optical cards, memory such as arrays of devices such as Redundant Array OF Independent Disks (RAID) drives, solid state memory devices (e.g., USB memory, solid state drives (SSD), and any other type of storage medium suitable for storing information. In the exemplary embodiment shown in FIG. 7, the system memory 706 may include a non-volatile memory 710 and / or a volatile memory 712. A basic input / output system (BIOS) may be stored in the non-volatile memory 710.

[0091] The computer 702 may include various types of computer-readable storage media in the form of one or more low-speed memory units, including an internal (or external) hard disk drive 730, a magnetic disk drive 716 that reads from and writes to a removable magnetic disk 720, and an optical disk drive 728 that reads from and writes to a removable optical disk 732 (e.g., a CD-ROM or DVD). The hard disk drive 730, the magnetic disk drive 716, and the optical disk drive 728 may be connected to the system bus 708 by a HDD interface 714, a FDD interface 718, and an optical disk drive interface 734, respectively. The HDD interface 714 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

[0092] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-executable instructions, and the like. A number of program modules may be stored in the drives and nonvolatile memory 710, and in the volatile memory 712, including, for example, an operating system 722, one or more applications 742, other program modules 724, and program data 726. In an embodiment, the one or more applications 742, other program modules 724, and program data 726 may include various applications and / or components of the system 100, such as, for example, applets 103, counters 104, master keys 105, diversified keys 106, customer IDs 107, URLs 108, web browsers 113, financial institution server 120, authentication applications 123, account data 124, payment processing server 140, payment processing data 141, electronic commerce server 150, web pages 151, transaction database 152, application server 160, and on-demand application 161.

[0093] A user can input commands and information into the computer 702 through one or more wired / wireless input devices, such as a keyboard 750 and a pointing device, such as a mouse 752. Other input devices can include a microphone, an infra-red (IR) remote, a radio frequency (RF) remote, a game pad, a stylus pen, a card reader, a dongle, a fingerprint reader, a glove, a graphic tablet, a joystick, a keyboard, a retina reader, a touch screen (e.g., capacitive, resistive, etc.), a track ball, a track pad, a sensor, a stylus, etc. These and other input devices are often connected to the processor 704 through an input device interface 736 coupled to the system bus 708, but can also be connected by other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.

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

[0095] The computer 702 can operate in a networked environment using logical connections via wired and / or wireless communications to one or more remote computers, such as a remote computer 748. The remote computer 748 can be a workstation. A server computer, a router, a personal computer, a portable computer, a microprocessor-based entertainment device, a peer device, or other common network node, typically includes many or all of the elements described relative to the computer 702, although for purposes of brevity, only memory and / or storage 758 is shown. The depicted logical connections include wired / wireless connections to a local area network 756 and / or larger networks, e.g., a wide area network 754. Such LAN and WAN networking environments are commonplace in offices and businesses, facilitating enterprise-wide computer networks, such as intranets, all of which may be connected to a global communications network, such as the Internet.

[0096] When used in a local area network 756 networking environment, the computer 702 is connected to the local area network 756 through a wired and / or wireless communication network interface or adapter 738. The network adapter 738 may facilitate wired and / or wireless communication. Wireless communication to the local area network 756. The local area network 756 may also include a wireless access point disposed on the local area network 756 to communicate with the wireless capabilities of the network adapter 738.

[0097] When used in a wide area network 754 networking environment, the computer 702 may include a modem 740, or may be connected to a communications server on the wide area network 754, or have other means of establishing communications over the wide area network 754, such as the Internet. The modem 740 may be internal or external, and a wired and / or wireless device, and connects to the system bus 708 via the input device interface 736. In a networked environment, the program modules depicted relative to the computer 702, or portions thereof, will be understood to be exemplary and that other means of establishing a communications link between the computers may be used.

[0098] The computer 702 is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively arranged for wireless communication (e.g., IEEE 802.11 wireless modulation technology). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, Bluetooth wireless technology, and the like. Thus, communication can be of a predefined structure, similar to a traditional network, or a simple ad-hoc communication between at least two devices. A Wi-Fi network provides secure, reliable, high-speed wireless connectivity using radio technologies called IEEE 802.11 (a, b, g, n, etc.). A Wi-Fi network can be used to connect computers to each other, to the Internet, and to wired networks (using IEEE 802.3 related media and functions).

[0099] The various elements of the apparatus described above with reference to Figures 1A-7 may include various hardware elements, software elements, or a combination of both. Examples of hardware elements may include apparatus, 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, chipsets, etc. Examples of software elements may 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, computer code, computer code, code segments, computer code segments, words, values, symbols, or combinations thereof. However, the decision whether an embodiment is implemented using hardware and / or software elements may vary according to any number of factors, such as computational speed, power levels, thermal tolerances, processing cycle budgets, input data rates, output data rates, memory resources required for a particular implementation, data bus speeds, and other design or performance constraints, depending on the desires of a given implementation.

[0100] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium that represent various logic within a processor and, when read by a machine, cause the machine to construct logic that performs the techniques described herein. Such representations, known as "IP cores," may be stored on tangible machine-readable media and provided to various customers or manufacturing facilities to be loaded into manufacturing machines that produce the logic or processors. Some embodiments may be implemented using a machine-readable medium or article that may store, for example, instructions or sets of instructions that, when executed by a machine, cause the machine to perform methods and / or operations in accordance with the embodiments. Such machines may include, for example, any suitable processing platform, computer platform, computing device, processing device, computer system, processing system, computer, processor, etc., and may be implemented using any suitable combination of hardware and / or software. A machine-readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage object, 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 disks, floppy disks, compact disk read only memory (CD-ROM), compact disk writeable (CD-R), compact disk rewriteable (CD-RW), optical disks, magnetic media, magneto-optical media, removable memory cards or disks, various types of DVDs (Digital Versatile Disks), tapes, cassettes, etc. The instructions may include any suitable type of code implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc.

[0101] The components and features of the devices described above may be implemented using any combination of discrete circuits, application specific integrated circuits (ASICs), logic gates, and / or single chip architectures. Furthermore, the functionality of the devices may be implemented using microcontrollers, programmable logic arrays, and / or microprocessors, or any combination of the foregoing, where appropriate. It should be noted that hardware, firmware, and / or software elements may be referred to herein collectively or individually as "logic" or "circuitry."

[0102] It will be appreciated that the exemplary devices depicted in the block diagrams above may represent one functionally illustrative example of many possible implementations. Thus, the division, omission, or inclusion of block functions depicted in the accompanying drawings does not necessarily imply that the hardware components, circuits, software, and / or elements implementing those functions are necessarily divided, omitted, or included in the embodiments.

[0103] At least one computer-readable storage medium can contain instructions that, when executed, cause the system to perform any of the computer-implemented methods described herein.

[0104] Some embodiments may be described using the phrase "in one embodiment" and its derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in this specification do not necessarily all refer to the same embodiment. Moreover, unless otherwise noted, the above features may be used in any combination. Thus, any features discussed individually may be used in combination with each other, unless it is noted that the features are not compatible with each other.

[0105]

[0023] Generally referring to the notation and nomenclature used herein, the detailed descriptions herein may be presented in terms of program procedures executed on a computer or network of computers. These procedural descriptions and representations are used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art.

[0106] A procedure here is generally conceived to be a self-consistent sequence of operations leading to a desired result. These operations are those requiring physical manipulation of physical quantities. Usually, without limitation, these quantities take the form of electrical, magnetic or optical signals capable of being stored, transferred, combined, compared and otherwise manipulated. It is sometimes convenient, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. However, all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

[0107] Further, the manipulations performed are often referred to in terms, such as adding or comparing, which are commonly associated with mental operations performed by a human operator. No such capability of a human operator is necessary, and in most cases is desirable, in any of the operations described herein that form part of one or more of the embodiments. Rather, the operations are machine operations. Useful machines for performing the operations of the various embodiments include general purpose digital computers or similar devices.

[0108] Some embodiments may be described using the terms "coupled" and "connected" along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments may be described using the terms "connected" and / or "coupled" to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term "coupled" may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0109] Various embodiments also relate to apparatus or systems for performing these operations. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. The procedures described herein are not inherently related to any particular computer or other apparatus. Various general-purpose machines may be used with programs written in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these machines will be apparent from the description given.

[0110] It is emphasized that the Abstract of the Disclosure is provided to enable the reader to quickly ascertain the nature of the technical disclosure. It is not used to interpret or limit the scope or meaning of the claims. Moreover, in the foregoing detailed description, various features have been grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure should not be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, the inventive subject matter lies in less than all features of a single disclosed embodiment. Accordingly, the following claims are incorporated into the detailed description, with each claim standing on its own as a separate embodiment. In the appended claims, the terms "comprises" and "in which" are used as the plain English equivalents of the respective terms "comprises" and "wherein." Moreover, terms such as "first," "second," and "third" are merely used as labels and are not intended to impose numerical requirements on their subject matter.

[0111] The above description includes examples of the disclosed architecture. Of course, it is not possible to describe every conceivable combination of components and / or methodologies, but one of ordinary skill in the art will recognize that many more combinations and permutations are possible. Accordingly, the novel architecture is intended to embrace all such alterations, modifications, and variations that fall within the spirit and scope of the appended claims.

Claims

1. A computer-implemented method comprising: downloading, by a processor of the device, the application from the application server based on a selection of a link in the web browser on the merchant web page; selecting, by the application, a first financial institution based on a plurality of financial institution applications installed on the device; receiving, by the application, encrypted data from a contactless card associated with an account at the first financial institution; transmitting, by the application, the encrypted data to an authentication server of the first financial institution; receiving, by the application, an authentication result identifying that the authentication server has decrypted the encrypted data; receiving, by the web browser, payment information associated with the account based on decryption of the encrypted data by the authentication server; providing, by the web browser, payment information to a server associated with the application for processing the transaction; The method includes:

2. Selecting the first financial institution includes calculating, by the application, a respective score for each of the plurality of financial institution applications; the first financial institution is associated with a first financial institution application of the plurality of financial institution applications installed on the device; The method of claim 1.

3. The score is calculated based on (i) the elapsed time since each of the financial institution applications was used on the device, and (ii) the number of times each of the financial institution applications was used on the device. The method of claim 2.

4. The method further comprising storing, by the web browser, a cookie on the device based on instructions received from the server associated with the application; the instructions specify that the payment information has been used to process a payment for the transaction. The method of claim 1.

5. prior to providing the payment information to the server associated with the application; receiving, by the device, a one-time passcode from the authentication server to a phone number of the device; receiving, by the application, an input value; comparing, by the application, the input value with the one-time passcode; determining, by the application, that the input value and the one-time passcode match based on the comparison; Further comprising: the application transmits the encrypted data to the authentication server based at least in part on a determination that the input value matches the one-time passcode. The method of claim 1.

6. the link includes a first identifier of a first merchant associated with the merchant webpage and a transaction identifier associated with the transaction; the first seller is one of a plurality of sellers; the merchant web page being one of a plurality of merchant web pages on a web server; The method of claim 1.

7. The web server hosts the plurality of merchant web pages; each merchant web page is associated with a respective one of the plurality of merchants; Each merchant is associated with a respective identifier of the plurality of identifiers, including the first identifier; the server associated with the application includes one of a payment processing server or a web server; The method according to claim 6.

8. The application is a non-persistent on-demand application, The link is a deep link URL or a universal link URL. The method of claim 1.

9. a page identifier parameter of the link identifies a page of the application; identifying, by the application, the page identifier parameter; opening, by the application, a page of the application based on the page identifier parameter; 2. The method of claim 1, comprising:

10. The payment information includes an account number, an expiration date associated with the account number, and a card verification value (CVV) associated with the account number; The method includes, before downloading the application, by the web browser: The method of claim 1 , further comprising receiving a selection of a link.

11. A non-transitory computer-readable storage medium comprising instructions that, when executed by a processor of a device, cause the processor to: The instruction: downloading the application from the application server based on a selection of a link in the web browser on the merchant web page; selecting, by the application, a first financial institution based on a plurality of financial institution applications installed on the device; receiving, by the application, encrypted data from a contactless card associated with an account at the first financial institution; transmitting, by the application, the encrypted data to an authentication server of the first financial institution; receiving, by the application, an authentication result identifying that the authentication server has decrypted the encrypted data; receiving, by the web browser, payment information associated with the account based on decrypting the data encrypted by the authentication server; providing, by the web browser, the payment information to a server associated with the application for processing the transaction; Including, A computer-readable storage medium.

12. Selecting the first financial institution includes calculating, by the application, a respective score for each of the plurality of financial institution applications; the first financial institution is associated with a first financial institution application of the plurality of financial institution applications installed on the device; The computer-readable storage medium of claim 11.

13. The instructions further include causing the processor to: receiving, by the web browser, a confirmation of the transaction being processed; and displaying, by the web browser, the confirmation; and Execute the The computer-readable storage medium of claim 11.

14. The instructions further include causing the processor to: storing cookies on the device based on instructions received by the web browser from the server associated with the application; Run the command, the instructions specify that the payment information has been used to process a payment for the transaction. The computer-readable storage medium of claim 11.

15. The instructions further cause the processor, prior to providing the payment information to the server associated with the application, to: receiving, by the device, a one-time passcode from the authentication server to a phone number of the device; receiving, by the application, an input value; comparing, by the application, the input value with the one-time passcode; determining, by the application, that the input value matches the one-time passcode based on the comparison; Run the command, the application transmits the encrypted data to the authentication server based at least in part on a determination that the input value matches the one-time passcode. The computer-readable storage medium of claim 11.

16. The computer device comprises: a processor and a memory storing instructions that are executable by the processor to cause the processor to: The instruction: downloading the application from the application server based on a selection of a link in the web browser on the merchant web page; selecting, by the application, a first financial institution based on a plurality of financial institution applications installed on the computing device; receiving, by the application, encrypted data from a contactless card associated with an account at the first financial institution; transmitting, by the application, the encrypted data to an authentication server of the first financial institution; receiving, by the application, an authentication result identifying that the authentication server has decrypted the encrypted data; receiving, by the web browser, payment information associated with the account based on decryption of the encrypted data by the authentication server; providing, by the web browser, the payment information to a server associated with the application for processing the transaction; Including, Computer equipment.

17. Selecting the first financial institution comprises: calculating, by said application, a respective score for each of a plurality of said financial institution applications; the first financial institution is associated with a first financial institution application of a plurality of financial institution applications installed on the computing device; 17. The computer device of claim 16.

18. The instructions further include causing the processor to: receiving, by the web browser, a confirmation of the transaction being processed; and displaying, via the web browser, a confirmation; Execute the 17. The computer device of claim 16.

19. The instructions further include causing the processor to: storing a cookie in the memory based on instructions received by the web browser from a server associated with the application; Execute the 17. The computer device of claim 16.

20. The instructions further cause the processor, prior to providing the payment information to the server associated with the application, to: receiving, by the computing device, a one-time passcode from the authentication server to a phone number of the computing device; receiving, by the application, an input value; comparing, by the application, the input value with the one-time passcode; determining, by the application, that the input value matches the one-time passcode based on the comparison; Run the command, the application transmits the encrypted data to the authentication server based at least in part on a determination that the input value matches the one-time passcode.

17. The computer device of claim 16.

Images