Determining specific conditions for contactless card activation

Abstract

A system, method, product, and computer-readable medium for determining specific conditions for activating a contactless card. An application running on a server can receive a request from a device specifying a uniform resource locator containing encrypted data, the encrypted data based at least in part on a private key assigned to the contactless card. The application can decrypt the encrypted data and determine the type of the contactless card. The application can determine a plurality of conditions associated with the type of contactless card and send the conditions to a web browser on the device. The application can receive instructions from the web browser specifying acceptance of the plurality of conditions. The application can store instructions in a database specifying that the contactless card has been activated for use based on the decryption of the encrypted data and the received instructions specifying acceptance of the conditions.

Description

[Technical Field]

[0001] Related Applications This application claims priority to U.S. utility application Ser. No. 16 / 847,268, entitled "Determining Specific Conditions for Contactless Card Activation," filed April 13, 2020. The contents of the aforementioned application are incorporated herein by reference in their entirety.

[0002] Technical Field FIELD Embodiments herein relate generally to computing platforms, and more particularly to computing platforms for determining specific conditions for contactless card activation. [Background technology]

[0003] Payment cards may be mailed to customers in an inactive state, preventing them from being used for purchases or other transactions before activation. The card activation process carries significant security risks. Additionally, activation of certain types of cards may impose various requirements. While some solutions have attempted to move the activation process to online platforms, these solutions do not offer the flexibility and security needed to accommodate the ever-increasing number of card types. Summary of the Invention

[0004]

[0003] Embodiments disclosed herein provide systems, methods, products, and computer-readable media for determining specific conditions for activating a contactless card. In one example, an application executing on a server may receive a request from a device specifying a uniform resource locator including encrypted data based at least in part on a private key assigned to the contactless card. The application may decrypt the encrypted data and determine the type of the contactless card. The application may determine a plurality of conditions associated with the type of contactless card and send the conditions to a web browser on the device. The application may receive instructions from the web browser specifying acceptance of the plurality of conditions. The application may store instructions in a database specifying that the contactless card has been activated for use based on the received instructions specifying decryption of the encrypted data and acceptance of the conditions. [Brief explanation of the drawings]

[0005] [Figure 1A] 1 illustrates an embodiment of a system for determining specific conditions for contactless card activation. [Figure 1B] 1 illustrates an embodiment of a system for determining specific conditions for contactless card activation. [Figure 1C] 1 illustrates an embodiment of a system for determining specific conditions for contactless card activation. [Figure 2A] 1 illustrates an embodiment of a system for determining specific conditions for contactless card activation. [Figure 2B] 1 illustrates an embodiment of a system for determining specific conditions for contactless card activation. [Figure 2C] 1 illustrates an embodiment of a system for determining specific conditions for contactless card activation. [Figure 3A] 1 illustrates an embodiment for determining specific conditions for contactless card activation. [Figure 3B]1 illustrates an embodiment for determining specific conditions for contactless card activation. [Figure 3C] 1 illustrates an embodiment for determining specific conditions for contactless card activation. [Figure 3D] 1 illustrates an embodiment for determining specific conditions for contactless card activation. [Figure 4A] 1 illustrates an embodiment for determining specific conditions for contactless card activation. [Figure 4B] 1 illustrates an embodiment for determining specific conditions for contactless card activation. [Figure 4C] 1 illustrates an embodiment for determining specific conditions for contactless card activation. [Figure 4D] 1 illustrates an embodiment for determining specific conditions for contactless card activation. [Figure 5A] An example of a contactless card is shown. [Figure 5B] An example of a contactless card is shown. [Figure 6] 1 illustrates one embodiment of a first logic flow. [Figure 7] 10 illustrates one embodiment of a second logic flow. [Figure 8] 10 illustrates one embodiment of a third logic flow. [Figure 9] 10 illustrates one embodiment of a fourth logic flow. [Figure 10] 1 illustrates an embodiment of a computing system. DETAILED DESCRIPTION OF THE INVENTION

[0006] Embodiments disclosed herein provide techniques for securely activating contactless cards through the disclosure of card-specific and / or customer-specific terms. Typically, a user receives a contactless card in an inactive state and must activate it before it can be used. In some embodiments, a user may tap the contactless card to a computing device, such as a smartphone, to initiate the activation process. Upon tapping the contactless card to the smartphone (or bringing the contactless card within wireless data range of the smartphone), the contactless card may generate encrypted data. The encrypted data may be transmitted to the smartphone.

[0007] In some embodiments, the encrypted data generated by the contactless card may be part of a uniform resource locator (URL) directed to a server. Upon receipt, the smartphone's operating system (OS) may cause a web browser to access the URL. Upon access, the server may receive the encrypted data, decrypt the encrypted data, and verify the authenticity of the contactless card. The server may then determine the type of contactless card and determine a number of terms and conditions associated with the card. The terms and conditions may be transmitted to the smartphone's web browser, where the user may accept and / or reject the terms. Upon user acceptance, an indication of acceptance is transmitted to the server, which may activate the contactless card, for example, by storing an indication in a database that the contactless card is active. The user may then use the contactless card for any desired payment transactions.

[0008] Advantageously, the embodiments disclosed herein improve the security of all devices and associated data. For example, contactless card security is improved by requiring verification of encrypted data generated by the contactless card to activate the card. As another example, user privacy and compliance with applicable laws and regulations are improved by presenting terms and conditions specific to the type of contactless card and / or other user attributes. Furthermore, doing so eliminates the need for card issuers to mail terms and conditions in paper format, thereby saving resources.

[0009] With general reference 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 herein, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. These operations are operations requiring 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 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. 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.

[0010] Further, these operations are often referred to in terms, such as adding or comparing, that 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, for any of the operations described herein that form part of one or more 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 and written in accordance with the teachings herein, and / or include specially constructed apparatus or digital computers 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 these various machines will be apparent from the description given.

[0011] Reference is now made to the drawings. 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 thereof. However, it may 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 description thereof. The intention is to cover all modifications, equivalents, and alternatives within the scope of the claims.

[0012] FIG. 1A illustrates a schematic diagram of an exemplary system 100 consistent with disclosed embodiments. As shown, the system 100 includes one or more contactless cards 101, one or more mobile computing devices 110, and an authentication server 120. The contactless cards 101 represent any type of payment card, such as a credit card, a debit card, an ATM card, or a gift card. The contactless cards 101 may include one or more communication interfaces 109, such as a radio frequency identification (RFID) chip, configured to communicate with the computing devices 110 via NFC, EMV standards, or other short-range protocols for wireless communication. While NFC is used as an exemplary communication protocol, the present disclosure is equally applicable to other types of communication, such as EMV standards, Bluetooth, and / or Wi-Fi. The mobile devices 110 represent any type of network-enabled computing device, such as a smartphone, a tablet computer, a wearable device, a laptop, a portable gaming device, or the like. The authentication server 120 represents any type of computing device, such as a server, a workstation, a computing cluster, a cloud computing platform, a virtualized computing system, or the like.

[0013] As shown, contactless card memory 102 includes applet 103, counter 104, private key 105, diversified key 106, and unique customer identifier (ID) 107. Applet 103 is executable code configured to perform the operations described herein. Counter 104, private key 105, diversified key 106, and customer ID 107 are used to provide security in system 100, as described in more detail below.

[0014] As shown, the memory 111 of the mobile device 110 includes an instance of an operating system (OS) 112. Exemplary operating systems 112 include Android® OS, iOS®, macOS®, Linux®, and Windows® operating systems. As shown, the OS 112 includes an account application 113. The account application 113 enables a user to perform various account-related operations, such as activating one or more contactless cards 101, viewing an account balance, purchasing items, and processing payments. The account application 113 may further control access permissions to different features provided by the account application 113. In some embodiments, a user may authenticate using authentication credentials to access certain features of the account application 113. For example, the authentication credentials may include a username (or login) and password, biometric credentials (e.g., fingerprint, Face ID, etc.), etc.

[0015] As mentioned, contactless card 101 may need to be activated before it can be used to provide payment data for a transaction. To activate contactless card 101, a user may tap contactless card 101 to device 110. 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 encrypted data as part of the authentication process required to activate contactless card 101. For example, in some embodiments, applet 103 may generate URL 108 containing encrypted data as part of the authentication process required to activate contactless card 101. To enable NFC data transfer between contactless card 101 and mobile device 110, account application 113 may communicate with contactless card 101 when contactless card 101 is sufficiently close to communication interface 118 of mobile device 110. The communication interface 118 may be configured to read from and / or communicate with the communication interface 109 of the contactless card 101 (e.g., via NFC, Bluetooth, RFID, etc.). Thus, exemplary communication interfaces 118 include an NFC communication module, a Bluetooth communication module, and / or an RFID communication module.

[0016] As mentioned, system 100 is configured to implement key diversification to protect data, which may be referred to herein as key diversification techniques. Generally, server 120 (or other computing device) and contactless card 101 may be provided with the same private key 105 (also referred to as a master key or master symmetric key). More specifically, each contactless card 101 is programmed with a unique private key 105 that has a corresponding pair within (or managed by) server 120. For example, when contactless card 101 is manufactured, the unique private key 105 may be stored in memory 102 of contactless card 101. Similarly, the unique private key 105 may be stored in a customer record (or profile) associated with contactless card 101 within account data 124 of server 120 (and / or in another secure location, such as hardware security module (HSM) 125). The private key 105 may be kept secret from all parties other than contactless card 101 and server 120, thereby enhancing the security of system 100. In some embodiments, applet 103 of contactless card 101 may encrypt and / or decrypt data (e.g., customer ID 107) using an encryption algorithm that takes private key 105 and data as input; for example, encrypting customer ID 107 with private key 105 may result in an encrypted customer ID. Similarly, authentication server 120 may encrypt and / or decrypt data associated with contactless card 101 using the corresponding private key 105.

[0017] In some embodiments, counter 104 and / or private key 105 of contactless card 101 and server 120 may be used in conjunction with counter 104 to enhance security using key diversification. Counter 104 comprises a value that is synchronized between a given contactless card 101 and server 120. Counter value 104 may comprise a number that changes each time data is exchanged between contactless card 101 and server 120 (and / or contactless card 101 and mobile device 110). When preparing to send data (e.g., to server 120 and / or mobile device 110), applet 103 of contactless card 101 may increment counter value 104. Contactless card 101 may then provide private key 105 and counter value 104 as input to an encryption algorithm, which generates diversified key 106 as 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 AES128, symmetric HMAC algorithms such as HMAC-SHA-256, and symmetric CMAC algorithms such as AES-CMAC. Examples of key diversification techniques are described in 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. The applet 103 of the contactless card 101 may include an encrypted payload as a parameter of a URL 108 that contains the encrypted data.

[0018] Continuing with the example of key diversification, the contactless card 101 may encrypt data (e.g., customer ID 107 and / or any other data) using the diversified key 106 and the data as input to an encryption algorithm. For example, encrypting the customer ID 107 with the diversified key 106 may result in an encrypted customer ID. In some embodiments, the encrypted data generated by the contactless card 101 may include a URL. The URL may be directed to the authentication server 120 or some other URL associated with the entity issuing the contactless card 101. In other embodiments, the URL may further be a universal link URL that opens a local resource (e.g., a specific page of the account application 113, such as a card activation page). The URL may further include data (e.g., parameters) used by the authentication server 120 to validate the data generated by the contactless card 101.

[0019] For example, if the URL to authentication server 120 (and / or the URL to account application 113) is "http: / / www.example.com / accountapp" and the encrypted data generated based on the aforementioned encryption operation is "ABC123," URL 108 containing the encrypted data may be "http: / / www.example.com / accountapp?data=ABC123." In some embodiments, applet 103 may encode the encrypted data according to a URL-compatible encoding format before including it as a parameter in URL 108. For example, the encrypted data may be a string of binary data (e.g., 0s and 1s), which may not be URL-compatible. Therefore, applet 103 may encode the encrypted data into the American Standard Code for Information Interchange (ASCII) Base 64 encoding format. In doing so, it represents the binary encrypted data in ASCII string format by converting it into a Base 64 representation (e.g., "ABC123" in the previous example). Additionally, in embodiments where the URL is directed to a local resource, such as account application 113, URL 108 may include an indication of which page of account application 113 to open. Continuing with the previous example, a page identifier of "1" (or other page identifier, such as a page name) may be added as a parameter to the URL, and URL 108 containing the encrypted data may be "http: / / www.example.com / accountapp?data=ABC123&p=1".

[0020] Once generated, applet 103 may transmit URL 108 containing the encrypted data to mobile device 110, for example, via NFC. In one embodiment, once received by OS 112, OS 112 causes web browser 115 to access URL 108 containing the encrypted data. In doing so, information describing mobile device 110 is transmitted along with the request to access URL 108 containing the encrypted data. For example, the information may include attributes of mobile device 110, such as operating system version, hardware capabilities, and software capabilities.

[0021] In the embodiment shown in FIG. 1A, URL 108 containing encrypted data is directed to server 120, which may include a Hypertext Transfer Protocol (HTTP) server. In one embodiment, authentication application 123 provides the HTTP server and / or related functionality. Thus, web browser 115 accessing URL 108 containing encrypted data causes server 120 to receive URL 108 containing encrypted data, for example, in an HTTP request. Authentication application 123 may receive URL 108 containing encrypted data and extract the encrypted data, which may include an encrypted customer ID (e.g., "ABC123" from the previous example). Authentication application 123 may convert the encrypted data back to its original encoding format (e.g., from ASCII base 64 to binary). Account application 113 may similarly perform conversions, such as, for example, from ASCII base 64 to binary and vice versa.

[0022] The authentication application 123 may then attempt to authenticate the encrypted data. For example, the authentication application 123 may attempt to decrypt the encrypted data using a copy of the private key 105 stored by the server 120. In another example, the authentication application 123 may provide the private key 105 and the counter value 104 as inputs to an encryption algorithm, which generates the diversified key 106 as an output. The resulting diversified key 106 may correspond to the diversified key 106 of the contactless card 101, which may be used to decrypt the encrypted customer ID 107. Thus, the authentication application 123 may successfully decrypt the encrypted data, thereby verifying the encrypted data. For example, as mentioned, the customer ID 107 may be used to generate the encrypted data included in the URL 108 that contains the encrypted data. In such an example, the authentication application 123 may decrypt the encrypted data using the private key 105 of the authentication server 120. If the decryption results in a customer ID 107 associated with an account in account data 124, authentication application 123 verifies the encrypted data. If authentication application 123 is unable to decrypt the encrypted data to the expected result (e.g., customer ID 107 for the account associated with contactless card 101), authentication application 123 does not verify (or validate or authenticate) the encrypted data. Due to a failed verification, authentication application 123 may return an error to web browser 115 and / or reject the attempted activation of contactless card 101.

[0023] Regardless of the decryption technique used, the authentication application 123 may successfully decrypt the encrypted customer ID 107, thereby verifying the encrypted customer ID 107 (e.g., by comparing the obtained customer ID 107 to the 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 as 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 encrypted customer ID 107. Similarly, the secure element and / or HSM 125 may generate the diversified key 106 based on the private key 105 and the counter value 104, as described above.

[0024] If the authentication application 123 verifies the encrypted customer ID 107 in the URL 108 containing the encrypted data, the authentication application 123 may return corresponding verification instructions to the web browser 115. The authentication application 123 may then determine the type of contactless card 101 being activated, for example, based on the type specified in the account data 124 and / or the card data 126. For example, each card may be associated with a unique identifier associated with at least one card type of multiple card types. The authentication application 123 may further receive data describing customer attributes associated with the contactless card 101 being activated, such as the customer's address, date of birth, etc. Using the card type and / or customer attributes, the authentication application 123 may determine multiple conditions 127 from the card data 126 that are applicable to the card type and / or customer data. The conditions 127 may generally include terms, conditions, cardholder agreements, personal information use disclosures, legal disclosures, privacy notices, etc., which may be collectively referred to herein as "conditions." For example, a first card type may have a first plurality of terms and conditions (e.g., interest rates, disclosures, etc.), while a second card type may have a second plurality of terms and conditions that are the same and / or different from the first plurality of terms. Similarly, a customer located in a first state (e.g., based on the customer's address) may be required to receive additional and / or different terms and conditions associated with a customer located in a second state. Thus, based on customer attributes and / or card type, the authentication application 123 dynamically determines the specific set of terms and conditions required to activate the contactless card 101.

[0025] In some embodiments, the authentication application 123 may determine that the contactless card 101 is a replacement for a previously active contactless card. In such embodiments, the user may have previously accepted the custom conditions of the previous card and may determine a reduced set of conditions 128 for activating the contactless card. For example, each contactless card 101 may be associated with an issue date and / or a manufacturing date. The authentication application 123 may determine the dates of the replacement card 101 and the previous card and determine the conditions 127 based on the dates. In one embodiment, the authentication application 123 calculates the difference between the different conditions to determine the reduced set of conditions (also referred to as a subset of conditions). Thus, the authentication application 123 may determine a modified, added, and / or deleted reduced set of conditions based on the date of each card. Doing so enables the authentication application 123 to transmit the reduced set of conditions to the web browser 115 as custom conditions 128. However, the complete set of conditions may be included in the reduced set of conditions. The user may then accept the reduced set of terms and conditions as part of the activation process for the replacement card 101. In some embodiments, the authentication application 123 may change the format of the custom terms and conditions 128 to reflect which terms and conditions have changed for the replacement card. For example, if new disclosures are added to the replacement card's custom terms and conditions 128 that were not present in the original card's terms and conditions 127, the authentication application 123 may highlight, bold, italicize, enlarge the font, or otherwise modify the new disclosures so that the user can easily detect the new terms.

[0026] 1B illustrates an embodiment in which authentication application 123 decrypts the encrypted customer ID, thereby verifying (or authenticating) the encrypted data in the URL with encrypted data 108 and determining a set of custom conditions 128 applicable to activation of contactless card 101. As shown, authentication application 123 sends custom conditions 128 to web browser 115, where custom conditions 128 may further indicate that authentication application 123 successfully decrypted the encrypted customer ID.

[0027] In response to receiving the custom terms 128, the web browser 115 may output an interface displaying the custom terms 128 for activation of the contactless card 101. The user may then read the custom terms 128 and decide to accept the custom terms 128 and activate the contactless card 101. For example, the user may click a checkbox indicating acceptance of the custom terms 128, provide a signature, etc.

[0028] 1C illustrates an embodiment in which a user accepts custom terms 128 via web browser 115. As shown, web browser 115 then sends an indication of acceptance 129 to server 120. Authentication application 123 may then receive acceptance 129 and determine to activate contactless card 101 based on the successful decryption of the encrypted data included in URL 108 containing the encrypted data and the user's acceptance of custom terms 128. In one embodiment, authentication application 123 may store an indication in account data 124 and / or card data 126 in a user profile indicating that contactless card 101 has been activated. In doing so, the customer may provide payment data for a transaction using contactless card 101 and / or provide the card number, expiration date, and / or CVV of contactless card 101 in a virtual interface to provide payment data for a transaction.

[0029] 2A is a schematic diagram 200 illustrating an embodiment in which the account application 113 is used to activate the contactless card 101. As shown, the user taps the contactless card 101 to the mobile device 110 to proceed with activating the card. In some embodiments, the user may provide authentication credentials to access the account associated with the contactless card 101 before tapping the contactless card 101 to the device 110. However, in other embodiments, the user does not need to log in to their account to activate the contactless card 101.

[0030] In response to tapping the contactless card 101, the applet 103 encrypts the customer ID 107, which is transmitted to the account application 113 as at least a portion of the encrypted data 208. Generally, the encrypted customer ID included in the encrypted data 208 is generated by the applet 103 as described above with respect to generating the URL 108 that includes the encrypted data (e.g., by encrypting the customer ID 107 with the private key 105 and / or the diversified key 106, where the diversified key 106 is generated based on the private key 105 and the counter value 104).

[0031] In response to receiving the encrypted customer ID in the encrypted data 208, the account application 113 may transmit the encrypted data 208 to the authentication server 120. Upon receipt, the authentication application 123 may attempt to decrypt the encrypted customer ID 208 using the private key 105 and / or the diversified key 106, as described above. If the attempted decryption yields the customer ID 107 associated with the account, the authentication application 123 may transmit an indication of successful verification to the account application 113. Otherwise, if the attempted decryption of the encrypted customer ID 208 is unsuccessful, the authentication application 123 may transmit an indication of failed decryption to the account application 113, which may deny activation of the contactless card 101. As another example, the authentication application 123 may deny activation of the contactless card 101.

[0032] 2B reflects an embodiment in which the authentication application 123 verifies the encrypted customer ID included in the encrypted data 208. As mentioned, the authentication application 123 may determine the type of card 101, the date of the card 101, or any other attribute of the card 101. The authentication application 123 may further determine one or more attributes of the associated account holder (e.g., name, address, age, etc.). The authentication application 123 may then use the attributes of the card 101 and / or the attributes of the account holder to determine a number of custom conditions 228 for the contactless card 101. The authentication application 123 may then send the custom conditions 228 to the account application 113. The account application 113 may then output the custom conditions 228 for display on the mobile device 110. As mentioned, in some embodiments (e.g., when the contactless card 101 is a replacement card), the conditions 228 may be a reduced set of conditions. In such an embodiment, the authentication application 123 and / or the account application 113 may modify the reduced set of conditions to improve its readability.

[0033] The account application 113 may provide one or more graphical user interface (GUI) elements that allow the user to accept the terms 228. FIG. 2C illustrates an embodiment in which the user has accepted the terms 228. In the illustrated embodiment, the account application 113 sends an indication of acceptance 229 to the authentication application 123. Once the authentication application 123 receives the acceptance 229, the authentication application 123 may activate the contactless card 101 based on the acceptance of the terms and verification of the encrypted customer ID 208. For example, the authentication application 123 may store in the account data 124 and / or the card data 126 an indication that the contactless card 101 has been activated.

[0034] As previously mentioned, the URL may be directed to the account application 113. Thus, in such an embodiment, the encrypted data 208 generated in FIG. 2A may include a URL directed to a card activation page of the account application 113. In such an embodiment, the account application 113 may extract the encrypted customer ID 107 from the URL, optionally decode the encrypted customer ID 107, and transmit the encoded and / or decoded customer ID 107 to the server 120 over the network 130. The authentication application 123 may then decrypt the encrypted customer ID 107 and verify the encrypted data.

[0035] By requiring verification of encrypted data generated by the contactless card 101 to activate the contactless card 101, embodiments disclosed herein improve the security of the contactless card 101. Furthermore, by presenting conditions specific to the type of contactless card and / or specific to user attributes (e.g., country of residence, state of residence, city of residence, age, legal status, etc.), user privacy and compliance with applicable laws and regulations are improved. Furthermore, doing so eliminates the need for card issuers to mail out terms and conditions in paper format, thereby saving resources.

[0036] FIG. 3A is a schematic diagram 300 illustrating an example embodiment of tapping a contactless card 101 to provide secure activation using custom conditions of the contactless card 101. When a user taps the contactless card 101 against a mobile device 110, the applet 103 on the contactless card 101 encrypts the customer ID 107 and generates a URL 108 containing the encrypted data. The applet 103 may then transmit the URL 108 containing the encrypted data to the mobile device 110, for example, via NFC. Upon receipt, the OS 112 may cause the device 110 to access the URL 108 containing the encrypted data. Because there are no applications in the foreground of the device 110 (e.g., the device displays the home screen of the OS 112), the NFC data transfer may be a background NFC read from the perspective of the device 110. The background NFC read may cause the OS 112 to open an application (e.g., a web browser 115 and / or an account application 113).

[0037] In the embodiment shown in FIG. 3A, the URL 108 containing the encrypted data may be directed to the server 120 and / or the authentication application 123. As shown in diagram 310 of FIG. 3B, the OS 112 may launch the web browser 115 and have the web browser 115 access the URL 108 containing the encrypted data. As shown, the web browser 115 provides an indication to the user that the activation process has begun. The authentication application 123 may then attempt to decrypt the encrypted customer ID 107 using the private key 105 and / or the diversified key 106 assigned to the contactless card 101. If the authentication application 123 cannot decrypt the encrypted customer ID 107 to obtain the expected result (e.g., the customer ID 107 of the account), the authentication application 123 does not verify the encrypted customer ID 107. If the authentication application 123 successfully decrypts the encrypted customer ID 107 and obtains the expected result (e.g., the customer ID 107 of the account), the authentication application 123 verifies the encrypted customer ID 107. As shown in FIG. 3B , the authentication application 123 successfully decrypts the encrypted customer ID, and the authentication application 123 sends a verification instruction to the web browser 115. The authentication application 123 may then determine custom conditions for the contactless card 101 based on one or more attributes of the card 101 and / or one or more attributes of the account holder.

[0038] FIG. 3C is a schematic diagram 320 illustrating a simplified portion of custom conditions 127 determined by authentication application 123 for a contactless card 101 being activated. More specifically, FIG. 3C illustrates an embodiment in which the contactless card 101 being activated is a replacement for a previous contactless card 101. Therefore, web browser 115 may output some conditions, such as conditions 321, in a modified format, such as in bold or italic font. This may allow the user to easily view the conditions. Additionally, as shown, web browser 115 may provide a link 322 to the complete conditions specific to the account owner and card 101. When accessed, link 322 may cause web browser 115 to display all relevant conditions. The user may accept the conditions by selecting an accept button, which may cause web browser 115 to send an indication of acceptance to authentication application 123. FIG. 3D is a schematic diagram 330 illustrating an embodiment in which authentication application 123 activates card 101 for use and returns a success page to web browser 115.

[0039] 4A is a schematic diagram 400 illustrating an example embodiment of tapping a contactless card 101 to provide secure activation using custom conditions of the contactless card 101. As shown, an account application 113 may run on a mobile device 110 and prompt a user to tap the contactless card 101 for activation. When the user taps the contactless card 101 against the mobile device 110, an applet 103 on the contactless card 101 encrypts a customer ID 107. The applet 103 may then transmit the encrypted customer ID 107 to the mobile device 110, for example, via NFC.

[0040] 4B is a schematic diagram 410 illustrating an embodiment in which the account application 113 receives the encrypted customer ID 107 from the contactless card 101. The account application 113 may then send the encrypted customer ID 107 to the authentication application 123 for verification. The authentication application 123 may then attempt to decrypt the encrypted customer ID 107 using the private key 105 and / or diversified key 106 assigned to the contactless card 101. If the authentication application 123 is unable to decrypt the encrypted customer ID 107 and obtain the expected result (e.g., the customer ID 107 of the account), the authentication application 123 does not verify the encrypted customer ID 107. If the authentication application 123 successfully decrypts the encrypted customer ID 107 and obtains the expected result (e.g., the customer ID 107 of the account), the authentication application 123 verifies the encrypted customer ID 107. 4B, the authentication application 123 successfully decrypts the encrypted customer ID, and the authentication application 123 sends a verification instruction to the web browser 115. The authentication application 123 may then determine custom conditions for the contactless card 101 based on one or more attributes of the card 101 and / or one or more attributes of the account holder.

[0041] FIG. 4C is a schematic diagram 420 illustrating a simplified portion of the custom conditions 127 determined by the authentication application 123 for the contactless card 101 being activated. More specifically, FIG. 4C illustrates an embodiment in which the contactless card 101 being activated is not a replacement for a previous contactless card 101. Thus, the account application 113 may output all conditions received from the authentication application 123. Although not shown in FIG. 4C (or FIG. 3C) for clarity, the complete set of conditions may be displayed on the device 110. The user may accept the conditions by selecting an accept button, which may cause the account application 113 to send an indication of acceptance to the authentication application 123. FIG. 4D is a schematic diagram 430 illustrating an embodiment in which the authentication application 123 activates the card 101 for use and returns a success page to the account application 113.

[0042] FIG. 5A illustrates a contactless card 101, which may comprise a payment card such as a credit card, debit card, and / or gift card. As shown, the contactless card 101 may be issued by a service provider 502, which may display the card's name on the front or back. In some examples, the contactless card 101 may comprise, but is not limited to, an identification card unrelated to a payment card. In some examples, the payment card may comprise a dual-interface contactless payment card. The contactless card 101 may comprise a substrate 510, which may include a single layer or one or more laminated layers composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium oxide, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 101 may have physical characteristics that conform to the ID-1 format of the ISO / IEC 7810 standard; otherwise, the contactless card 101 may conform to the ISO / IEC 14443 standard. However, it should be understood that contactless cards 101 according to the present disclosure may have different characteristics and the present disclosure does not require contactless cards to be implemented as payment cards.

[0043] 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 be configured to establish contact with other communication devices, such as the mobile device 110, a user device, a smartphone, a laptop, a desktop, or a tablet computer. The contactless card 101 may also include processing circuitry, an antenna, and other components not shown in FIG. 5A. These components may be located behind the contact pad 520 or elsewhere on the substrate 510. The contactless card 101 may also include a magnetic strip or tape (not shown in FIG. 5A) that may be located on the back of the card.

[0044] 5B, contact pad 520 of contactless card 101 may include processing circuitry 525 for storing and processing information, including microprocessor 530 and memory 102. It will be understood that 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 tamper-proof hardware, as needed to perform the functions described herein.

[0045] The memory 102 may be read-only memory, write-once read-multiple memory, or read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 101 may include one or more of these memories. Read-only memory may be read-only or one-time programmable at the factory. One-time programming 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 may not be rewritten, but it may be read many times. Read / write memory may be programmed and reprogrammed many times after leaving the factory. Read / write memory may be read many times after leaving the factory.

[0046] Memory 102 may be configured to store one or more applets 103, counter value 104, secret key 105, diversified key 106, and one or more customer (or user) IDs 107. One or more applets 103 may comprise 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 applet 103 is not limited to a Java Card applet and may be any software application capable of operating on a contactless card or other device with limited memory. Customer ID 107 may comprise a unique alphanumeric identifier assigned to a user of contactless card 101, which may distinguish a contactless card user from other contactless card users. In some examples, customer ID 107 may identify both a customer and an account assigned to that customer, and may further identify a contactless card associated with the customer's account. In some embodiments, applet 103 may use customer ID 107 as input to an encryption algorithm using keys 105 and / or 106 to encrypt customer ID 107. Similarly, the applet 103 may construct a URL that includes the encrypted customer ID 107 as a parameter. The URL may be directed to the server 120 and / or the account application 113.

[0047] Although the processor and memory elements of the foregoing exemplary embodiments are described with reference to contact pads, the present disclosure is not limited thereto, and it will be understood that these elements may be implemented external to, or completely separate from, the pads 520, or as additional elements in addition to the processor 530 and memory 102 elements located within the contact pads 520.

[0048] 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 pads 520. For example, the one or more antennas 555 may be integrated 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 pads 520 and the processing circuit 525.

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

[0050] As described above, contactless card 101 may be built on a software platform operable on a memory-limited smart card or other device, such as a Java Card, and one or more applications or applets may be securely executed. The applets 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 applets may be configured to respond to one or more requests, such as near-field wireless data exchange requests, from a reader, such as a mobile NFC reader (e.g., communication interface 118 of device 110), and generate an NDEF message comprising a cryptographically secure OTP (e.g., an encrypted customer ID) encoded as an NDEF text tag.

[0051] The operation of the disclosed embodiments may be further explained with reference to the following figures. Some figures may include logic flows. While such diagrams presented herein may include specific logic flows, it should be understood that the logic flows merely provide examples of how the general functionality described herein may be implemented. Furthermore, a given logic flow does not necessarily have to be executed in the order presented, unless otherwise indicated. 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.

[0052] 6 illustrates one embodiment of a logic flow 600. The logic flow 600 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 600 may include some or all of the operations for activating the contactless card 101 using conditions specific to the contactless card and account owner. The embodiments are not limited in this context.

[0053] As shown, logic flow 600 begins at block 605, where a user taps contactless card 101 to mobile device 110, causing applet 103 on contactless card 101 to generate encrypted data. At block 610, applet 103 generates customer ID 107 as part of a URL that includes the encrypted data. At block 615, the applet sends the URL that includes the encrypted data to mobile device 110. At block 620, OS 112 may launch web browser 115 to access the URL that includes the encrypted data, which may be directed to server 120 and / or authentication application 123. Server 120 may attempt to decrypt the encrypted customer ID included in the URL, as described herein. At block 625, web browser 115 receives an indication from server 120 that the encrypted customer ID 107 has been verified by decrypting the encrypted customer ID 107. In doing so, the server 120 may determine conditions specific to the account holder and the contactless card 101 .

[0054] At block 630, web browser 115 receives the plurality of terms from server 120 and outputs the terms for display. At block 635, web browser 115 receives acceptance of the terms from the user. At block 640, web browser 115 sends an indication of acceptance to server 120. Doing so may cause server 120 to activate contactless card 101. At block 645, web browser 115 may receive and output an indication from the server specifying that contactless card 101 has been activated.

[0055] 7 illustrates one embodiment of a logic flow 700. The logic flow 700 may represent 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 for activating the contactless card 101 using conditions specific to the contactless card and account owner. The embodiments are not limited in this context.

[0056] As shown, logic flow 700 begins at block 705, where a user taps contactless card 101 to mobile device 110, causing applet 103 of contactless card 101 to generate encrypted data. At block 710, applet 103 generates an encrypted customer ID 107, which may be part of a URL containing the encrypted data, the URL directed to an activation page of account application 113. At block 715, the applet sends the URL containing the encrypted data to mobile device 110. At block 720, OS 112 may launch account application 113 and open the card activation page in response to receiving URL 108 containing the encrypted data. At block 725, account application 113 sends the received encrypted data (e.g., encrypted customer ID 107) to server 120. In one embodiment, the account application extracts the encrypted data (e.g., the encrypted customer ID 107) from the URL 108 before sending the encrypted data to the server. In other embodiments, the account application 113 sends the URL 108 containing the encrypted data to the server 120. The server 120 may then attempt to decrypt the encrypted data as described herein. In doing so, the server 120 may determine conditions specific to the account holder and the contactless card 101.

[0057] At block 730, the account application 113 receives an indication from the server 120 that the encrypted customer ID 107 has been verified by decrypting the encrypted customer ID 107 and the determined plurality of conditions. At block 735, the account application 113 receives acceptance of the conditions from the user. At block 740, the account application 113 sends an indication of acceptance to the server 120. Doing so may cause the server 120 to activate the contactless card 101. At block 745, the account application 113 may receive and output an indication from the server specifying that the contactless card 101 has been activated.

[0058] 8 illustrates one embodiment of a logic flow 800. The logic flow 800 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 800 may include some or all of the operations for activating the contactless card 101 using conditions specific to the contactless card and account owner. The embodiments are not limited in this context.

[0059] As shown, logic flow 800 begins at block 805, where server 120 receives a URL containing encrypted data from web browser 115 executing on mobile device 110. The URL containing the encrypted data may be generated by applet 103 of contactless card 101 based at least in part on a private key assigned to contactless card 101. At block 810, server 120 may decrypt the encrypted data based on an instance of the private key maintained by server 120. At block 815, server 120 determines the type of contactless card 101. For example, a unique identifier for contactless card 101 may be stored in account data 124 and / or card data 126. The unique identifier may be used, for example, in card data 126, to determine the type of card. Card data 126 may specify the type of card, the date the card was issued, and any associated conditions 127 regarding the card. At block 820, the server 120 determines multiple terms and / or conditions for the card based on user attributes such as age, location, credit limit, etc.

[0060] At block 825, server 120 may optionally identify changed conditions on the card, such as if the card is a replacement for a previous card held by the account holder. Server 120 may modify the changed conditions (e.g., highlight, bold, increase font size, etc.) to improve readability on the user's device. At block 830, server 120 sends an indication to web browser 115 that server 120 has decrypted the encrypted data, thereby verifying the encrypted data. Server 120 may further transmit the conditions determined at block 820, which may be output for display by web browser 115. At block 835, server 120 receives an indication from web browser 115 specifying that the user has accepted the terms. At block 840, server 120 stores (e.g., in account data 124) an indication indicating that the card has been activated for use based on the acceptance of the terms and the decryption of the encrypted data. At block 845, the server 120 sends an indication that the card has been activated to the web browser 115. The web browser 115 may display the indication on a display.

[0061] 9 illustrates one embodiment of a logic flow 900. The logic flow 900 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logic flow 900 may include some or all of the operations for activating the contactless card 101 using conditions specific to the contactless card and account owner. The embodiments are not limited in this context.

[0062] As shown, logic flow 900 begins at block 905, where server 120 receives encrypted data from account application 113 executing on mobile device 110. The encrypted data may be generated by applet 103 of contactless card 101 based at least in part on a private key assigned to contactless card 101. In some embodiments, applet 103 includes the encrypted data as a parameter of a URL containing the encrypted data. At block 910, server 120 may decrypt the encrypted data based on an instance of the private key maintained by server 120. At block 915, server 120 determines the type of contactless card 101. For example, a unique identifier for contactless card 101 may be stored in account data 124 and / or card data 126. The unique identifier may be used, for example, in card data 126, to determine the type of card. Card data 126 may specify the type of card, the date the card was issued, and any associated conditions 127 regarding the card. At block 920, the server 120 determines multiple terms and / or conditions for the card based on user attributes such as age, location, credit limit, etc.

[0063] At block 925, server 120 may optionally identify changed conditions on the card, such as if the card is a replacement for a previous card held by the account holder. Server 120 may modify the changed conditions (e.g., highlight, bold, increase font size, etc.) to improve readability on the user's device. At block 930, server 120 sends an indication to account application 113 that it has decrypted the encrypted data, thereby verifying the encrypted data. Server 120 may further transmit the conditions determined at block 920, which may be output for display by account application 113. At block 935, server 120 receives an indication from account application 113 specifying that the user has accepted the terms. At block 940, server 120 stores (e.g., in account data 124) an indication indicating that the card has been activated for use based on the acceptance of the terms and the decryption of the encrypted data. In block 945, the server 120 sends an indication that the card has been activated to the account application 113. The account application 113 may display the indication on a display.

[0064] FIG. 10 illustrates an embodiment of an exemplary computing architecture 1000 comprising a computing system 1002 that may be suitable for implementing various embodiments as described above. In various embodiments, the computing architecture 1000 may comprise or be implemented as part of an electronic device. In some embodiments, the computing architecture 1000 may represent, for example, a system implementing one or more components of the system 100. In some embodiments, the computing system 1002 may represent, for example, the contactless card 101, the mobile device 110, and the authentication server 120 of the system 100. In this context, the embodiments are not limited. More generally, the computing architecture 1000 is configured to implement all logic, applications, systems, methods, apparatus, and functions described herein with reference to FIGS. 1-9.

[0065] As used in this application, the terms “system,” “component,” and “module” are intended to refer to any computer-related entity: hardware, a combination of hardware and software, software, or software in execution, an example of which is provided by exemplary computing architecture 1000. For example, a component may be, but is not limited to, a process running on a computer processor, a computer 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 and coordinate their operations by various types of communication media. 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. Information may be embodied as signals assigned to various signal lines. In such assignments, each message is a signal. However, further embodiments may alternatively use data messages. Such data messages may be transmitted over a variety of connections. Example connections include parallel interfaces, serial interfaces, and bus interfaces.

[0066] The computing system 1002 includes various typical 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 by the computing system 1002.

[0067] 10, computing system 1002 includes processor 1004, system memory 1006, and system bus 1008. Processor 1004 may be any of a variety of commercially available computer processors, including, but not limited to, AMD® Athlon®, Duron®, and Opteron® processors, ARM® application, embedded, and secure processors, IBM® and Motorola® DragonBall® and PowerPC® processors, IBM and Sony® Cell processors, Intel® Celeron®, Core®, Core(2) Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors and similar processors. Dual microprocessors, multi-core processors, and other multi-processor architectures may also be used as processor 1004.

[0068] The system bus 1008 provides an interface to system components, including but not limited to, the processor 1004, from the system memory 1006. The system bus 1008 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 1008 through a slot architecture. Examples of slot architectures include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, (Extended) Industry Standard Architecture ((E)ISA), MicroChannel Architecture (MCA), NuBus, Peripheral Component Interconnect (Expansion) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), etc.

[0069] The system memory 1006 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 (e.g., one or more flash arrays), polymer memory such as ferroelectric polymer memory, ovonic memory, phase-change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, arrays of devices such as redundant array of independent disks (RAID) drives, solid-state memory devices (e.g., USB memory, solid-state drive (SSD)), and other types of storage media suitable for storing information. In the illustrated embodiment shown in FIG. 10, the system memory 1006 may include non-volatile memory 1010 and / or volatile memory 1012. The non-volatile memory 1010 may store a basic input / output system (BIOS).

[0070] Computing system 1002 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 (HDD) 1014, a magnetic floppy disk drive (FDD) 1016 that reads from or writes to a removable magnetic disk 1018, and an optical disk drive 1020 that reads from or writes to a removable optical disk 1022 (e.g., a CD-ROM or DVD). HDD 1014, FDD 1016, and optical disk drive 1020 may be connected to system bus 1008 by HDD interface 1024, FDD interface 1026, and optical drive interface 1028, respectively. HDD interface 1024 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies. The computing system 1002 is generally configured to implement all of the logic, systems, methods, devices, and functionality described herein with reference to FIGS.

[0071] The drives and associated computer-readable media provide volatile and / or nonvolatile storage of data, data structures, computer-readable instructions, computer-executable instructions, etc. For example, a number of program modules may be stored on the drives and memory units 1010, 1012, including an operating system 1030, one or more application programs 1032, other program modules 1034, and program data 1036. In one embodiment, the one or more application programs 1032, other program modules 1034, and program data 1036 may include, for example, various applications and / or components of the system 100, such as applets 103, counters 104, private keys 105, diversified keys 106, customer ID 107, operating system 112, account application 113, web browser 115, authentication application 123, account data 124, card data 126, conditions 127, URLs 108 containing encrypted data, and / or encrypted data 208.

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

[0073] A monitor 1044 or other type of display device is also connected to the system bus 1008 via an interface, such as a video adapter 1046. The monitor 1044 may be internal or external to the computing system 1002. In addition to the monitor 1044, computers typically include other peripheral output devices, such as speakers, printers, etc.

[0074] The computing system 1002 may 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 1048. The remote computer 1048 may 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 and typically includes many or all of the elements described relative to the computing system 1002, although for simplicity, only the memory / storage device 1050 is shown. The logical connections shown include wired / wireless connections to a local area network (LAN) 1052 and / or larger networks, e.g., a wide area network (WAN) 1054. Such LAN and WAN networking environments are commonplace in offices and businesses, facilitating enterprise-wide computer networks such as intranets. All of these may connect to a global communications network, e.g., the Internet. In an embodiment, the network 130 of FIG. 1 is one or more of the LAN 1052 and the WAN 1054.

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

[0076] When used in a WAN networking environment, the computing system 1002 may include a modem 1058 or have other means for establishing communications over the WAN 1054, such as connected to a communications server on the WAN 1054 or via the Internet. The modem 1058 may be internal or external, a wired and / or wireless device, and connects to the system bus 1008 via the input device interface 1042. In a networked environment, program modules depicted relative to the computing system 1002, or portions thereof, may be stored in the remote memory / storage device 1050. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between computers may be used.

[0077] The computing system 1002 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.16 wireless modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, Bluetooth® wireless technologies, and the like. Thus, communication can be in a predefined structure, similar to a traditional network, or simply ad hoc communication between at least two devices. Wi-Fi networks use radio technologies called IEEE 802.11x (a, b, g, n, etc.) to provide secure, reliable, and high-speed wireless connectivity. Wi-Fi networks can be used to connect computers to each other, to the Internet, or to wired networks (using IEEE 802.3-related media and functions).

[0078] Various embodiments may be implemented using hardware elements, software elements, or a combination of both. Examples of hardware elements may include a processor, a microprocessor, a circuit, a circuit element (e.g., a transistor, a resistor, a capacitor, an inductor, etc.), an integrated circuit, an application specific integrated circuit (ASIC), a programmable logic device (PLD), a digital signal processor (DSP), a field programmable gate array (FPGA), a logic gate, a register, a semiconductor device, a chip, a microchip, a chipset, etc. Examples of software may include a software component, a program, an application, a computer program, an application program, a system program, a machine program, an operating system software, a middleware, a firmware, a software module, a routine, a subroutine, a function, a method, a procedure, a software interface, an application program interface (API), an instruction set, a computing code, a computer code, a code segment, a computer code segment, a word, a value, a symbol, or any combination thereof. The decision whether an embodiment is implemented using hardware and / or software elements may vary according to any number of factors, such as desired computational speed, power level, heat tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed and other design or performance constraints.

[0079] 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, which, when read by a machine, causes the machine to manufacture logic that performs the techniques described herein. Such representations, known as “IP cores,” are 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 the 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. 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 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 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., and may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0080] 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 appended claims. 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 as variously disclosed or demonstrated herein.

Claims

1. a server receiving a request from a device to activate a contactless card, the request including encrypted data, the encrypted data generated by the contactless card and read by the device; the server decrypting the encrypted data; the server determining, based on a unique identifier of the contactless card, that the contactless card is a first type of a plurality of types of contactless cards, the plurality of types of contactless cards including a credit card, a debit card, an automated teller machine (ATM) card, and a gift card; the server determining a plurality of conditions associated with the first type of contactless card; the server transmitting the plurality of conditions to the device; receiving, by the server, an indication from the device specifying acceptance of the plurality of conditions; storing, by the server, instructions in a database specifying that the contactless card is activated for use based on the received instructions specifying the decryption of the encrypted data and acceptance of the plurality of terms and conditions; A method comprising:

2. The method of claim 1 , wherein the encrypted data is a parameter of a uniform resource locator (URL).

3. The method comprises: the server extracting the encrypted data from the URL; the server decoding the extracted ciphertext prior to said decryption; The method of claim 2 further comprising:

4. the server sending instructions to the device specifying that the contactless card is activated for use; The method of claim 1 further comprising:

5. The method comprises: the server receiving a plurality of attributes from a user profile associated with the contactless card, the plurality of attributes including at least the first type of the contactless card and an address associated with the contactless card; the server determining the plurality of conditions based on the first type of the contactless card and the address associated with the contactless card, wherein at least one condition of the plurality of conditions is based on the address; The method of claim 1 further comprising:

6. The encrypted data is based on a diversified key of the contactless card; the diversified key is based on a counter value and another key of the contactless card; the encrypted data is decrypted by the server by generating a copy of the diversified key based on a copy of the counter value and a copy of the other key; The method of claim 1.

7. The method comprises: a subset of the plurality of terms is formatted according to a modified format, the modified format including one or more of a highlight effect, a bold effect, or an italic effect applied to the subset of the plurality of terms and not to the remaining terms; The method of claim 1 , comprising:

8. A non-transitory computer-readable storage medium, the computer-readable storage medium, when executed by a processor, causing the processor to: receiving a request from a device to activate a contactless card, the request including encrypted data generated by the contactless card and read by the device; decrypting the encrypted data; determining that the contactless card is a first type of a plurality of types of contactless cards based on a unique identifier of the contactless card, the plurality of types of contactless cards including a credit card, a debit card, an automated teller machine (ATM) card, and a gift card; determining a plurality of conditions associated with the first type of contactless card; transmitting the plurality of conditions to the device; receiving an indication from the device specifying acceptance of the plurality of conditions; storing instructions in a database specifying that the contactless card is activated for use based on the received instructions specifying the decryption of the encrypted data and acceptance of the plurality of terms and conditions; A non-transitory computer-readable storage medium containing instructions for causing a computer to execute 9. The non-transitory computer-readable storage medium of claim 8, wherein the encrypted data is a parameter of a uniform resource locator (URL).

10. The instructions to the processor further include: extracting the encrypted data from the URL; decoding the extracted ciphertext prior to said decryption; 10. The non-transitory computer-readable storage medium of claim 9, 11. The instructions to the processor further include: sending an instruction to the device specifying that the contactless card has been activated for use; The non-transitory computer-readable storage medium of claim 8 ,

12. The instructions further cause the processor to: receiving a plurality of attributes from a user profile associated with the contactless card, the plurality of attributes including at least the first type of the contactless card and an address associated with the contactless card; determining the plurality of conditions based on the first type of the contactless card and the address associated with the contactless card, wherein at least one condition of the plurality of conditions is based on the address; The non-transitory computer-readable storage medium of claim 8 ,

13. A subset of the plurality of conditions is formatted according to a modified format, the modified format including one or more of a highlight effect, a bold effect, or an italic effect applied to the subset of the plurality of conditions and not to the remaining plurality of conditions; The non-transitory computer-readable storage medium of claim 8 , 14. A computing device comprising: a processor; and a memory storing instructions that, when executed by the processor, cause the processor to: receiving a request from a device to activate a contactless card, the request including encrypted data generated by the contactless card and read by the device; decrypting the encrypted data; determining, based on a unique identifier, that the contactless card is a first type of a plurality of types of contactless cards, the plurality of types of contactless cards including a credit card, a debit card, an automated teller machine (ATM) card, and a gift card; determining a plurality of conditions associated with the first type of contactless card; transmitting the plurality of conditions to the device; receiving an indication from the device specifying acceptance of the plurality of conditions; storing instructions in a database specifying that the contactless card is activated for use based on the received instructions specifying the decryption of the encrypted data and acceptance of the plurality of terms and conditions; A computing device that runs 15. The computing device of claim 14, wherein the encrypted data is a parameter of a uniform resource locator (URL).

16. The instructions to the processor further include: extracting the encrypted data from the URL; decoding the extracted ciphertext prior to said decryption; 16. The computing device of claim 15, configured to execute:

17. The instructions to the processor further include: sending an instruction to the device specifying that the contactless card has been activated for use; 15. The computing device of claim 14, configured to execute:

18. A non-transitory computer-readable storage medium as described in claim 8, wherein the encrypted data is based on a diversified key of the contactless card, the diversified key being based on a counter value and another key of the contactless card, and the encrypted data is encrypted by generating a copy of the diversified key based on a copy of the counter value and a copy of the other key.

19. The computing device of claim 14, wherein the encrypted data is based on a diversified key of the contactless card, the diversified key being based on a counter value and another key of the contactless card, and the encrypted data is encrypted by generating a copy of the diversified key based on a copy of the counter value and a copy of the other key.

20. A subset of the plurality of conditions is formatted according to a modified format, the modified format including one or more of a highlight effect, a bold effect, or an italic effect applied to the subset of the plurality of conditions and not to the remaining conditions.

15. The computing device of claim 14.

Images