Web-based activation of contactless cards

Abstract

To provide a computing device for secure and web-based activation of a contactless card.SOLUTION: The computing device wirelessly receives a network address of a resource from the contactless card in a disabled payment state, a web browser executing on the computing device accesses the network address resource, the web browser resource operates a card reader of the computing device to receive a cryptogram from the contactless card, the web browser resource transmits the cryptogram to a server, and the web browser resource receives a response from the server specifying that the contactless card has transitioned from the disabled payment state to the enabled payment state.SELECTED DRAWING: Figure 5

Description

Related Applications

[0001] This application claims priority to U.S. Patent Application No. 17 / 088,399, entitled "WEB-BASED ACTIVATION OF CONTACTLESS CARDS," filed November 3, 2020, the contents of which are incorporated herein by reference in their entirety. [Technical Field]

[0002] FIELD OF THE INVENTION The embodiments disclosed herein relate generally to computing platforms, and more particularly to computing platforms for secure, web-based activation of contactless cards. [Background technology]

[0003] Payment cards are often mailed to customers in a payment-disabled (or inactive) state so that payments cannot be processed (and / or other operations) using the payment card until it is activated. Traditional activation solutions include requiring customers to use telephone calls, dedicated applications, and other technologies to activate contactless cards. However, such traditional solutions may result in security exposure, user error, or other adverse effects. Furthermore, the need for dedicated applications (e.g., applications provided by the payment card issuer) does not scale well as the number of cards and customers increases. Summary of the Invention

[0004]

[0006] Embodiments disclosed herein provide systems, methods, articles of manufacture, and computer-readable media for secure, web-based activation of contactless cards. In one example, a computing device may receive a network address for a resource from a contactless card that is in an inactivated payment state. A web browser executing on the computing device may access the resource at the network address. The web browser resource may operate a card reader of the computing device to receive a cryptogram from the contactless card. The web browser resource may transmit the cryptogram to a server. The web browser resource may receive a response from the server specifying that the contactless card has transitioned from the inactivated payment state to the activated payment state. [Brief explanation of the drawings]

[0005] [Figure 1A] 1 illustrates an embodiment of a system. [Figure 1B] 1 illustrates an embodiment of a system. [Figure 1C] 1 illustrates an embodiment of a system. [Figure 1D] 1 illustrates an embodiment of a system. [Figure 2A] 1 illustrates an embodiment of a system. [Figure 2B] 1 illustrates an embodiment of a system. [Figure 2C] 1 illustrates an embodiment of a system. [Figure 2D] 1 illustrates an embodiment of a system. [Figure 3A] An example of a contactless card is shown. [Figure 3B] An example of a contactless card is shown. [Figure 4] 1 illustrates a data structure according to one embodiment. [Figure 5] 1 shows a first logic flow. [Figure 6] 2 shows a second logic flow. [Figure 7]A third logic flow is shown. [Figure 8] 1 illustrates a computer architecture according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0006] Embodiments disclosed herein provide techniques for securely activating a payment card using a web browser on a computing device. The computing device may not have a dedicated application installed that facilitates payment card activation. For example, a bank or other financial institution may provide a dedicated application that can be used to activate a payment card. However, a user may not have such an application installed on one of their computing devices. However, embodiments disclosed herein advantageously can utilize a web page within a web browser to securely read data from a contactless card via near field communication (NFC). As described in more detail herein, the data read via NFC can be used to activate the payment card.

[0007] In one embodiment, a user may receive a contactless payment card that is in a payment-disabled state such that it must be activated before it can be used to process payments. The user may tap the card against a computing device. In doing so, the card generates a network address, such as a uniform resource locator (URL), for a server. The URL may generally be directed to one or more card-activation web pages associated with the server. Upon receiving the URL, the operating system of the computing device may launch a web browser. Once launched, the web browser can access the URL received from the contactless card.

[0008] The web browser may receive and display a web page at the URL. The web page may include functionality for communicating with a contactless card, for example, via NFC. The web page may instruct the user to tap the contactless card to the device. In response, the user taps the contactless card to the device, and the web page and / or web browser may operate the device's card reader. Doing so may cause the contactless card to generate or instruct it to generate a cryptogram, which may be included as part of a data package, such as an NFC Data Exchange Format (NDEF) file. The data package may also include an unencrypted customer identifier (ID) or other unique identifier. The web page and / or web browser may read the data package via NFC and send it to a server for decryption. The server may attempt to decrypt the cryptogram using the received data package. If the server is able to decrypt the cryptogram, the server may activate the contactless card, for example, by updating a database record to reflect that the card has transitioned from a disabled to an enabled payment state. The server may then send a response to the web browser reflecting that the card has been activated and is now available to process payments (and / or perform other operations).

[0009] Advantageously, embodiments disclosed herein provide techniques for securely activating payment cards. By leveraging cryptography generated by contactless cards, embodiments of the present disclosure may securely verify the identity of users requesting activation while minimizing the risk of fraud. Furthermore, by using a web browser, a dedicated client application is not required to activate cards and / or to communicate data with contactless cards. By using a web browser, the functionality described herein may be advantageously scaled to various entities and any number of users without requiring a dedicated application. Furthermore, by providing a simplified activation process, more activation requests may be processed by the server, thereby improving system performance.

[0010] To generally refer to the notation and nomenclature used herein, one or more portions of the detailed descriptions which follow 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 is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. These operations require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It proves convenient at times, principally 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.

[0011] Further, these operations are often referred to in terms, such as adding or comparing. These terms 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 mechanical operations. Useful machines for performing the operations of the various embodiments include digital computers selectively activated or configured by a computer program stored therein as described in accordance with the teachings herein, and / or apparatuses specially constructed for the required purpose or digital computers. Various embodiments also relate to apparatuses or systems for performing these operations. These apparatuses may be specially constructed for the required purpose. The required structure for these various machines will be apparent from the description given.

[0012] 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. It will be apparent, however, 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. It is the intention to cover all modifications, equivalents, and alternatives within the scope of the claims.

[0013] 1A depicts an exemplary system 100 consistent with disclosed embodiments. While system 100 depicted in FIGS. 1A-1D has a limited number of elements in one topology, it can be understood that system 100 may include more or fewer elements in alternative topologies as desired for a given implementation.

[0014] As shown, system 100 includes one or more contactless cards 101, one or more computing devices 110, and one or more servers 120. Contactless card 101 represents any type of payment card, such as a credit card, a debit card, an ATM card, a gift card, etc. Contactless card 101 may include one or more communication interfaces 109, such as a radio frequency identification (RFID) chip, configured to communicate with a communication interface 118 (also referred to herein as a “card reader,” “wireless card reader,” and / or “wireless communication interface”) of computing device 110 via NFC, the EMV standard, or other short-range protocols for wireless communication. While NFC is used herein as an exemplary communication protocol, the present disclosure is equally applicable to other types of wireless communication, such as the EMV standard, Bluetooth, and / or Wi-Fi.

[0015] Computing device 110 represents any number and type of computing device, such as a smartphone, a tablet computer, a wearable device, a laptop, a portable gaming device, a virtual computing system, a merchant terminal, a point of sale system, a server, a desktop computer, etc. Server 120 represents any type of computing device, such as a server, a workstation, a computing cluster, a cloud computing platform, a virtual computing system, etc. Although not shown for clarity, computing device 110, contactless card 101, and server 120 each include one or more processor circuits for executing programs, code, and / or instructions.

[0016] 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 configured to perform the operations described herein. Counter 104, master key 105, diversification key 106, and customer ID 107 are used to provide security in system 100, as described in more detail below.

[0017] As shown, memory 111 of mobile device 110 includes an instance of operating system (OS) 112. Exemplary operating systems 112 include Android® OS, iOS®, macOS®, Linux®, and Windows® operating systems. As shown, OS 112 includes web browser 115. Web browser 115 is an application that allows device 110 to access information over network 130 (e.g., via the Internet).

[0018] As shown, memory 122 of server 120 includes authentication application 123 and web server 127. While depicted as separate components of server 120, in some embodiments, authentication application 123 and web server 127 may be integrated into a single component, e.g., a single application that includes all of the related functionality described herein. Similarly, while depicted as parts of server 120, in some embodiments, authentication application 123 and web server 127 may be implemented on separate servers. Furthermore, authentication application 123 and / or web server 127 may be implemented in hardware, software, and / or a combination of hardware and software.

[0019] As described in more detail herein, authentication application 123 is configured to facilitate activation of one or more contactless cards 101 via web browser 115 without requiring device 110 to include a dedicated application for activating contactless cards to process payments (and / or other types of operations). Web server 127 is generally configured to process client requests from web browser 115 for web pages 134. In at least one embodiment, web server 127 and browser 115 communicate via Hypertext Transfer Protocol (HTTP).

[0020] As mentioned above, a given contactless card 101 may be mailed to a customer in a payment-disabled state, which generally means that the customer must activate the card 101 to process payments (e.g., by using the card 101 at a point-of-sale (POS) device to pay for a purchase, by using the card 101 to pay for an online purchase, etc.). However, to maintain the security of the contactless card 101 and / or any associated accounts in the account data 124, the system 100 may implement various techniques for securely activating the contactless card 101 using the web browser 115.

[0021] In the embodiment depicted in FIG. 1A , a user may tap contactless card 101 against device 110 (or alternatively, bring contactless card 101 within communication range of card reader 118 of device 110). Applet 103 on contactless card 101 may then generate URL 108-1 associated with a resource, such as server 120, one or more card activation web pages 134, or the like. More generally, URL 108 (and any other URL disclosed herein) may be associated with any component of server 120 and / or any resource associated with server 120. In some embodiments, applet 103 constructs URL 108 according to one or more rules. In some embodiments, contactless card 101 stores multiple URLs 108, and applet 103 selects URL 108-1 from the multiple URLs 108 based on one or more rules. In some embodiments, applet 103 may generate URL 108-1 by selecting one of multiple URLs 108 and adding dynamic data as one or more parameters of the URL.

[0022] In general, web page 134 may include a HyperText Markup Language (HTML) page, a JavaScript page, and / or any other type of page that can be displayed by web browser 115. In some embodiments, web page 134 and / or URL 108 may be associated with authentication application 123. In some embodiments, web page 134 may provide an interface for activating contactless card 101 using web page 134 in web browser 115. Additionally, in some embodiments, web page 134 may be associated with a web-based front end exposed by authentication application 123.

[0023] Once generated, OS 112 may read URL 108-1. OS 112 may be in any state, such as displaying one or more other applications and / or displaying a web browser on the home screen of OS 112. Regardless of the state of OS 112, reading URL 108-1 causes OS 112 to launch web browser 115 and / or bring web browser 115 to the foreground of OS 112.

[0024] 1B illustrates an embodiment in which OS 112 launches web browser 115 and provides URL 108 as a parameter to web browser 115. In doing so, web browser 115 generates request 133 specifying URL 108. Request 133 may be an HTTP request sent to web server 127. In response, web server 127 of server 120 sends web page 134-1 to web browser 115, and web browser 115 may load, display, or otherwise access web page 134-1.

[0025] 1C illustrates an embodiment in which web browser 115 has loaded web page 134-1. Advantageously, web page 134-1 includes functionality for wirelessly reading data generated by contactless card 101 and / or wirelessly writing data to memory 102 of contactless card 101. More generally, a given web page 134 and / or web browser 115 may include functionality to control communication interface 118 to communicate with card 101 without requiring a dedicated operating system application (e.g., an application store application) to perform these functions. In at least one embodiment, the functionality may be provided via one or more application programming interfaces (APIs). The APIs may be defined by a Web NFC Draft Community Group Report. Thus, web page 134-1 (and any other web page 134) may control the NFC functionality of communication interface 118 without requiring a dedicated application.

[0026] In some embodiments, web page 134-1 of web browser 115 may output a display requesting or instructing the user to tap contactless card 101 on device 110 to activate contactless card 101. Generally, when contactless card 101 is brought within communication range of communication interface 118 of device 110, applet 103 of contactless card 101 may generate a cryptogram. The cryptogram may be generated based on customer ID 107 of contactless card 101. The cryptogram may be generated based on any suitable cryptographic technique. In some embodiments, applet 103 may include the cryptogram and unencrypted customer ID 107 (and / or any other unique identifier) ​​in data package 117. In at least one embodiment, data package 117 including the cryptogram and unencrypted customer ID 107 is an NDEF file.

[0027] As mentioned above, the system 100 is configured to implement key diversification to protect data, sometimes referred to herein as key diversification technology. Generally, the server 120 (or other computing device) and the contactless card 101 may be provisioned 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. For example, when the contactless card 101 is manufactured, a unique master key 105 may be programmed into the memory 102 of the contactless card 101. 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 in another secure location, such as a hardware security module (HSM) 125). The master key 105 may be kept secret from all parties except the contactless card 101 and the server 120, thereby enhancing the security of the system 100. In some embodiments, applet 103 of contactless card 101 may encrypt and / or decrypt data (e.g., customer ID 107) using master key 105 and the data as input to a cryptographic algorithm. For example, encrypting customer ID 107 with master key 105 results in a cryptogram. Similarly, server 120 may encrypt and / or decrypt data associated with contactless card 101 using the corresponding master key 105.

[0028] In other embodiments, the master key 105 of the contactless card 101 and the server 120 may be used in combination with a counter 104 to enhance security using key diversification. The counter 104 includes a value that is synchronized between the contactless card 101 and the server 120. The counter value 104 may include a number 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 may increment the counter value 104. The applet 103 of the contactless card 101 may then provide the master key 105 and the counter value 104 as inputs to a cryptographic algorithm. The cryptographic algorithm generates a diversified key 106 as an output. The cryptographic algorithms may include encryption algorithms, hash-based message authentication code (HMAC) algorithms, cipher-based message authentication code (CMAC) algorithms, etc. Non-limiting examples of cryptographic 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 key diversification techniques are described in further detail in U.S. patent application Ser. No. 16 / 205,119, filed November 29, 2018. The aforementioned patent application is incorporated herein by reference in its entirety.

[0029] Continuing with the key diversification example, contactless card 101 may then encrypt data (e.g., customer ID 107 and / or any other data) using diversification key 106 and the data as input to a cryptographic algorithm. For example, encrypting customer ID 107 with diversification key 106 results in an encrypted customer ID (e.g., cipher) that is included in data package 117. Web browser 115 and / or web page 134 may then read data package 117, including the cipher and unencrypted customer ID 107, via communication interface 118.

[0030] Regardless of the encryption technique used, the web page 134 and / or web browser 115 may then transmit the data package 117 containing the cipher and the unencrypted customer ID 107 to the server 120 over the network 130. The web page and / or web browser 115 may further indicate to the server 120 that the data package 117 containing the cipher and the unencrypted customer ID 107 has been read from the contactless card 101 via the card reader 118 of the device 110. Upon receipt, the authentication application 123 and / or web server 127 may attempt to authenticate the cipher. For example, the authentication application 123 may attempt to decrypt the cipher using a copy of the master key 105 stored by the server 120. In some embodiments, the authentication application 123 may use the unencrypted customer ID 107 included in the data package 117 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 a cryptographic algorithm. The cryptographic algorithm produces as output a diversified key 106. The resulting diversified key 106 corresponds to the diversified key 106 of the contactless card 101 and may be used to decrypt the encryption in the data package 117.

[0031] Regardless of the decryption technique used, the authentication application 123 may successfully decrypt the cipher and thereby verify or authenticate the cipher in the data package 117 (e.g., by comparing the customer ID 107 generated by decrypting the cipher with 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). While the keys 105, 106 are depicted as being stored in the memory 122, the keys 105, 106 may be stored elsewhere, such as in a secure element and / or HSM 125. In such an embodiment, the secure element and / or HSM 125 may decrypt the cipher using the keys 105 and / or 106 and a cryptographic function. 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, authentication application 123 may activate the contactless card, for example, by updating a record in account data 124 corresponding to contactless card 101. The record may be updated to reflect that contactless card 101 has been transitioned from a disabled payment state to a enabled payment state. In some embodiments, authentication application 123 may send a decryption result to web browser 115 and / or web page 134-1 indicating whether the decryption was successful or unsuccessful. Web page 134-1 may then perform one or more actions based on whether the decryption result indicates that the cipher was decrypted and / or not decrypted.

[0032] However, if authentication application 123 is unable to decrypt the encryption and produce the expected result (e.g., customer ID 107 for the account associated with contactless card 101), authentication application 123 does not verify the encryption of data package 117. In such an instance, authentication application 123 may decide to abandon contactless card activation. Authentication application 123 and / or web server 127 may send an indication of the failed decryption to web browser 115. Web page 134-1 may then display an indication of the failed decryption, and therefore the failed card activation, to the user via the web browser.

[0033] 1D illustrates an embodiment in which authentication application 123 successfully decrypts data package 117, thereby verifying (or authenticating) the encryption. In response, authentication application 123 may store activation record 140 in account data 124. Activation record 140 reflects that contactless card 101 has been activated and can be used to process payments. Further, as illustrated, authentication application 123 and / or web server 127 transmits confirmation 139 to device 110. Confirmation 139 indicates that authentication application 123 successfully decrypted data package 117 and that contactless card 101 has been activated. Web page 134-1 may be updated to reflect confirmation 139. In another embodiment, confirmation 139 is web page 134, and web browser 115 may display web page 134 of confirmation 139.

[0034] In some embodiments, web page 134-1 may instruct the user to tap contactless card 101 to device 110. In response, web page 134-1 may control card reader 118 and cause card reader 118 to store an indication in memory 102 of contactless card 101 reflecting that card 101 has been activated. Doing so may cause portions of applet 103, a payment applet, and / or other logic within card 101 to be activated or otherwise made available.

[0035] Once activated, a customer may process a payment using contactless card 101. For example, the customer may use web browser 115 to visit a merchant's web page, provide payment information such as the card number, expiration date, and card verification value (CVV) of card 101, and pay for a purchase on the web page. The merchant's web page may then submit a request to server 120 to process the requested payment. Server 120 may approve the request based at least in part on activation record 140.

[0036] Advantageously, contactless card 101 is securely activated without requiring device 110 to run a dedicated client application provided by an entity associated with contactless card 101 (e.g., an application provided by a financial institution associated with contactless card 101). Additionally, the security of card 101 is enhanced by using a cryptogram generated by contactless card 101 as a condition for activation.

[0037] FIG. 2A is a schematic diagram 200 illustrating an exemplary computing device 110 consistent with disclosed embodiments. More specifically, FIG. 2A illustrates an embodiment in which the device 110 outputs a home screen or page of the OS 112 and the contactless card 101 is tapped to the device 110. Although a home screen is depicted, the OS 112 and / or the device 110 may be in any powered-on state when the contactless card 101 is tapped to the device 110. As described, when the card 101 is tapped to the device 110, the applet 103 may provide a URL to the device 110. For example, as described, the applet 103 may generate a link to be directed to a web page 134 for activating the contactless card. Thus, when the card 101 is tapped to the device in FIG. 2A, the card 101 is in a payment-disabled state and cannot be used to process payments. The applet 103 may then send the URL to the mobile device 110. Once received, OS 112 may perform an action such as, for example, launching a web browser 115 registered with OS 112 to open the URL, thereby advantageously providing a solution for URL-based authentication that does not require an active application running in the foreground of OS 112.

[0038] 2B is a schematic diagram 210 illustrating an embodiment in which a web browser 115 of a device 110 is launched upon receiving a URL 108-2 from the contactless card of FIG. 2A. Generally, the OS 112 may launch the web browser 115 and provide the URL 108-2 as input to the web browser 115. In doing so, the web browser may generate an HTTP request to access the resource at the specified URL 108-2. The URL 108-2 may generally be associated with one of a server 120, an authentication application 123, and / or a web page 134.

[0039] 2C is a schematic diagram 220 reflecting an embodiment in which web browser 115 has loaded and displayed web page 134-2 at URL 108-2 received from contactless card 101. Web page 134-2 may be received from web server 127 in response to an HTTP request from web browser 115 specifying URL 108-2. Web page 134-2 includes similar functionality to web page 134-1, including the ability to communicate with contactless card 101, for example, by reading data generated by contactless card 101 and / or by writing data to the memory of contactless card 101. Thus, more generally, web page 134-2 and / or web browser 115 may generally control the NFC functionality of communication interface 118 and communicate with contactless card 101 via NFC.

[0040] As shown, web page 134-2 instructs the user to tap contactless card 101 against computing device 110 to activate card 101. When card 101 comes within range of card reader 118, web page 134-2 controls card reader 118 to instruct applet 103 on contactless card 101 to generate diversification key 106 as described above and to generate a cipher (e.g., encrypted customer ID 107) using generated diversification key 106. Applet 103 may further generate an NDEF file or other data package that includes the cipher and the unencrypted identifier (e.g., unencrypted customer ID 107).

[0041] Web browser 115 and / or web page 134-2 may then read the data package or NDEF file, for example, via NFC. Once read, web browser 115 and / or web page 134-2 may send the data package to server 120 for processing. Web page 134-2 may optionally process the data package, for example, to format the data package. Web page 134-2 and / or web browser 115 may further indicate to server 120 that a cryptogram has been read from contactless card 101 via card reader 118 of device 110.

[0042] Upon receipt, authentication application 123 may attempt to verify the encryption in the data package. In at least one embodiment, the unencrypted customer ID 107 provided by applet 103 may be used by authentication application 123 to identify the associated account in account data 124, counter value 104, and / or master key 105. Authentication application 123 may attempt to decrypt the encryption by providing master key 105 and incremented counter value 104 as inputs to a cryptographic algorithm. The cryptographic algorithm generates diversified key 106 as output. The resulting diversified key 106 may correspond to the instance of diversified key 106 generated by contactless card 101 to generate the encryption and may be used to decrypt the encryption. Generally, authentication application 123 may transmit a decryption result to web browser 115 and / or web page 134-2 indicating whether the decryption was successful or unsuccessful. If the decryption is successful, authentication application 123 may transition contactless card 101 from a payment-disabled state to a payment-enabled state, for example, by updating one or more records in account data 124 .

[0043] 2D is a schematic diagram 230 illustrating an embodiment in which server 120 decrypts the cipher generated by contactless card 101 and read by web page 134-2. As described above, server 120 may activate contactless card 101 for payment based on decrypting the cipher generated by contactless card 101. Server 120 may communicate the results of the decryption to web page 134-2. As shown, web page 134-2 is updated to reflect that the decryption was successful and that contactless card 101 is activated to process payments.

[0044] FIG. 3A is a schematic diagram 300 illustrating an example configuration of a contactless card 101. The contactless card 101 may include a payment card, such as a credit card, debit card, or gift card, issued by a service provider, with service provider indicia 302 displayed on the front or back of the contactless card 101. In some examples, the contactless card 101 may be unrelated to payment cards and may include, but is not limited to, identification. In some examples, the contactless card may include a dual-interface contactless payment card, a rewards card, or the like. The contactless card 101 may include a substrate 310. The substrate may include a single layer or one or more laminated layers of plastic, metal, and other materials. Exemplary substrates include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium oxide, 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 the contactless card may otherwise conform to the ISO / IEC 14443 standard. However, it will be understood that contactless card 101 according to the present disclosure may have different characteristics, and the present disclosure does not require that the contactless card be implemented as a payment card.

[0045] The contactless card 101 may include identification information 315 displayed on the front and / or back of the card and a contact pad 320. The contact pad 320 may include one or more pads and be configured to establish a connection with another client device, such as an ATM, user equipment, a smartphone, a laptop, a desktop, or a tablet computer, 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 the EMV protocol. The contactless card 101 may also include processing circuitry, an antenna, and other components, as further described in FIG. 3B . These components may be located behind the contact pad 320 or elsewhere on the substrate 310, such as in a different layer of the substrate 310, and may be electrically and physically coupled to the contact pad 320. 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. 3A ). The contactless card 101 may also include a Near Field Communication (NFC) device coupled to an antenna capable of communicating via an NFC protocol. Embodiments are not limited in this manner.

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

[0047] In some embodiments, memory 102 may be read-only memory, write-once read-multiple memory, or read / write memory, such as RAM, ROM, or EEPROM, and contactless card 101 may include one or more of these memories. Read-only memory may be factory programmable as read-only, or may be programmable only once. One-time programmability provides the opportunity to write once and read many times. Write-once read-multiple memory may be programmed at a time after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten but 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 implementations, memory 102 may be encrypted memory that utilizes an encryption algorithm executed by processor 330 to encrypt data.

[0048] The memory 102 may be configured to store one or more applets 103, one or more counters 104, a master key 105, a diversification key 106, a customer ID 107, and one or more URLs 108. The one or more applets 103 may include one or more software applications configured to run on one or more contactless cards, such as a Java Card applet. However, it is understood that the applet 103 is not limited to a Java Card applet and may instead be any software application capable of running on a contactless card or other device with limited memory. The one or more counters 104 may include a numeric counter sufficient to store integers. The customer ID 107 may include a unique alphanumeric identifier assigned to a user of the contactless card 101, which identifier can distinguish the contactless card user 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.

[0049] Although the processor 330 and memory elements of the foregoing exemplary embodiments are described with reference to contact pads 320, the present disclosure is not limited thereto. It is understood that these elements may be implemented outside of contact pads 320, may be implemented completely separate therefrom, or may be implemented as additional elements in addition to the processor 330 and memory 102 elements disposed within contact pads 320.

[0050] In some examples, the contactless card 101 may include one or more antennas 355. The one or more antennas 355 may be disposed within the contactless card 101 and around the processing circuit 325 of the contact pads 320. For example, the one or more antennas 355 may be integral with the processing circuit 325, or the one or more antennas 355 may be used in conjunction with an external booster coil. As another example, the one or more antennas 355 may be external to the contact pads 320 and the processing circuit 325.

[0051] 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 disconnecting the power or amplitude modulation. The contactless card 101 may estimate data transmitted from the terminal using gaps in the contactless card 101's power connection, which may be maintained functionally via one or more capacitors. The contactless card 101 may return communication by switching the load on the coil or performing load modulation. Load modulation may be detected by interference on the terminal's coil. More generally, using one or more antennas 355, processor 330, and / or memory 102, the contactless card 101 provides a communication interface for communicating via NFC, Bluetooth, and / or Wi-Fi communications.

[0052] As described above, contactless card 101 may be built on a software platform capable of operating on a smart card or other device with limited memory, such as a Java Card, on which one or more applications or applets may be securely executed. Applet 103 may be added to the contactless card to provide one-time passwords (OTPs) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet may be configured to respond to one or more requests, such as a near-field data exchange request, from a reader, such as a mobile NFC reader (e.g., on a mobile device or POS terminal), and generate an NDEF message including the cryptographically secure OTP encoded as an NDEF text tag.

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

[0054] In some examples, the one or more applets 103 may be configured to emulate an RFID tag. The RFID tag may include one or more polymorphic tags. In some examples, each time the tag is read, different encrypted 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 a server in a banking system, where the data may be verified.

[0055] In some examples, contactless card 101 and server 120 may contain specific data such that the card can be properly identified. Contactless card 101 may include one or more unique identifiers (not shown). Counter 104 may be configured to increment each time a read operation is performed. In some examples, each time data from contactless card 101 is read (e.g., by computing device 110), counter 104 is sent to the server for verification to determine whether counter 104 is equal to the server's counter 104 (as part of the verification).

[0056] One or more counters 104 may be configured to 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 otherwise passed on. The counter 104 may be replayed if it is not being used. In some examples, the counter incremented on the card is different from the counter incremented for a transaction. Because there is no communication between applets 103 on the contactless card 101, the contactless card 101 cannot determine the counter 104 for an application transaction. 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 for authenticating calls as disclosed herein. Each applet 103-1 and 103-2 may include a respective counter 104.

[0057] In some examples, counter 104 may be out of sync. In some examples, counter 104 may increment to account for accidental reads that initiate transactions, such as reads at an angle, but the application does not process counter 104. In some examples, when device 110 wakes up, NFC is enabled, and device 110 may be configured to read available tags, but no action is taken in response to the read.

[0058] To keep the counter 104 synchronized, an application, such as a background application, may be run. The application may be configured to detect when the device 110 wakes up, synchronize with a banking system's server indicating the reading that occurred, and then advance the counter 104. 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 be configured to advance. However, if within a different threshold number, such as 10 or 1000, a request to perform a re-synchronization may be processed. This request may require the user, via one or more applications, to tap, gesture, or otherwise indicate one or more times via the user's device. If the counter 104 increments in the proper order, it may be known that the user has done so.

[0059] The key diversification techniques described herein with reference to counter 104, master keys, and diversification keys are one example of an encryption and / or decryption key diversification technique, and this exemplary key diversification technique should not be considered limiting of this disclosure, as this disclosure is equally applicable to other types of key diversification techniques.

[0060] During the contactless card 101 generation process, two cryptographic keys may be uniquely assigned to each card. The cryptographic 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 implemented by the contactless card 101 hardware. Using a key diversification process, one or more keys may be derived from a master key based on uniquely identifiable information for each entity needing a key.

[0061] In some examples, to overcome deficiencies in the 3DES algorithm, which is susceptible to vulnerabilities, a session key (e.g., a unique key per session) may be derived, but rather than using a master key, a unique card-derived key and a counter may be used as diversification data. For example, each time the contactless card 101 is used during an implementation, a different key may be used to generate a message authentication code (MAC) and perform encryption. This results in triple encryption. The session key may be generated by one or more applets and derived by using an application transaction counter in one or more algorithms (as defined in EMV 3.3 Book 2 A1.3.1 Common Session Key Derivation).

[0062] Additionally, the increment for each card may be unique, assigned by personalization, or algorithmically assigned by some identifying information. For example, odd-numbered cards may increment by 2, and even-numbered cards may increment by 5. In some examples, the increment may also vary over successive reads, such that one card repeatedly increments by 1, 3, 5, 2, 2, .... The specific sequence or algorithmic sequence may be defined at the time of personalization or from one or more processes derived from the unique identifier. This may make it difficult for a replay attacker to generalize from a small sample of cards.

[0063] The authentication message may be carried as the contents of a text NDEF record in hexadecimal ASCII format. Alternatively, the NDEF record may be encoded in hexadecimal format.

[0064] FIG. 4 illustrates a data structure 400 for an NDEF short record layout (SR=1) according to an example embodiment. One or more applets may be configured to encode the OTP as a text tag of an NDEF type 4 well-known type. In some examples, an NDEF message may consist of one or more records. An applet may be configured to add one or more static tag records in addition to the OTP record. Example tags include, but are not limited to: tag type: well-known type, text, English encoding (en); applet ID: D2760000850104; function: read-only access; encoding: authentication message 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, an authentication template may include a first record with a well-known index to provide the actual dynamic authentication data. In various embodiments, the payload of the data structure 400 may store a cryptogram (e.g., an encrypted customer ID 107) and any other associated data, such as an unencrypted customer ID 107 that uniquely identifies the card 101 and / or the account associated with the card 101, and / or some other unencrypted value.

[0065] The operation of the disclosed embodiments is further described with reference to the following figures. Some of the figures may include logic flows. While such diagrams presented herein may include specific logic flows, it is understood that the logic flows merely provide one example of how the general functionality as described herein may be implemented. Furthermore, a given logic flow does not necessarily have to be performed in the order presented, unless specifically indicated. Furthermore, not all operations illustrated in a logic flow may be required in other embodiments. 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 context.

[0066] 5 illustrates one embodiment of a logic flow 500. The logic flow 500 may be representative of some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 500 may include some or all of the operations of activating the contactless card 101 using the web browser 115. The embodiments are not limited in this context.

[0067] In block 505, contactless card 101 is tapped against computing device 110, such as a smartphone. In block 510, applet 103 executing on contactless card 101 generates (or selects) URL 108 directed to a resource, such as server 120 and / or its components. In block 515, computing device 110 receives URL 108 from contactless card 101, e.g., via NFC. In block 520, OS 112 of computing device 110 launches web browser 115 and provides URL 108 to web browser 115. In doing so, web browser 115 may request the resource located at URL 108 from web server 127 of server 120, e.g., via an HTTP request. In block 525, web browser 115 receives web page 134 from web server 127 based on the request for the resource at URL 108. The web browser 115 may display, load, or otherwise process the received web page 134 and display the web page 134 on a display device. The web page 134 generally includes instructions that enable the web page 134 to control the communication interface 118 of the device 110, which may enable the web page 134 and / or the web browser 115 to control or otherwise participate in NFC communications with the contactless card 101.

[0068] In block 530, web page 134 outputs instructions to tap contactless card 101 against computing device 110. In response, the user may tap contactless card 101 against computing device 110 (e.g., a second tapping instance). Upon detecting that contactless card 101 has come within communication range of device 110, web page 134 may instruct applet 103 to generate a data package (e.g., an NDEF file) including the encryption and the unencrypted customer ID 107 (or any other unique identifier). In block 535, web page 134 and / or web browser 115 may read the data package (e.g., the NDEF file) generated by contactless card 101 by controlling communication interface 118. In some embodiments, web page 134 may process the data package, e.g., format, extract values, modify the package, and include an indication that the data package is part of a request to activate card 101. At block 540, the web page 134 and / or the web browser 115 may transmit the received data package to the server 120 and / or any components thereof.

[0069] In block 545, server 120 attempts to decrypt or verify the encryption in the received data package. If the decryption and / or verification is not successful, server 120 may deny the request to activate contactless card 101. Otherwise, the server may approve the request to activate contactless card 101 based on the successful decryption and / or verification of the encryption. In block 550, server 120 activates contactless card 101 based on the decryption and / or verification. For example, server 120 may update account data 124 to reflect the activation of contactless card 101, thereby enabling contactless card 101 to be used to process payments and / or perform other functions that require contactless card 101 to be in an activated (or payment-enabled) state.

[0070] In block 555, server 120 may send a response to web browser 115 including the decryption results of the successful decryption and indicating that contactless card 101 has been activated. In block 560, server 120 receives a request to process a payment using the activated contactless card 101. In block 565, server 120 (e.g., authentication application 123) may approve the request received in block 560 based at least in part on the activation of contactless card 101 in block 550.

[0071] 6 illustrates one embodiment of a logic flow 600. The logic flow 600 may be representative of some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 600 may include some or all of the operations for activating the contactless card 101 using the web browser 115. More specifically, the logic flow 600 may include some or all of the operations performed by the system 100 for activating the contactless card 101 using the web browser 115. The embodiments are not limited in this context.

[0072] As shown, in block 605, the applet 103 of the contactless card 101 may increment the counter 104 in response to instructions from the web page 134 to generate a cipher to activate the card 101. The web page 134 may provide the instructions to the card 101 by controlling the communication interface 118 of the device 110. In block 610, the applet 103 encrypts the master key 105 and the incremented counter value 104 using an encryption function. Doing so may result in a diversified key 106. In block 615, the applet 103 encrypts some data (e.g., a customer ID 107 or other unique identifier) ​​using the diversified key 106 to generate the cipher. In block 620, the applet 103 generates a data package (e.g., an NDEF file) that includes the cipher generated in block 615 and the unencrypted identifier (e.g., the unencrypted customer ID 107). In block 625, the device 110 receives the data package generated in block 620. Generally, the web page 134 may instruct the communication interface 118 to read the data package from the contactless card 101.

[0073] At block 630, the device 110 may send the data package to the server 120. At block 635, the server 120 and / or any component thereof may determine the unencrypted customer ID 107 in the data package. Doing so, the server 120 may identify the master key 105 and / or counter value 104 for the card 101 in the account data 124 at block 640. At block 645, the server 120 may increment the counter value 104 identified at block 640. At block 650, the server 120 may encrypt the master key 105 identified at block 640 and the counter value 104 incremented at block 645 with an encryption function to generate an instance of the diversified key 106. At block 655, the server 120 may decrypt the encryption using the diversified key 106. The server 120 may verify the encryption based on the decryption and / or one or more further operations. For example, server 120 may compare the result of the decryption in block 655 with the stored customer ID 107 in account data 124. Server 120 may verify the encryption if the comparison results in a match. In such an example, server 120 may activate contactless card 101, for example, by updating the record in account data 124 to reflect the activation. Otherwise, server 120 may refrain from activating contactless card 101 and leave contactless card 101 in a payment-disabled state.

[0074] 7 illustrates one embodiment of a logic flow 700. The logic flow 700 may be representative of some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 700 may include some or all of the operations of activating a contactless card 101 using a web browser 115. The embodiments are not limited in this context.

[0075] As shown, in block 705, server 120 and / or any component thereof receives a request to access card activation web page 134 from web browser 115 of device 110. In block 710, server 120 transmits activation web page 134-1 to the requesting web browser 115. In block 715, server 120 receives a data package generated by contactless card 101. The data package may be read from contactless card 101 by web browser 115 controlling the NFC functionality of communication interface 118. The data package may include a cipher and an unencrypted customer identifier. In block 720, server 120 determines that contactless card 101 is in a payment-disabled state, for example, based on account data 124.

[0076] At block 730, the server 120 identifies the master key 105 and / or counter value 104 for the card 101 in the account data 124 based on the unencrypted customer identifier in the data package received at block 715. At block 735, the server 120 may increment the counter value 104 identified at block 730. At block 740, the server 120 may encrypt the master key 105 identified at block 730 and the counter value 104 incremented at block 735 with a cryptographic function to generate an instance of a diversified key 106. At block 745, the server 120 may decrypt and / or otherwise verify the diversified key 106 generated at block 740. At block 750, the server 120 activates the contactless card 101 by updating the record in the account data 124 to reflect that the contactless card 101 has transitioned from a disabled payment state to a enabled payment state.

[0077] At block 755, server 120 may send an indication to web page 134-1 in web browser 115 reflecting successful decryption and / or verification and that contactless card 101 has transitioned to a payment-enabled state. At block 760, server 120 receives a request to perform an action using contactless card 101. For example, web browser 115 may generate a request to process a purchase using contactless card 101. At block 765, server 120 may approve the request based at least in part on the activation of the contactless card at block 750.

[0078] 8 illustrates one embodiment of an exemplary computer architecture 800 including a computing system 802 that may be suitable for implementing various embodiments as described above. In one embodiment, the computer architecture 800 may include or be implemented as part of the computing system 100. In some embodiments, the computing system 802 may represent, for example, the contactless card 101, the computing device 110, and the server 120 of the system 100. The embodiments are not limited in this context. More generally, the computing architecture 800 is configured to implement all of the logic, applications, systems, methods, apparatus, and functionality described herein with reference to FIGS. 1A-7.

[0079] As used herein, the terms "system" and "component" are intended to refer to computer-related entities, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by exemplary computing computer architecture 800. 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 (optical and / or magnetic storage media), an object, an executable, 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 components may be localized on one computer and / or distributed among two or more computers. Furthermore, components may be communicatively coupled to each other by various types of communication media to coordinate operations. This coordination may involve unidirectional or bidirectional exchange of information. For example, components may convey information in the form of signals communicated over the communication media. Information may be implemented as signals assigned to various signal lines. In such assignments, each message is a signal. However, further embodiments may employ data messages instead. Such data messages may be transmitted over a variety of connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0080] Computing architecture 800 may include various common computing 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 computing architecture 800.

[0081] 8, computing architecture 800 includes a processor 804, a system memory 806, and a system bus 808. Processor 804 may be any of various commercially available processors.

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

[0083] Computing architecture 800 may include or be implemented in various articles of manufacture. The articles of manufacture may include a computer-readable storage medium for storing logic. Examples of computer-readable storage media may include any tangible medium capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, etc. 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, etc. Embodiments may also be implemented, at least in part, as instructions contained in or residing 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.

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

[0085] Computer 802 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 830, a magnetic disk drive 816 for reading from or writing to a removable magnetic disk 820, and an optical disk drive 828 for reading from or writing to a removable optical disk 832 (e.g., a CD-ROM or DVD). The hard disk drive 830, magnetic disk drive 816, and optical disk drive 828 can be connected to system bus 808 by an HDD interface 814, a FDD interface 818, and an optical disk drive interface 834, respectively. The HDD interface 814 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

[0086] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-executable instructions, etc. A number of program modules can be stored in the drives and nonvolatile memory 810 and volatile memory 812, including, for example, an operating system 822, one or more applications 842, other program modules 824, and program data 826. In one embodiment, the one or more applications 842, other program modules 824, and program data 826 may include various applications and / or components of system 100, such as, for example, applets 103, counters 104, master keys 105, diversified keys 106, customer IDs 107, URLs 108, web browsers 115, data packages 117, encryption, authentication applications 123, account data 124, web servers 127, and web pages 134.

[0087] A user can enter commands and information into the computer 802 through one or more wired / wireless input devices, such as a keyboard 850 and a pointing device such as a mouse 852. Other input devices may include a microphone, an infrared (IR) remote control, a radio frequency (RF) remote control, a game pad, a stylus pen, a card reader, a dongle, a fingerprint reader, gloves, a graphics tablet, a joystick, a keyboard, a retina reader, a touch screen (e.g., capacitive, resistive, etc.), a trackball, a track pad, a sensor, a stylus, etc. These and other input devices are often connected to the processor 804 through an input device interface 836 coupled to the system bus 808, but may 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.

[0088] A monitor 844 or other type of display device is also connected to the system bus 808 via an interface, such as a video adapter 846. The monitor 844 may be internal or external to the computer 802. In addition to the monitor 844, computers typically include other peripheral output devices, such as speakers, printers, etc.

[0089] The computer 802 may operate in a networked environment using wired and / or wireless communication logical connections to one or more remote computers, such as a remote computer 848. The remote computer 848 may be a workstation, a server computer, a router, a personal computer, a portable computer, a microprocessor-based entertainment appliance, a peer device, or other common network node, and typically includes many or all of the elements described relative to the computer 802, although for purposes of simplicity, only a memory and / or storage device 858 is illustrated. The logical connections shown include wired and / or wireless connections to a local area network 856 and / or larger networks, e.g., a wide area network 854. Such LAN and WAN networking environments are commonplace in offices and businesses and facilitate enterprise-wide computer networks, such as intranets, all of which may connect to a global communications network, e.g., the Internet.

[0090] When used in a local area network 856 networking environment, the computer 802 is connected to the local area network 856 through a wired and / or wireless communication network interface or adapter 838. The network adapter 838 can facilitate wired and / or wireless communication to the local area network 856 and may also include a wireless access point disposed thereon for communicating with the wireless capabilities of the network adapter 838.

[0091] When used in a wide area network 854 networking environment, the computer 802 may include a modem 840, or be connected to a communications server on the wide area network 854, or have other means for establishing communications over the wide area network 854, for example, via the Internet. The modem 840, which may be an internal or external device and a wired and / or wireless device, connects to the system bus 808 via the input device interface 836. In a networked environment, program modules depicted relative to the computer 802, or portions thereof, may be stored in the remote memory and / or storage device 858. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between computers may be used.

[0092] The computer 802 can communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively arranged in wireless communications (e.g., IEEE 802.11 wireless modulation technology). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth® wireless technologies. Thus, communications may be in a predefined structure, such as a traditional network, or simply ad hoc communications between at least two devices. A Wi-Fi network uses a radio technology called IEEE 802.11 (a, b, g, n, etc.) and provides secure, reliable, and fast wireless connections. A Wi-Fi network can be used to connect computers to each other, to the Internet, and to wired networks (which use IEEE 802.3-related media and functions).

[0093] As described above with reference to FIGS. 1A - 8, the various elements of the device may include various hardware elements, software elements, or a combination of both. Examples of hardware elements can be devices, logic devices, components, processors, microprocessors, circuits, processors, circuit elements (such as transistors, resistors, capacitors, inductors, etc.), integrated circuits, application - specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field - programmable gate arrays (FPGAs), memory units, logic gates, registers, semiconductor devices, chips, microchips, chip sets, etc. Examples of software elements include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, sub - routines, functions, methods, procedures, software interfaces, application program interfaces (APIs), instruction sets, operation codes, computer codes, code segments, computer code segments, words, values, symbols, or any combination thereof. However, determining whether an embodiment is implemented using hardware elements and / or software elements can vary according to any number of factors such as the desired computing speed, power level, thermal tolerance, processing cycle budget, input data speed, output data speed, memory resources, data bus speed, and other design or performance constraints for a given implementation.

[0094] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium representing various logic within a processor. The instructions, when read by a machine, cause the machine to generate logic for performing 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 for loading into manufacturing machines that create the logic or processors. Some embodiments may be implemented using, for example, a machine-readable medium or article that may store 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 a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and may be implemented using any suitable combination of hardware and / or software. The machine-readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium, and / or storage unit, such as memory, removable or non-removable media, erasable or non-erasable media, writable or rewritable media, digital or analog media, hard disk, floppy disk, compact disk read-only memory (CD-ROM), compact disk recordable (CD-R), compact disk rewriteable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various types of digital versatile disks (DVDs), tape, cassette, etc. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc., implemented using any suitable high-level programming language, low-level programming language, object-oriented programming language, visual programming language, compiled and / or interpreted programming language.

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

Claims

1. a processor; When executed by the processor, the processor: receiving a network address for the resource from a payment-disabled contactless card via a wireless card reader; accessing the resource at the network address received from the contactless card via the card reader using a web browser; activating the card reader with the resource of the web browser to receive a cryptogram from the contactless card; causing the resource of the web browser to transmit the encryption to a server; causing the resource of the web browser to receive from the server a response identifying that the contactless card has transitioned from the payment disabled state to a payment enabled state. a memory containing instructions; An apparatus comprising:

2. The memory, when executed by the processor, causes the processor to: causing the resource of the web browser to receive a decryption result from the server; The resource of the web browser determines that the server has decrypted the encryption. The apparatus of claim 1 comprising instructions.

3. The memory, when executed by the processor, causes the processor to: and upon receiving the network address, launching the web browser to access the resource by an operating system executing on the processor; causing the resource of the web browser to display the response identifying that the contactless card has transitioned from the payment disabled state to the payment enabled state. The apparatus of claim 1 comprising instructions.

4. The device of claim 1 , wherein the network address comprises a uniform resource locator (URL) generated by the contactless card.

5. The device of claim 1 , wherein the card reader receives the network address for the resource from the contactless card using near field communication (NFC).

6. 2. The device of claim 1, wherein the card reader action includes instructing an applet running on the contactless card to generate the network address and the encryption code.

7. The memory, when executed by the processor, causes the processor to: receiving, by the resource of the web browser, an unencrypted customer identifier along with the encryption; causing the resource of the web browser to transmit the unencrypted customer identifier along with the encryption to the server. The apparatus of claim 1 comprising instructions.

8. A non-transitory computer-readable medium containing a set of instructions, The set of instructions, when executed by a processor circuit, causes the processor circuit to: receiving a network address for the resource from a payment-disabled contactless card via a wireless card reader; accessing the resource at the network address received from the contactless card via the card reader using a web browser; activating the card reader with the resource of the web browser to receive a cryptogram from the contactless card; causing the resource of the web browser to transmit the encryption to a server; causing the resource of the web browser to receive from the server a response identifying that the contactless card has transitioned from the payment disabled state to a payment enabled state; Non-transitory computer-readable medium.

9. When executed by the processor circuit, the processor circuit: causing the resource of the web browser to receive a decryption result from the server; The resource of the web browser determines that the server has decrypted the encryption. The non-transitory computer-readable medium of claim 8 comprising instructions.

10. When executed by the processor circuit, the processor circuit: and upon receiving the network address, launching the web browser to access the resource by an operating system executing on the processor circuit; causing the resource of the web browser to display the response identifying that the contactless card has transitioned from the payment disabled state to the payment enabled state. The non-transitory computer-readable medium of claim 8 comprising instructions.

11. The non-transitory computer-readable medium of claim 8 , wherein the network address comprises a uniform resource locator (URL) generated by the contactless card.

12. 9. The non-transitory computer-readable medium of claim 8, wherein the card reader receives the network address for the resource from the contactless card using near field communication (NFC), and the operation of the card reader includes instructing an applet running on the contactless card to generate the network address and the encryption.

13. When executed by the processor circuit, the processor circuit: receiving, by the resource of the web browser, an unencrypted customer identifier along with the encryption; causing the resource of the web browser to transmit the unencrypted customer identifier along with the encryption to the server. The non-transitory computer-readable medium of claim 8 comprising instructions.

14. receiving, by a computing device, a network address for a resource from a payment-disabled contactless card via a wireless card reader of said computing device; accessing the resource at the network address received from the contactless card via the card reader in a web browser running on the computing device; operating the card reader with the resource of the web browser to receive a cryptogram from the contactless card; transmitting the encryption key to a server by the resource of the web browser; receiving, by the resource of the web browser, a response from the server identifying that the contactless card has transitioned from the payment disabled state to a payment enabled state; A method comprising:

15. receiving, by the resource of the web browser, a decryption result from the server; determining, by the resource of the web browser, that the server has decrypted the encryption; 15. The method of claim 14.

16. launching, by the device's operating system, the web browser to access the resource upon receiving the network address; and displaying, by the resource of the web browser, the response identifying that the contactless card has transitioned from the payment disabled state to the payment enabled state.

15. The method of claim 14.

17. The method of claim 14 , wherein the network address comprises a uniform resource locator (URL) generated by the contactless card.

18. 15. The method of claim 14, wherein the card reader receives the network address for the resource from the contactless card using near field communication (NFC), and the card reader action includes instructing an applet running on the contactless card to generate the network address and the encryption.

19. receiving, by the resource of the web browser, an unencrypted customer identifier along with the encryption; transmitting, by the resource of the web browser, the unencrypted customer identifier together with the encryption to the server; 15. The method of claim 14.

20. identifying, by the server, an encryption key and a counter value associated with the contactless card based on the unencrypted customer identifier; incrementing, by the server, an identified counter value associated with the contactless card; encrypting, by the server, the incremented counter value and the encryption key to generate a diversified key associated with the contactless card; decrypting the encryption by the server using the diversified key; storing, by the server, an indication that the contactless card has been activated based on the decryption; receiving, by the server, a request to process a payment using the contactless card; and granting, by the server, the request based at least in part on activation of the contactless card.

20. The method of claim 19.

Images