A system and method for launching a mobile application or browser extension in response to the fulfillment of predetermined conditions.

Abstract

A method and system are provided for a mobile device that can receive encryption from a contactless card, verify the encryption, and launch a shopping mobile application and / or a shopping browser extension on the mobile device when the encryption is verified and a merchant mobile application is running on the mobile device. The method may include displaying a request to communicate with a contactless card on the mobile device's display screen. For example, the method may include displaying a request to communicate with a contactless card on the mobile device's display screen in response to displaying a payment screen associated with a first mobile application on the mobile device's display screen.

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims the priority of U.S. Patent Application No. 18 / 131,935, filed on April 7, 2023, the disclosure of which is hereby incorporated by reference in its entirety.

Background Art

[0002] Browser extensions that add functionality to or improve the functionality of a website are known in the art. For example, shopping browser extensions such as Capital One Shopping can automatically apply coupons available for any item in the cart of the visited website at checkout and / or automatically search for a better price for any item in the cart of the visited website at checkout and display the better price found on an alternative website within a pop - up window, thereby improving the user's online shopping experience. In operation, the shopping browser extension runs in the background and can search multiple websites for available coupons and / or better prices.

[0003] Currently, known shopping browser extensions are only available via a web browser on the desktop, thereby preventing users who shop and purchase via a mobile application from benefiting from the shopping browser extension.

Summary of the Invention

[0004] [[ID=2

[0005] In some embodiments, the method may include displaying a request to communicate with a contactless card on the mobile device's display screen in response to a first mobile application running on the mobile device. For example, in some embodiments, the method may include displaying a request to communicate with a contactless card on the mobile device's display screen in response to displaying a payment screen associated with the first mobile application on the mobile device's display screen. Additionally or alternatively, in some embodiments, the method may include displaying a request to communicate with a contactless card on the mobile device's display screen in response to an item being placed in a shopping cart associated with the first mobile application.

[0006] In some embodiments, the method may include successfully decrypting the cipher in order to verify the cipher. For example, in some embodiments, the method may include decrypting protected data within the cipher, comparing the protected data with recorded data associated with the contactless card, and verifying the customer associated with the contactless card if the protected data matches the recorded data.

[0007] In some embodiments, the method may include sending an encryption key from a mobile device to a server and receiving a notification from the server on the mobile device that the encryption key has been verified.

[0008] In some embodiments, a second mobile application or shopping browser extension can automatically apply available coupons to items in the cart associated with the first mobile application. Additionally or alternatively, in some embodiments, the second mobile application or shopping browser extension can automatically search for better prices for items in the cart associated with the first mobile application and display the better prices found on alternative websites on the mobile device's display screen.

[0009] In some embodiments, the non-temporary computer-readable medium, when executed by the processor, may include instructions that cause the processor to receive encryption from a contactless card via the mobile device's near-field communication antenna, verify the encryption, and, once the encryption is verified, launch a second mobile application or shopping browser extension on the mobile device when a first mobile application is running on the mobile device.

[0010] In some embodiments, in response to a first mobile application running on a mobile device, the instruction can further cause the processor to display a request to communicate with a contactless card on the mobile device's display screen. For example, in some embodiments, in response to displaying a payment screen associated with the first mobile application on the mobile device's display screen, the instruction can further cause the processor to display a request to communicate with a contactless card on the mobile device's display screen. Additionally or alternatively, in some embodiments, in response to items placed in a shopping cart associated with the first mobile application, the instruction can further cause the processor to display a request to communicate with a contactless card on the mobile device's display screen.

[0011] In some embodiments, the instruction can further cause the processor to successfully decrypt the cipher in order to verify the cipher. For example, in some embodiments, the instruction can further cause the processor to decrypt the protected data within the cipher, compare the protected data with the recorded data associated with the contactless card, and verify the customer associated with the contactless card if the protected data matches the recorded data.

[0012] In some embodiments, the instruction can further cause the processor to send an encryption from the mobile device to the server and for the mobile device to receive an instruction from the server that the encryption has been verified.

[0013] In some embodiments, a second mobile application or shopping browser extension can automatically apply available coupons to items in the cart associated with the first mobile application. Additionally or alternatively, in some embodiments, the second mobile application or shopping browser extension can automatically search for better prices for items in the cart associated with the first mobile application and display the better prices found on alternative websites on the mobile device's display screen.

[0014] In some embodiments, the mobile device may include a near-field communication antenna, a processor, and a memory for storing instructions, which, when executed by the processor, cause the processor to receive encryption from a contactless card via the near-field communication antenna, verify the encryption, and, once the encryption is verified, launch a second mobile application or shopping browser extension while the processor is running a first mobile application.

[0015] In some embodiments, the mobile device may also include a display device, and instructions may further cause a processor to display a request on a screen to communicate with a contactless card in response to a processor running a first mobile application.

[0016] Other technical features may be readily apparent to those skilled in the art from the following drawings, description, and claims. [Brief explanation of the drawing]

[0017] [Figure 1] An example of a system according to one embodiment is shown. [Figure 2] An example of a system according to one embodiment is shown. [Figure 3] An example of a contactless card according to one embodiment is shown. [Figure 4] An example of a transaction card component according to one embodiment is shown. [Figure 5] An example of a sequence flow according to an embodiment is shown. [Figure 6] An example of a data structure according to an embodiment is shown. [Figure 7] An example of a key system according to an embodiment is shown. [Figure 8] An example of a method for generating an encryption according to an embodiment is shown. [Figure 9] An example of a method for key diversification according to an embodiment is shown. [Figure 10] An example of a method for card activation according to an embodiment is shown. [Figure 11] An example of a mobile device according to an embodiment is shown. [Figure 12] An example of a system according to an embodiment is shown. [Figure 13] An example of a method according to an embodiment is shown. [Figure 14] An example of a sequence flow according to an embodiment is shown. [Figure 15] An example of a computer architecture according to an embodiment is shown. [Figure 16] An example of a communication architecture according to an embodiment is shown.

Best Mode for Carrying Out the Invention

[0018] Embodiments disclosed herein generally relate to systems and methods for launching a mobile application or browser extension in response to meeting certain conditions. For example, a contactless card can be registered with a mobile device. The contactless card can also be registered with a shopping mobile application and / or a shopping browser extension, such as Capital One Shopping. When the mobile device is being used for shopping via a merchant application, the mobile device can receive an encryption key from the contactless card, verify the encryption key, and, when the encryption key is verified, launch the shopping mobile application and / or the shopping browser extension. In this context, launching can include opening and executing the shopping mobile application and / or the shopping browser extension on the mobile device. The certain conditions that can be met can include the merchant application running on the mobile device, the mobile device receiving an encryption key from the contactless card, the contactless card registered with the mobile device, the contactless card registered with the shopping mobile application and / or the shopping browser extension, and the mobile device verifying the encryption key.

[0019] Advantageously, once a shopping mobile application and / or shopping browser extension is launched, it can add functionality to and / or enhance the functionality of the merchant application. For example, in some embodiments, the shopping mobile application and / or shopping browser extension can automatically apply available coupons to any items in the shopping cart associated with the merchant application. Additionally or alternatively, in some embodiments, the shopping mobile application and / or shopping browser extension can automatically search for a better price for any item in the shopping cart associated with the merchant application and display the better price found on an alternative website to the user of the mobile device.

[0020] A further advantage of the embodiments disclosed herein is the ability to open a shopping mobile application and / or shopping browser extension without requiring the user to exit the merchant application. For example, a user can bring a contactless card within range of their mobile device and send an encryption without exiting the merchant application. Furthermore, the shopping mobile application and / or shopping browser extension can be launched automatically in response to encryption verification, so that the user does not need to exit the merchant application to select the shopping mobile application and / or shopping browser extension.

[0021] A further advantage of the embodiments disclosed herein is that the shopping mobile application and / or shopping browser extension can run in the background to search multiple websites for available coupons and / or better prices. Thus, the user can continue shopping through the merchant application without interruption while simultaneously being presented with the benefits associated with those better deals.

[0022] Another advantage of the embodiments disclosed herein may include ensuring that the shopping mobile application and / or shopping browser extension is launched only for its registered users. For example, since cryptographic, and therefore contactless, cards and their associated users must be verified before launching the shopping mobile application and / or shopping browser extension, the embodiments disclosed herein can ensure that contactless cards are registered with the shopping mobile application and / or shopping browser extension before launch. In this regard, contactless cards and, therefore, their users that are not registered with the shopping mobile application and / or shopping browser extension may not be able to benefit from it.

[0023] Details of the embodiments identified above and their additional advantages are discussed in the following description.

[0024] Figure 1 shows a data transmission system 100 according to an exemplary embodiment. As will be further described below, the system 100 may include a contactless card 102, a client device 104, a network 106, and a server 108. Figure 1 shows one example of the components, but the system 100 may include any number of components.

[0025] The system 100 may include one or more contactless cards 102, which are further described below. In some embodiments, the contactless card 102 may communicate wirelessly with the client device 104, for example, by utilizing near-field communication (NFC).

[0026] System 100 may include a client device 104 which may be a network-enabled computer. As referred to herein, a network-enabled computer may include, but is not limited to, a computer device or communication device, including, for example, a server, network equipment, a personal computer, a workstation, a telephone, a handheld personal computer (PC), a personal digital assistant, a thin client, a fat client, an internet browser, or other device. The client device 104 may also be a mobile device, for example, an iPhone®, iPod®, iPad®, or any other mobile device running Apple's iOS® operating system, any device running Microsoft's Windows® mobile operating system, any device running Google's Android® operating system, and / or any other wearable mobile device such as a smartphone or tablet.

[0027] The client device 104 may include a processor and memory, and the processing circuit may include additional components, as necessary to perform the functions described herein, including a processor, memory, error and parity / cyclic redundancy check (CRC) checker, data encoder, anti-collision algorithm, controller, command decoder, security primitives, and tamper-proof hardware. The client device 104 may further include a display and input device. The display may be any type of device that presents visual information, such as a computer monitor, flat panel display, and mobile device screen, including liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays. The input device may include any device that inputs information into the user's device, which is available to and supported by the user's device, such as a touchscreen, keyboard, mouse, cursor control device, microphone, digital camera, video recorder, or camcorder. These devices may be used to input information and interact with software and other devices described herein.

[0028] In some examples, a client device 104 of system 100 may run one or more applications, such as software applications, that enable network communication with one or more components of system 100 and transmit and / or receive data.

[0029] The client device 104 can communicate with one or more servers 108 via one or more networks 106 and can operate with the server 108 as a front-end-back-end pair. The client device 104 can send one or more requests to the server 108, for example, from a mobile device application running on the client device 104. One or more requests may be associated with retrieving data from the server 108. The server 108 can receive one or more requests from the client device 104. The server 108 may be configured to retrieve the requested data from one or more databases (not shown) based on one or more requests from the client device 104. The server 108 may also be configured to send the received data to the client device 104 based on receiving the requested data from one or more databases, and the received data may respond to one or more requests.

[0030] System 100 may include one or more networks 106. In some examples, network 106 may be one or more wireless networks, wired networks, or any combination of wireless and wired networks, and may be configured to connect client devices 104 to server 108. For example, network 106 may include one or more optical fiber networks, passive optical networks, cable networks, Internet networks, satellite networks, wireless local area networks (LANs), global systems for mobile communications, personal communication services, personal area networks (PANs), wireless application protocols, multimedia messaging services, enhanced messaging services, short message services, time division multiplexing-based systems, code division multiplexing-based systems, digital advanced mobile phone services (D-AMPS), Wi-Fi (Wireless Fidelity), fixed wireless data, the Institute of Electrical and Electronics Engineers (IEEE) 802.11 network family, Bluetooth, NFC, radio frequency identification (RFID), and / or similar.

[0031] Furthermore, network 106 may include, but is not limited to, global networks such as telephone lines, optical fibers, IEEE Ethernet 802.3, WANs, wireless PANs, LANs, or the Internet. Additionally, network 106 may support Internet networks, wireless communication networks, cellular networks, or any combination thereof. Network 106 may further include one network or any number of networks of the exemplary types described above, either as standalone networks or working together. Network 106 may utilize one or more protocols of one or more network elements that are communicatively coupled. Network 106 may convert one or more protocols of network devices to and from other protocols. While network 106 is shown as a single network, it should be understood that, according to one or more examples, network 106 may include multiple interconnected networks, such as the Internet, service provider networks, cable television networks, corporate networks, such as credit card association networks, and home networks.

[0032] System 100 may include one or more servers 108. In some examples, server 108 may include one or more processors coupled to memory. Server 108 may be configured as a central system, server, or platform that controls and retrieves various data at different times to perform multiple workflow operations. Server 108 may be configured to connect to one or more databases. Server 108 may be connected to at least one client device 104.

[0033] Figure 2 shows a data transmission system according to an exemplary embodiment. System 200 may include a transmitter or transmitting device 204 and a receiver or receiving device 208 that communicate with one or more servers 202, for example, via a network 206. The transmitter or transmitting device 204 may be the same as or similar to the client device 104 described above with reference to Figure 1. The receiver or receiving device 208 may be the same as or similar to the client device 104 described above with reference to Figure 1. The network 206 may be the same as the network 106 described above with reference to Figure 1. The server 202 may be the same as the server 108 described above with reference to Figure 1. Figure 2 shows one example of the components of system 200, but system 200 may include any number of illustrated components.

[0034] When using symmetric encryption algorithms, such as encryption algorithms, hash-based message authentication code (HMAC) algorithms, and cryptographic-based message authentication code (CMAC) algorithms, it is important that the key remains secret between the party that initially processes the data protected using the symmetric algorithm and key, and the party that receives and processes the data using the same encryption algorithm and the same key.

[0035] It is also important that the same key is not used too many times. If a key is used or reused too frequently, it can be compromised. Each time a key is used, the attacker is provided with an additional sample of data processed by the cryptographic algorithm using that same key. The more data processed with the same key the attacker has, the higher the chance that the attacker will discover the key's value. Frequently used keys can be included in a variety of different attacks.

[0036] Furthermore, each time a symmetric encryption algorithm is executed, information such as side-channel data about the key used during the symmetric encryption operation may be revealed. Side-channel data may include minute power fluctuations that occur when the cryptographic algorithm is executed while using the key. If the side-channel data is sufficiently measured, enough information about the key may be revealed to enable an attacker to decrypt the data. If the same key is used to exchange data, the data processed with the same key will be revealed repeatedly.

[0037] However, by limiting the number of times a particular key is used, the amount of side-channel data that an attacker can collect is limited, thereby reducing exposure to this and other types of attacks. As further described herein, parties involved in the exchange of cryptographic information (e.g., sender and receiver) can generate keys independently of the initial shared master symmetric key in combination with a counter value, thereby periodically replacing the shared symmetric key used without having to rely on any form of key exchange to maintain synchronization between the parties. By periodically changing the shared secret symmetric key used by the sender and receiver, the aforementioned attacks become impossible.

[0038] Referring back to Figure 2, System 200 can implement key diversification. For example, the sender and receiver may wish to exchange data (e.g., original confidential data) through their respective devices 204 and 208. As mentioned above, one example of a sending device 204 and a receiving device 208 may be included, but it is understood that one or more sending devices 204 and one or more receiving devices 208 may be involved, as long as each party shares the same shared secret symmetric key. In some examples, the sending device 204 and the receiving device 208 may be provisioned with the same master symmetric key. Furthermore, it is understood that any party or device holding the same secret symmetric key may perform the functions of the sending device 204, and similarly, any party holding the same secret symmetric key may perform the functions of the receiving device 208. In some examples, the symmetric key may include a shared secret symmetric key that is kept secret from all parties other than the sending device 204 and the receiving device 208 involved in the exchange of secure data. The same master symmetric key may be provided to both the transmitting device 204 and the receiving device 208, and it is further understood that some of the data exchanged between the transmitting device 204 and the receiving device 208 may include at least some of the data which may be called a counter value. The counter value may include a number which changes each time data is exchanged between the transmitting device 204 and the receiving device 208.

[0039] System 200 may include one or more networks 206. In some examples, network 206 may be one or more wireless networks, wired networks, or any combination of wireless and wired networks, and may connect one or more transmitting devices 204 and one or more receiving devices 208 to server 202. For example, network 206 may include one or more fiber optic networks, passive optical networks, cable networks, Internet networks, satellite networks, wireless LANs, global systems for mobile communications, personal communication services, PANs, wireless application protocols, multimedia messaging services, enhanced messaging services, short message services, time division multiplexing-based systems, code division multiplexing-based systems, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11 network families, Bluetooth, NFC, RFID, and / or similar.

[0040] Furthermore, network 206 may include, but is not limited to, global networks such as telephone lines, fiber optics, IEEE Ethernet 902.3, WANs, wireless PANs, LANs, or the Internet. Additionally, network 206 may support Internet networks, wireless communication networks, cellular networks, or any combination thereof. Network 206 may further include one network or any number of networks of the exemplary types described above, either as standalone networks or working together. Network 206 may utilize one or more protocols of one or more network elements that are communicatively coupled. Network 206 may convert one or more protocols of network devices to and from other protocols. While network 206 is presented as a single network, it should be understood that, according to one or more examples, network 206 may include multiple interconnected networks, such as the Internet, service provider networks, cable television networks, corporate networks, such as credit card association networks, and home networks.

[0041] In some examples, one or more transmitting devices 204 and one or more receiving devices 208 may communicate with and send / receive data from each other without using the network 206. For example, communication between one or more transmitting devices 204 and one or more receiving devices 208 may be performed via at least one of the following: NFC, Bluetooth, RFID, Wi-Fi, etc.

[0042] In block 210, the sender may update the counter when the sending device 204 is preparing to process sensitive data using symmetric cryptographic operations. Furthermore, the sending device 204 may select an appropriate symmetric cryptographic algorithm, which may include at least one of the symmetric cryptographic algorithms, HMAC algorithms, and CMAC algorithms. In some examples, the symmetric algorithm used to process the divergence values ​​may include any symmetric cryptographic algorithm used as needed to generate a divergence symmetric key of the desired length. Non-restrictive examples of symmetric algorithms may include symmetric cryptographic algorithms such as the Triple Data Encryption Standard (3DES) or Advanced Encryption Standard 128 (AES128), symmetric HMAC algorithms such as HMAC-SHA-256, and symmetric CMAC algorithms such as AES-CMAC. If the output of the selected symmetric algorithm does not produce a key of sufficient length, it is understood that multiple outputs may be generated, which can be combined as needed to produce a key of sufficient length, by techniques such as processing multiple iterations of the symmetric algorithm with different input data and the same master key.

[0043] In block 212, the transmitting device 204 can obtain the selected cryptographic algorithm and process the counter value using the master symmetric key. For example, the sender can select a symmetric encryption algorithm and use a counter that is updated for each conversation between the transmitting device 204 and the receiving device 208. The transmitting device 204 can then use the master symmetric key to encrypt the counter value with the selected symmetric encryption algorithm and create a diversified symmetric key.

[0044] In some examples, the counter value does not need to be encrypted. In these examples, in block 212, the counter value may be transmitted between the transmitting device 204 and the receiving device 208 without encryption.

[0045] In block 214, the diversified symmetric key may be used to process sensitive data before sending the result to the receiving device 208. For example, the transmitting device 204 may encrypt sensitive data using a symmetric encryption algorithm that uses the diversified symmetric key, and the output will contain the protected encrypted data. The transmitting device 204 may then send the protected encrypted data, along with a counter value, to the receiving device 208 for processing.

[0046] In block 216, the receiving device 208 can first obtain a counter value, then use that counter value as input to the encryption and the master symmetric key as the encryption key to perform the same symmetric encryption. The output of the encryption may be the same diversified symmetric key value created by the sender.

[0047] In block 218, the receiving device 208 can acquire the protected encrypted data and decrypt it using a symmetric decryption algorithm along with a diversified symmetric key.

[0048] In block 220, the original confidential data may be revealed as a result of decrypting the protected encrypted data.

[0049] The next time confidential data needs to be sent from the sender to the receiver via the respective sending device 204 and receiving device 208, different counter values ​​may be selected to generate different diversified symmetric keys. By processing the counter values ​​using the master symmetric key and the same symmetric encryption algorithm, both the sending device 204 and receiving device 208 can independently generate the same diversified symmetric key. This diversified symmetric key, rather than the master symmetric key, is used to protect the confidential data.

[0050] As described above, both the transmitting device 204 and the receiving device 208 each initially possess a shared master symmetric key. The shared master symmetric key is not used to encrypt the original sensitive data. Since the diversified symmetric key is created independently by both the transmitting device 204 and the receiving device 208, it is not transmitted between them. Therefore, an attacker cannot intercept the diversified symmetric key, and an attacker never sees the data processed with the master symmetric key. Only counter values ​​are processed with the master symmetric key, and no sensitive data is processed. As a result, reduced side-channel data for the master symmetric key becomes apparent. Furthermore, the operation of the transmitting device 204 and the receiving device 208 may be governed by a symmetric requirement regarding the frequency of creating new diversified values, and therefore new diversified symmetric keys. In one embodiment, a new diversified value, and therefore a new diversified symmetric key, may be created with each exchange between the transmitting device 204 and the receiving device 208.

[0051] In some examples, the key diversification value may include a counter value. Other non-restrictive examples of key diversification values ​​include a random nonce generated each time a new diversification key is needed, a random nonce sent from the transmitting device 204 to the receiving device 208, the entire value of a counter sent from the transmitting device 204 and the receiving device 208, a portion of a counter value sent from the transmitting device 204 and the receiving device 208, a counter maintained independently by the transmitting device 204 and the receiving device 208 and not transmitted between the two devices, a one-time passcode exchanged between the transmitting device 204 and the receiving device 208, and a cryptographic hash of sensitive data. In some examples, one or more portions of the key diversification value may be used by the parties to create multiple diversification keys. For example, a counter can be used as the key diversification value. Furthermore, one or more combinations of the exemplary key diversification values ​​described above may be used.

[0052] In another example, a portion of the counter can be used as a key diversification value. If multiple master key values ​​are shared between the parties, multiple diversification key values ​​can be obtained by the systems and processes described herein. New diversification values, and therefore new diversification symmetric keys, can be created as frequently as needed. In the most secure case, a new diversification value may be created for each exchange of sensitive data between the transmitting device 204 and the receiving device 208. In practice, disposable keys, such as disposable session keys, can be created.

[0053] Figure 3 shows an exemplary configuration of a contactless card 102, which may include a contactless card or payment card, such as a credit card, debit card, or gift card, issued by a service provider as indicated by a service provider marking 302 on the front or back of the contactless card 102. In some examples, the contactless card 102 may include, but is not limited to, an identification card, and may not be related to a payment card. In some examples, the transaction card may include a dual-interface contactless payment card, a rewards card, etc. The contactless card 102 may include a substrate 308, which may include a single layer or one or more laminates comprising plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, titanium anodized oxide, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 102 may have physical characteristics conforming to the ID-1 format of the International Organization for Standardization / International Electrotechnical Commission 7816 (ISO / IEC 7816) standard, or the transaction card may conform to the ISO / IEC 14443 standard. However, the contactless card 102 according to this disclosure may have different characteristics, and it should be understood that this disclosure does not require the implementation of a transaction card in a payment card.

[0054] The contactless card 102 may also include identification information 306 displayed on the front and / or back of the card, and contact pads 304. The contact pads 304 may include one or more pads that can establish contact via the transaction card with other client devices, such as automated transaction machines (ATMs), user devices, smartphones, laptops, desktops, or tablet computers. The contact pads 304 may be designed in accordance with one or more standards, such as the ISO / IEC 7816 standard, and may enable communication in accordance with the EMV protocol. The contactless card 102 may also include processing circuits, antennas, and other components, as further described in Figure 4. These components may be located behind the contact pads 304 or elsewhere on the substrate 308, for example, in different layers of the substrate 308, and may be electrically and physically coupled to the contact pads 304. The contactless card 102 may also include magnetic strips or tapes, which may be located on the back of the card (not shown in Figure 3). The contactless card 102 may also include an NFC device coupled to an antenna that can communicate via the NFC protocol. Embodiments are not limited thereto.

[0055] As shown in Figure 4, the contact pads 304 of the contactless card 102 may include a processing circuit 416 for storing, processing, and communicating information, which includes a processor 402, memory 404, and one or more interfaces 406. It is understood that the processing circuit 416 may include additional components, as necessary to perform the functions described herein, including a processor, memory, error and parity / CRC check unit, data encoder, anti-collision algorithm, controller, command decoder, security primitive, and tamper-proof hardware.

[0056] Memory 404 may be read-only memory (ROM), write-once read-multiple memory, or read / write memory, such as random access memory (RAM), ROM, and electrically erasable programmable ROM (EEPROM), and the contactless card 102 may include one or more of these memories. ROM may be factory programmable as read-only or one-time programmable. One-time programmable provides multiple opportunities to read after a single write. Write-once read-multiple memory may be programmed after the memory chip leaves the factory. Once programmed, memory cannot be rewritten but can be read multiple times. Read / write memory can be programmed and reprogrammed multiple times after leaving the factory. Read / write memory can be read multiple times after leaving the factory. In some cases, memory 404 may be encrypted memory that utilizes an encryption algorithm executed by the processor 402 to encrypt the data.

[0057] Memory 404 may store one or more applets 408, one or more counters 410, a customer identifier 414, and an account number 412, which may be a virtual account number. One or more applets 408 may include one or more software applications that run on one or more contactless cards, such as a Java® card applet. However, it is understood that applet 408 is not limited to a Java card applet, but may instead be any software application that can run on a contactless card or other device with limited memory. One or more counters 410 may include numeric counters sufficient to store integers. The customer identifier 414 may include a unique alphanumeric identifier assigned to a user of a contactless card 102, and the customer identifier 414 can distinguish a user of a contactless card from other contactless card users. In some examples, the customer identifier 414 may identify both the customer and the account assigned to that customer, and may further identify the contactless card 102 associated with the customer's account. As described above, account number 412 may contain thousands of disposable virtual account numbers associated with contactless card 102. Applet 408 of contactless card 102 may manage account number 412 (for example, by selecting account number 412, marking the selected account number 412 as used, and sending account number 412 to a mobile device for autofill by an autofill service).

[0058] The elements of the processor 402 and memory 404 in the exemplary embodiments described above are described with reference to the contact pad 304, but the disclosure is not limited thereto. It is understood that these elements may be mounted outside the contact pad 304, or completely separate from the contact pad 304, or may be mounted as additional elements in addition to the elements of the processor 402 and memory 404 located within the contact pad 304.

[0059] In some examples, the contactless card 102 may include one or more antennas 418. One or more antennas 418 may be arranged within the contactless card 102, around the processing circuit 416 of the contact pads 304. For example, one or more antennas 418 may be integrated with the processing circuit 416, or one or more antennas 418 may be used with an external booster coil. In another example, one or more antennas 418 may be located outside the contact pads 304 and the processing circuit 416.

[0060] In one embodiment, the coil of the contactless card 102 may function as the secondary of an air-core transformer. A terminal may communicate with the contactless card 102 by disconnected power or amplitude modulation. The contactless card 102 may infer data transmitted from the terminal using a gap in the contactless card's power connection, which can be functionally maintained through one or more capacitors. The contactless card 102 may return communication by switching the load or load modulation of the contactless card's coil. The load modulation may be detected by interference in the terminal's coil. More generally, using an antenna 418, a processor 402, and / or memory 404, the contactless card 102 provides a communication interface for communicating via NFC, Bluetooth, and / or Wi-Fi communication.

[0061] As described above, the contactless card 102 can be built on a software platform that can run on other devices with limited memory, such as a smart card or JavaCard, and can securely run one or more applications or applets. The applet 408 can be added to the contactless card to provide a one-time password (OTP) for multi-factor authentication (MFA) in various mobile app-based use cases. The applet 408 may respond to one or more requests, such as a Near Field Wireless Data Exchange request from a reader (e.g., a mobile NFC reader such as a mobile device or point-of-sale terminal), and generate an NFC Data Exchange Format (NDEF) message, which includes a cryptographically secure OTP encoded as an NDEF text tag.

[0062] An example of an NDEF OTP is the NDEF short record layout (SR=1). In such an example, one or more applet 408 may encode the OTP as a well-known type of text tag of NDEF type 4. In some examples, an NDEF message may contain one or more records. Applet 408 may add one or more static tag records in addition to the OTP records.

[0063] In some examples, one or more applet 408 may emulate an RFID tag. The RFID tag may include one or more polymorphic tags. In some examples, each time the tag is read, different encrypted data is presented that can indicate the authenticity of the contactless card. Based on one or more applet 408, the NFC reading of the tag can be processed and the data can be sent to a server, for example, a server in a banking system, where the data can be verified.

[0064] In some examples, the contactless card 102 and the server may contain certain data so that the card can be properly identified. The contactless card 102 may contain one or more unique identifiers (not shown). Each time a read operation is performed, the counter 410 may be incremented. In some examples, each time data is read from the contactless card 102 (e.g., by a mobile device), the counter 410 is sent to the server for verification to determine whether the counter 410 is equal to the server's counter (as part of the verification).

[0065] One or more counters 410 may prevent replay attacks. For example, if an encryption key is captured and replayed, the key is immediately rejected if counter 410 is read, used, or otherwise passed. If counter 410 is not used, the key can be replayed. In some examples, a counter incremented on a card is different from a counter incremented for a transaction. The contactless card 102 cannot determine the application transaction counter 410 because there is no communication between the applets 408 on the contactless card 102.

[0066] In some cases, counter 410 may become out of sync. In some cases, counter 410 may increment to account for accidental reads that initiate a transaction, such as reads at a certain angle, but the application does not process counter 410. In some cases, when mobile device 104 is woken up, NFC may be enabled and device 104 may read available tags, but no action is taken in response to the read.

[0067] To keep counter 410 synchronized, an application such as a background application may be run that detects when the mobile device 104 wakes up and increments counter 410 in synchronization with a banking system server indicating the reads made by the detection. In other examples, a hashed one-time password may be used so that a window of missynchronization is acceptable. For example, counter 410 may increment if it is within a threshold of 10. However, if it is within a different threshold, e.g., within 10 or within 1000, a request to perform resynchronization may be processed, which is requested through one or more applications, such as by the user tapping, gesture, or otherwise instructing through the user's device once or multiple times. If counter 410 increments in the appropriate sequence, it can be known that the user has done so.

[0068] The key diversification techniques described herein with reference to counter 410, the master key, and the diversification key are examples of encryption and / or decryption in key diversification techniques. This exemplary key diversification technique should not be considered limiting to this disclosure, as this disclosure is equally applicable to other types of key diversification techniques.

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

[0070] In some cases, to overcome the shortcomings of the vulnerability-prone 3DES algorithm, session keys may be derived (such as a unique key per session), but instead of using a master key, a unique card derivation key and counters can be used as diversification data. For example, each time a contactless card 102 is used in operation, a different key may be used to generate and encrypt the message authentication code (MAC). This results in three layers of encryption. Session keys can be generated by one or more applets and derived using application transaction counters with one or more algorithms (as defined in EMV4.3 Book2 A1.3.1 Common Session Key Derivation).

[0071] Furthermore, the increment for each card may be unique, assigned by personalization, or algorithmically assigned by some identifying information. For example, odd-numbered cards may be incremented by 2, and even-numbered cards may be incremented by 5. In some examples, the increment may also vary in consecutive readings; for example, a card may be incremented in a repeating sequence of 1, 3, 5, 2, 2, ... A particular sequence or algorithmic sequence may be defined during personalization or from one or more processes derived from a unique identifier. This makes it more difficult for a replay attacker to generalize from a small number of card examples.

[0072] The authentication message may be delivered as the content of a text NDEF record in hexadecimal American Standard Code for Information Interchange (ASCII) format. In another example, the NDEF record may be encoded in hexadecimal format.

[0073] Figure 5 is a timing diagram showing an exemplary sequence for providing authenticated access according to one or more embodiments of the present disclosure. The sequence flow 500 may include a contactless card 102 and a client device 104, the client device 104 may include an application 502 and a processor 504.

[0074] On line 508, application 502 communicates with contactless card 102 (for example, after bringing it close to contactless card 102). Communication between application 502 and contactless card 102 may include contactless card 102 being close enough to the card reader (not shown) of client device 104 to enable NFC data transfer between application 502 and contactless card 102.

[0075] After communication is established between the client device 104 and the contactless card 102 on line 506, the contactless card 102 generates a MAC cipher. In some examples, this may occur when the contactless card 102 is read by application 502. In particular, this may occur during a read, such as an NFC read of an NDEF tag. For example, a reader application such as application 502 may send a message, such as an applet selection message, along with the applet ID of the NDEF generation applet. Upon confirmation of the selection, a sequence of selected file messages followed by read file messages may be sent. For example, the sequence may include "Select capability file", "Read capability file", and "Select NDEF file". At this point, a counter value maintained by the contactless card 102 may be updated or incremented, followed by "Read NDEF file". At this point, a message may be generated that may include a header and a shared secret. Subsequently, a session key may be generated. A MAC cipher may be created from the message, which may include a header and a shared secret. The MAC cipher may then be concatenated with one or more blocks of random data, and the MAC cipher and random numbers (RND) may be encrypted with a session key. The cipher and header may then be concatenated, encoded as ASCII hex, and returned in NDEF message format (in response to the "Read NDEF file" message).

[0076] In some examples, the MAC cipher may be transmitted as an NDEF tag, and in other examples, the MAC cipher may be included with a uniform resource indicator (e.g., as a formatted string). In some examples, application 502 may send a request to contactless card 102, the request including an instruction to generate the MAC cipher.

[0077] On line 510, the contactless card 102 transmits the MAC encryption to application 502. In some embodiments, the transmission of the MAC encryption is performed via NFC, but this disclosure is not limited thereto. In other embodiments, this communication may be performed via Bluetooth, Wi-Fi, or other wireless data communication means. On line 512, application 502 communicates the MAC encryption to processor 504.

[0078] At line 514, processor 504 verifies the MAC cipher according to instructions from application 502. For example, the MAC cipher may be verified as described below. In some examples, the verification of the MAC cipher may be performed by a device other than client device 104, such as a server in a banking system that communicates data with client device 104. For example, processor 504 may output the MAC cipher to send to a server in a banking system that can verify the MAC cipher. In some examples, the MAC cipher may serve as a digital signature for verification. This verification may be performed using other digital signature algorithms, such as public-key asymmetric algorithms, e.g., digital signature algorithms and Rivest-Shamir-Adelman (RSA) algorithms, or zero-knowledge protocols.

[0079] Figure 6 shows an NDEF short record layout (SR=1) data structure 600 according to an exemplary embodiment. One or more applets may encode OTPs as text tags of a well-known type of NDEF type 4. In some examples, an NDEF message may include one or more records. In addition to OTP records, the applet may add one or more static tag records. Exemplary tags include, but are not limited to: Tag type: well-known type, text, encoded in English (en); Applet ID: D2760000850101; Function: read-only access; Encoding: Authentication messages may be encoded as ASCII hex; Type-length-value (TLV) data may be provided as personalization parameters that can be used to generate an NDEF message. In one embodiment, an authentication template may include a first record having a well-known index that provides actual dynamic authentication data.

[0080] Figure 7 shows a system 700 that implements one or more embodiments of the present disclosure. As described below, two cryptographic keys can be uniquely assigned to each card during the contactless card creation process. The cryptographic keys may include symmetric keys that can be used for both encryption and decryption of data. The 3DES algorithm may be used by EMV and implemented by hardware within the contactless card. By using a key diversification process, one or more keys can be derived from a master key based on uniquely identifiable information of each entity that requires a key.

[0081] With regard to master key management, two issuer master keys 702,726 may be required for each portion of the portfolio in which one or more applets are issued. For example, the first master key 702 may contain the issuer cryptographic generation / authentication key (Iss-Key-Auth), and the second master key 726 may contain the issuer data encryption key (Iss-Key-DEK). As further described herein, the two issuer master keys 702,726 are diversified into card master keys 708,720, unique for each card. In some examples, a network profile record ID (pNPR) 722 and a derived key index (pDKI) 724 can be used as back-office data to identify which issuer master key 702,726 to use in the cryptographic process of authentication. The system performing authentication may obtain the values ​​of the pNPR 722 and pDKI 724 of the contactless card at the time of authentication.

[0082] In some examples, session keys may be derived to enhance the security of the solution (e.g., a unique key per session), but as mentioned above, instead of using a master key, a unique card-derived key and counter can be used as diversification data. For example, a different key may be used each time the card is used in operation to generate and encrypt the message authentication code (MAC). With regard to session key generation, the key used to generate cryptography and encrypt data within one or more applets may include a session key based on card-specific keys (Card-Key-Auth708 and Card-Key-Dek720). The session key (Aut-Session-Key732 and data encryption key (DEK-Session-Key710)) may be generated by one or more applets and derived by using an application transaction counter (pATC)704 along with one or more algorithms. Only the two lower bytes of the 4-byte pATC704 are used to fit the data to one or more algorithms. In some examples, a 4-byte session key derivation method can include F1:=PATC(lower 2 bytes)||'F0'||'00'||PATC(4 bytes)F1:=PATC(lower 2 bytes)||'0F'||'00'||PATC(4 bytes)SK:={(ALG(MK)[F1])||ALG(MK)[F2]}, where ALG can contain the 3DES Electronic Codebook (ECB) and MK can contain the card-specific derived master key.

[0083] As described herein, one or more MAC session keys may be derived using the lower two bytes of pATC704. With each tap of the contactless card, pATC704 is updated, and the card master keys Card-Key-AUTH708 and Card-Key-DEK720 are further diversified into session keys Aut-Session-Key732 and DEK-Session-KEY710. pATC704 may be initialized to 0 during personalization or applet initialization. In some examples, pATC704 may be initialized during or before personalization, and may be incremented by 1 with each NDEF read.

[0084] Furthermore, each card update may be unique, assigned by personalization, or algorithmically assigned by a pUID or other identifying information. For example, odd-numbered cards may be incremented or decremented by 2, and even-numbered cards may be incremented or decremented by 5. In some examples, the updates may also vary in consecutive reads; for example, a card may be incremented in a repeating sequence of 1, 3, 5, 2, 2, ... A particular sequence or algorithmic sequence may be defined during personalization or from one or more processes derived from a unique identifier. This makes it more difficult for a replay attacker to generalize from a small number of card examples.

[0085] The authentication message may be delivered as the content of a text NDEF record in hexadecimal ASCII format. In some examples, it may contain only the authentication data and an 8-byte random number preceding the MAC of the authentication data. In some examples, the random number may precede the cipher A and may be 1 block long. In other examples, there may be no restriction on the length of the random number. In further examples, the total data (i.e., random number plus cipher) may be a multiple of the block size. In these examples, an additional 8-byte block may be added to match the block generated by the MAC algorithm. As another example, if the algorithm used uses 16-byte blocks, it may be a multiple of that block size, or the output may be automatically or manually padded to a multiple of that block size.

[0086] MAC may be performed using a function key (AUT-Session-Key) 732. The encrypted data may be processed with javacard.signature method:ALG_DES_MAC8_ISO9797_1_M2_ALG3 and associated with the EMV Authorization Request Cryptogram (ARQC) verification method. The key used in this calculation may include the session key AUT-Session-Key 732, as described above. As mentioned above, the lower two bytes of the counter can be used to diversify one or more MAC session keys. As described below, MAC data 706 may be encrypted using AUT-Session-Key 732, and the resulting data or cipher A 714 and random number RND may be encrypted using DEK-Session-Key 710 to create cipher B, or 718 which is sent in the message may be output.

[0087] In some examples, one or more hardware security module (HSM) commands may be processed for decryption, and the final 16 (binary, 32hex) bytes may include 3DES symmetric encryption using a cipher block chaining (CBC) scheme with a random zero IV followed by MAC authentication data. The key used for this encryption may include the session key DEK-Session-Key 710 derived from Card-Key-DEK720. In this case, the ATC value of the session key derivation is the least significant byte of pATC704.

[0088] The following format represents an exemplary embodiment of the binary version. Furthermore, in some examples, the first byte may be set to the ASCII character "A".

[0089] [Table 1]

[0090] [Table 2]

[0091] Another exemplary format is shown below. In this example, the tags may be encoded in hexadecimal format.

[0092] [Table 3]

[0093] [Table 4]

[0094] The unique identifier (UID) field of the received message may be extracted, and the card master key (Card-Key-Auth708 and Card-Key-DEK720) for that particular card may be derived from the master keys Iss-Key-AUTH702 and Iss-Key-DEK726. Using the card master key (Card-Key-Auth708 and Card-Key-DEK720), the session key (Aut-Session-Key732 and DEK-Session-Key710) for that particular card may be derived using the counter (pATC) field of the received message. Cipher B 718 may be decrypted using the DEK-Session-KEY to generate cipher A 714 and RND, which may be discarded. The UID field may be used to retrieve the shared secret of a contactless card and, along with the Ver, UID, and pATC fields of the message, may be processed via cipher MAC using the recreated Aut-Session-Key to produce a MAC output, e.g., MAC'. If the MAC is the same as the cipher A 714, this indicates that message decryption and MAC checks have all passed. Then the pATC can be read to determine if it is valid.

[0095] During an authentication session, one or more ciphers may be generated by one or more applications. For example, one or more ciphers may be generated as a 3DES MAC using the ISO9797-1 algorithm 3, via one or more session keys such as Aut-Session-Key732, with padding from Method 2. The input data 706 can take the form of version(2), pUID(8), pATC(4), and shared secret(4). In some examples, the numbers in parentheses may include the length in bytes. In some examples, the shared secret may be generated by one or more random number generators that can ensure the random numbers are unpredictable via one or more secure processes. In some examples, the shared secret may include a random 4-byte binary number introduced into the card at a personalization time known by the authentication service. During an authentication session, the shared secret does not have to be provided to the mobile application from one or more applets. Padding from Method 2 may include adding a required 0x'80' byte to the end of the input data and adding a 0x'00' byte that may be added to the end of the resulting data up to an 8-byte boundary. The resulting encrypted code may have a length of 8 bytes.

[0096] In some examples, one advantage of using MAC encryption to encrypt non-shared random numbers as the first block is that it acts as an initialization vector while using the CBC mode of the symmetric encryption algorithm. This allows for "scrambling" between blocks without the need to pre-establish either a fixed or dynamic IV.

[0097] By including an Application Transaction Counter (pATC) as part of the data contained in the MAC encryption, the authentication service can determine whether the value transmitted in plaintext data has been tampered with. Furthermore, by including a version in one or more ciphers, it is difficult for an attacker to intentionally falsify the application version in an attempt to weaken the strength of the cryptographic solution. In some examples, the pATC may start at zero and be updated by one each time one or more applications generate authentication data. The authentication service can track the pATC used during an authentication session. In some examples, if the authentication data uses a pATC less than or equal to a previous value received by the authentication service, this may be interpreted as an attempt to replay an old message, and authentication may be rejected. In some examples, if the pATC is greater than a previous value received, this may be evaluated to determine whether it is within an acceptable range or threshold, and if it exceeds or falls outside the range or threshold, the verification may be considered to have failed or to be unreliable. In MAC operation 712, data 706 is processed via MAC using the Auto-Session-Key 732 to produce an encrypted MAC output (cipher A) 714.

[0098] To provide additional protection against brute-force attacks that expose the key on the card, it is desirable that cipher A 714 be encrypted. In some examples, the data or cipher A 714 contained in the ciphertext may include random(8), cipher(8). In some examples, the numbers in parentheses may include the length in bytes. In some examples, the random numbers may be generated by one or more random number generators that can ensure the random numbers are unpredictable through one or more secure processes. The key used to encrypt this data may include a session key. For example, the session key may include DEK-Session-Key710. In the cryptographic operation 716, the data or cipher A 714 and RND are processed using DEK-Session-Key710 to produce cipher B 718, which is the encrypted data. Cipher A 714 may be encrypted using 3DES in CBC mode to ensure that an attacker must perform any attack on the entire ciphertext. As a non-restrictive example, other algorithms such as the Advanced Encryption Standard (AES) may be used. In some examples, an initialization vector of 0x'0000000000000000' may be used. An attacker attempting to brute-force the key used to encrypt this data would be unable to determine when the correct key was used because correctly decrypted data is indistinguishable from incorrectly decrypted data due to its random appearance.

[0099] For the authentication service to verify one or more ciphers provided by one or more applets, the following data must be transmitted in plain text from one or more applets to the mobile device during the authentication session: a version number that determines the cryptographic method used, and a message format for verifying the cipher (this allows for future changes to the method); a pUID that retrieves the crypto asset and derives the card key; and a pATC that derives the session key used for the cipher.

[0100] Figure 8 shows a method 800 for generating cryptography. For example, in block 802, the Network Profile Record ID (pNPR) and Derived Key Index (pDKI) may be used to identify which issuer master key to use in the authentication encryption process. In some examples, the method may include performing authentication to obtain the pNPR and pDKI values ​​of the contactless card at the time of authentication.

[0101] In block 804, issuer master keys can be diversified by combining them with the card's unique ID number (pUID) and the PAN sequence number (PSN) of one or more applets, such as a payment applet.

[0102] In block 806, a Card-Key-Auth and Card-Key-DEK (unique card key) may be created by diversifying the issuer master key, and a session key may be generated that can be used to generate MAC encryption.

[0103] In block 808, the key used to generate ciphers and encrypt data within one or more applets may include the session key in block 806, based on card-specific keys (Card-Key-Auth and Card-Key-DEK). In some examples, these session keys may be generated by one or more applets and derived using pATC, resulting in the session keys Aut-Session-Key and DEK-Session-Key.

[0104] Figure 9 shows an exemplary process 900 illustrating key diversification by example. Initially, the sender and receiver may be provisioned with two different master keys. For example, the first master key may include a data encryption master key, and the second master key may include a data integrity master key. The sender has a counter value that can be updated in block 902, and other data to be protected, such as data to be protected, which can be protected from sharing with the receiver.

[0105] In block 904, the sender may encrypt the counter value using the data encryption master key to generate a data encryption derived session key, or the sender may encrypt the counter value using the data integrity master key to generate a data integrity derived session key. In some examples, the entire counter value or a portion of the counter value can be used during both encryptions.

[0106] In some examples, the counter value does not need to be encrypted. In these examples, the counter can be sent between the sender and receiver in plain text, i.e., without encryption.

[0107] In block 906, the data to be protected is processed in cryptographic MAC operation by the sender using a data integrity session key and a cryptographic MAC algorithm. The protected data, including the plaintext and shared secret, may be used to generate the MAC using one of the session keys (AUT-Session-Key).

[0108] In block 908, the data to be protected may be encrypted by the sender using a data encryption derived session key along with a symmetric encryption algorithm. In some examples, the MAC is combined with equal amounts of random data, e.g., each 8 bytes long, and then encrypted using a second session key (DEK-Session-Key).

[0109] In block 910, the encrypted MAC is sent from the sender to the receiver along with enough information to identify additional secrets (e.g., shared secret, master key, etc.) in order to verify the encryption.

[0110] In block 912, the receiver uses the received counter value, as described above, to independently derive two derived session keys from the two master keys.

[0111] In block 914, the data encryption derived session key is used in conjunction with the symmetric decryption operation to decrypt the protected data. Further processing is then performed on the exchanged data. In some examples, it is desirable to reconstruct and verify the MAC after it has been extracted. For example, when verifying the encryption, decryption may be performed using a appropriately generated session key. The protected data may be reconstructed for verification. A MAC operation can be performed using a properly generated session key to determine if it matches the decrypted MAC. Since the MAC operation is an irreversible process, the only way to verify it is to attempt to recreate it from the source data.

[0112] In block 916, the data integrity derivation session key is used in conjunction with the cryptographic MAC operation to verify that the protected data has not been altered.

[0113] Some examples of the methods described herein can favorably confirm when authentication success is determined when the following conditions are met: Firstly, the ability to verify the MAC indicates that the derived session key was appropriate. The MAC may only be correct if decryption is successful and an appropriate MAC value is obtained. Successful decryption may indicate that the correctly derived cryptographic key was used to decrypt the encrypted MAC. Since the derived session key is created using a master key known only to the sender (e.g., the sending device) and receiver (e.g., the receiving device), it can be trusted that the contactless card that initially created and encrypted the MAC is indeed genuine. Furthermore, the counter values ​​used to derive the first and second session keys may be shown to be valid and may be used to perform the authentication operation.

[0114] Subsequently, the two derived session keys may be discarded, the counter value may be updated in the next iteration of data exchange (returning to block 902), and a new set of session keys may be created (block 910). In some examples, the combined random data may be discarded.

[0115] Figure 10 shows a card activation method 800 according to an exemplary embodiment. For example, card activation may be completed by a system including a card, a device, and one or more servers. The contactless card, device, and one or more servers may refer to the same or similar components described previously, such as the contactless card 102, client device 104, and server.

[0116] In block 1002, the card may dynamically generate data. In some examples, this data may include information such as an account number, card identifier, card verification value, or telephone number that can be transmitted from the card to the device. In some examples, one or more portions of the data may be encrypted via systems and methods disclosed herein.

[0117] In block 1004, one or more portions of dynamically generated data can be communicated to the device's application via NFC or other wireless communication. For example, by tapping the card in close proximity to the device, the device's application may be able to read one or more portions of the data associated with the contactless card. In some examples, if the device does not have an application to help activate the card, tapping the card may lead the device to a software application store or prompt the customer to download the relevant application to activate the card. In some examples, the user may be prompted to sufficiently gesture, position, or orient the card toward the surface of the device, for example, on, near, or close to the surface of the device, at a certain angle or flat. In response to the sufficient gesture, position, and / or orientation of the card, the device may proceed to send one or more encrypted portions of the data received from the card to one or more servers.

[0118] In block 1006, one or more portions of the data can be communicated to one or more servers, such as a card issuer server. For example, one or more encrypted portions of the data may be sent from the device to the card issuer server for card activation.

[0119] In block 1008, one or more servers can decrypt one or more encrypted portions of data via the systems and methods disclosed herein. For example, one or more servers can receive encrypted data from a device and decrypt it in order to compare the received data with recorded data accessible to one or more servers. If the comparison of one or more decrypted portions of data by one or more servers results in a successful match, the card may be activated. If the comparison of one or more decrypted portions of data by one or more servers results in a failure to find a match, one or more actions may be taken. For example, in response to a failure to find a match, the user may be prompted to tap, swipe, or wave the card again. In this case, there may be a predetermined threshold, including the number of attempts the user is allowed to activate the card. Alternatively, the user may receive a message on their device indicating that the card verification attempt failed, and a notification such as calling, emailing, or texting the relevant service to help activate the card; another notification such as a phone call to their device indicating that the card verification attempt failed, and a notification such as calling, emailing, or texting the relevant service to help activate the card; or an email indicating that the card verification attempt failed, and another notification such as calling, emailing, or texting the relevant service to help activate the card.

[0120] In block 1010, one or more servers may send a return message based on the successful activation of the card. For example, a device may receive output from one or more servers indicating that the card has been successfully activated by one or more servers. The device may display a message indicating that the card has been successfully activated. Once the card is activated, it may stop dynamically generating data to prevent fraudulent use. In this way, the card is not activated again, and one or more servers are notified that the card has already been activated.

[0121] Figures 1 to 10 generally illustrate systems and methods for authenticating a contactless card based on information about the contactless card. However, as previously stated, some embodiments disclosed herein may include systems and methods for launching a mobile application or browser extension in response to the fulfillment of certain conditions. For example, a contactless card may be registered with a mobile device. A contactless card may also be registered with a shopping mobile application and / or a shopping browser extension, such as Capital One Shopping. When a mobile device is used for shopping via a merchant application, the mobile device may receive a cryptographic message from the contactless card, verify the message, i.e., authenticate the contactless card, and launch the shopping mobile application and / or shopping browser extension when the message is verified. In this context, launching may include opening and running the shopping mobile application and / or shopping browser extension on the mobile device. Certain conditions that can be fulfilled may include a merchant application running on the mobile device, a mobile device receiving a cryptographic message from a contactless card, a contactless card registered with the mobile device, a contactless card registered with the shopping mobile application and / or shopping browser extension, and a mobile device verifying the message. Figures 11 to 14 generally cover these embodiments and provide further details.

[0122] Figure 11 is a block diagram showing an example of a mobile device 1102 according to the disclosure. It should be understood that the mobile device 1102 may be the same as or similar to the client device 104.

[0123] As shown in the figure, the mobile device 1102 may include an interface 1104, memory 1106, a processor 1112, and a display device 1114. The memory 1106 can store computer instructions to be executed by the processor 1112, and these computer instructions may be part of an application 1108 and / or an operating system 1110. However, embodiments are not limited to this.

[0124] In some embodiments, interface 1104 may include one or more antennas, such as a near-field communication antenna, a camera, a scanner, or another device capable of reading information or data within its field of view. Additionally or alternatively, interface 1104 may include a Wi-Fi interface, a Bluetooth interface, an NFC interface, a serial bus interface, a Universal Serial Bus (USB), and the like.

[0125] In some embodiments, memory 1106 can be any type of memory that stores instructions processed by processor 1112. Examples of memory 1106 may include volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, and the like.

[0126] In some embodiments, the processor 1112 may be any type of processor, microprocessor, circuit, circuit element (e.g., transistor, resistor, capacitor, inductor, etc.), integrated circuit, application-specific integrated circuit (ASIC), programmable logic device (PLD), digital signal processor (DSP), field-programmable gate array (FPGA), multicore processor, etc.

[0127] In some embodiments, the display device 1114 may include a display screen or other output device that displays data, information, and / or graphics to the user of the mobile device 1102.

[0128] As described above, memory 1106 may include application 1108 and / or operating system 1110. Application 1108 may include any type of application that runs on mobile device 1102. For example, application 1108 may include social networking applications, communication applications, business productivity applications (e.g., email, word processor, spreadsheet, etc.), in-store applications, banking applications, money transfer applications, game applications, etc. Particularly relevant to some embodiments disclosed herein, application 1108 may include merchant applications and shopping mobile applications.

[0129] Application 1108 can run within the operating system 1110. In some embodiments, the operating system 1110 may be the Android® operating system, the Apple iOS® operating system, the Windows Mobile Operating System®, etc. The operating system 1110 can provide services and instructions that enable Application 1108 to run and operate on hardware. For example, the operating system 1110 can work with the hardware associated with the processor 1112 to process detections made by interface 1104. In some embodiments, the operating system 1110 can provide data to Application 1108 which is processed by the operating system 1110. Application 1108 can process such data, including performing authentication of the data and communicating the data to other devices or servers. In some embodiments, at least a portion of the operating system 1110 can perform one or more authentication steps. Furthermore, it can be understood that at least a portion of the operating system 1110 and / or at least one of Application 1108 retrieve information such as merchant information, payment information, and / or cart information from other parts of Application 1108.

[0130] Figure 12 is a block diagram showing an example of a system 1200 according to an embodiment of the disclosure. As shown, the system 1200 may include a mobile device 1202 and a contactless card 1204. It should be understood that the mobile device 1202 may be the same as or similar to the mobile device 1102 and / or client device 104. It should also be understood that the contactless card 1204 may be the same as or similar to the contactless card 102. The contactless card 1204 can be registered with the mobile device 1202, and the contactless card 1204 can also be registered with a shopping mobile application and / or a shopping browser extension.

[0131] In some embodiments, a user can provide input by tapping a contactless card 1204 on a mobile device 1202 or by bringing the contactless card 1204 within the communication range of the mobile device 1202. For example, when tapped on or within the communication range of the mobile device 1202, the mobile device 1202 can read information or data from the contactless card 1204, and / or the contactless card 1204 can transmit such information or data to the mobile device 1202. In some embodiments, the mobile device 1202 can request or solicit information or data from the contactless card 1204, for example by displaying a request on the display screen of the mobile device 1202.

[0132] During operation, the mobile device 1202 can process data received as input from the contactless card 1204, including authentication data and / or signal and communication data, and use such data to authenticate the contactless card 1204 and / or verify data received from the mobile device 1202. For example, in some embodiments, the authentication data may include encryption from the contactless card 1204, and the mobile device 1202 may successfully decrypt the encryption to verify it. Additionally or alternatively, in some embodiments, the mobile device 1202 may decrypt protected data within the encryption and compare the protected data with recorded data stored in a server associated with the contactless card 1204 and communicating with the mobile device 1202 and / or the mobile device 1202. If the protected data matches the recorded data, the mobile device 1202 can verify the customer associated with the contactless card 1204. In some embodiments, the mobile device 1202 may send the data received as input and / or authentication data to the server for verification, for example, as shown in Figures 1 to 10.

[0133] In some embodiments, it should be understood that data received as input from the contactless card 1204 will not be authenticated and / or verified unless the contactless card 1204 is registered with the mobile device 1202 and / or the shopping mobile application and / or the shopping browser extension. In this regard, without such registration, the mobile device 1202 and / or the server may be unable to decrypt the encrypted and / or protected data within the encrypted data, for example, due to the lack of necessary keys. Additionally or alternatively, without such registration, the mobile device 1202 and / or the server may be able to decrypt the encrypted and / or protected data within the encrypted data, but may be unable to match the protected data with any recorded data stored for the registered card. In this regard, if registered, the contactless card 1204 can be associated with the mobile device 1202, the shopping mobile application and / or the shopping browser extension in a database or data store maintained by the server. Therefore, the mobile device 1202 can provide the server with data received as input from the contactless card 1204, as well as identification data such as identifiers for the mobile device, the shopping mobile application, and / or the shopping browser extension, and the server can use such received information to verify that the contactless card 1204 is associated with the mobile device 1202, the shopping mobile application, and / or the shopping browser extension.

[0134] In some embodiments, in response to the authentication of the contactless card 1204, the mobile device 1202 can initiate an action on the mobile device 1202. For example, in some embodiments, the mobile device 1202 can launch a shopping mobile application and / or a shopping browser extension. In some embodiments, the shopping mobile application and / or a shopping browser extension can automatically apply available coupons to items in the cart associated with the merchant application running on the mobile device 1202. For example, the shopping mobile application and / or a shopping browser extension can retrieve information identifying the items in the cart from the merchant application, search a database or the internet for available coupons associated with the items in the cart, identify the available coupons associated with the items in the cart, and push the available coupons associated with the items in the cart to the shopping merchant application for their application. Additionally or alternatively, in some embodiments, the shopping mobile application and / or a shopping browser extension can automatically search for better prices for the items in the cart associated with the merchant application and display the better prices found on alternative websites on the mobile device's display screen. For example, a shopping mobile application and / or shopping browser extension can retrieve information identifying items in the cart from the merchant application, search multiple alternative websites, identify a better price for the items in the cart on one of the alternative websites, and display the better price and identification from one of the alternative websites.

[0135] In some embodiments, the data received as input from the contactless card 1204 may include instructions to access a shopping mobile application and / or a shopping browser extension, such as a uniform resource locator (URL) to visit and / or download the shopping mobile application and / or shopping browser extension.

[0136] Figure 13 is a flowchart illustrating an example of Method 1300 according to the disclosure. In some embodiments, mobile devices such as mobile device 1202, mobile device 1102, and / or client device 104 can perform some or all of Method 1300. Additionally or alternatively, a server communicating with a mobile device can perform some or all of Method 1300.

[0137] As illustrated, method 1300 may include the step of receiving encryption from a contactless card, as in 1302. For example, in some embodiments, a mobile device's near-field communication antenna may receive encryption from a contactless card. In some embodiments, a mobile device may receive encryption in response to a request to communicate with a contactless card displayed on the mobile device's display screen. For example, in some embodiments, a mobile device may display a request for communication in response to a display screen of the mobile device showing a payment screen associated with a merchant application. Additionally or alternatively, in some embodiments, a request for communication may be displayed in response to an item placed in a shopping cart associated with a merchant application.

[0138] After receiving the cipher from the contactless card, method 1300 may include a step of verifying the cipher, as in 1304. For example, in some embodiments, the processor of the mobile device may verify the cipher. Additionally or alternatively, in some embodiments, the mobile device may send the cipher to a server and receive an instruction from the server that the cipher has been verified.

[0139] In some embodiments, a mobile device and / or server may successfully decrypt the cipher to verify it. Additionally or alternatively, in some embodiments, the mobile device and / or server may decrypt the protected data within the cipher and compare the protected data with record data associated with the contactless card and stored in the mobile device and / or server. If the protected data matches the record data, the mobile device and / or server may verify the customer associated with the contactless card. In this regard, it should be understood that verifying the cipher, the contactless card, and / or the customer associated with the contactless card may include and incorporate systems and methods for authenticating a contactless card based on information about the contactless card disclosed and described herein.

[0140] If the encryption is verified and the merchant application is running on the mobile device, method 1300 may include the step of launching the shopping mobile application and / or shopping browser extension on the mobile device. In some embodiments, the shopping mobile application and / or shopping browser extension may automatically apply available coupons to items in the cart associated with the first mobile application. Additionally or alternatively, in some embodiments, the shopping mobile application and / or shopping browser extension may automatically search for better prices for items in the cart associated with the merchant application, and the mobile device's display screen may show the better prices found on the alternative website. In this regard, it should be understood that the mobile device, and several applications running on it, including the shopping mobile application and / or shopping browser extension, may retrieve information such as merchant information, payment information, and / or cart information from other applications running on the mobile device, including the merchant application.

[0141] Figure 14 shows an example of a sequence flow 1400 according to the disclosure. In some embodiments, verification and / or authentication can be performed by a mobile device 1404. Additionally or alternatively, in some embodiments, verification and / or authentication can be performed by a server 1406.

[0142] In 1408, the contactless card 1402 can be tapped or brought into the communication range of the mobile device 1404 and can exchange information with the mobile device 1404. Line 1408 can represent communication between the contactless card 1402 and the mobile device 1404, and the communication may include authentication data, such as cryptographic data, stored in the contactless card 1402 and provided to the mobile device 1404. In some embodiments, the authentication data may be encrypted cryptographically and may be encrypted using systems and methods disclosed and described herein, for example, as described in Figures 1 to 10.

[0143] In some embodiments, communication between the contactless card 1402 and the mobile device 1404 may include NFC communication using one or more NFC protocols. However, embodiments disclosed herein are not limited thereto and may include other wireless technologies in addition to NFC, or as alternatives to NFC, such as other short-range communication protocols.

[0144] In 1410, the mobile device 1404 can process authentication data and any other data received from the contactless card 1402. For example, in some embodiments, the mobile device 1404 can verify the cipher received from the contactless card 1402. Additionally or alternatively, the mobile device 1404 can operate as a pass-through and send the authentication data and / or cipher to the server 1406 for verification and / or authentication.

[0145] In 1412, the mobile device 1404 can transmit information to the server 1406. For example, in some embodiments, the mobile device 1404 can transmit information received from the contactless card 1402 to the server 1406 as it was received. However, in some embodiments, the mobile device 1404 can partially or completely process the information received from the contactless card 1402 and transmit the information received from the contactless card 1402 to the server 1406 as processed, for example, partially or completely decrypted protected data or key. Additionally or alternatively, in some embodiments, the mobile device 1404 can transmit an information request to the server 1406 requesting data stored in the server 1406, such as record data, for comparison with authentication data in the information received from the contactless card 1402. In some embodiments, the mobile device 1404 can store record data for comparison with protected data.

[0146] The mobile device 1404 can transmit information to the server 1406 via one or more wireless and / or wired connections. For example, in some embodiments, the mobile device 1404 can transmit information to one or more application programming interfaces (APIs) hosted by the server 1406. Additionally or alternatively, in some embodiments, the mobile device 1404 can transmit information to one or more application programming interfaces (APIs) hosted by a third party, such as a cloud computing provider.

[0147] In 1414, the server 1406 can process information received from the mobile device 1404. For example, in some embodiments, the server 1406 can verify encrypted and / or authenticated data received from the mobile device 1404. In this regard, the server 1406 can process information received from the mobile device 1404 partially or completely. Additionally or alternatively, in some embodiments, the server 1406 can compare protected data with recorded data stored in the server 1406.

[0148] In 1416, the server 1406 can transmit information to the mobile device 1404. For example, the server 1406 can transmit an instruction that the encryption has been verified, transmit protected data or other data that the server 1406 has decrypted from the encryption, transmit recorded data stored in the server 1406, and / or transmit an instruction that is the result of comparing the protected data with the recorded data.

[0149] Once the mobile device 1404 has verified the encryption received from the contactless card 1402 and / or received information from the server 1406 and completed any further processing necessary to verify the encryption received from the contactless card 1402, the mobile device 1404 can initiate an action that requires encryption verification, such as launching a shopping mobile application and / or a shopping browser extension.

[0150] Figure 15 shows an exemplary embodiment of the computer architecture 1500 suitable for carrying out the various embodiments described above. In one embodiment, the computer architecture 1500 may be implemented in or as part of one or more systems or devices described herein.

[0151] As used in this application, the terms “system” and “component” are intended to refer to any computer-related entity, whether hardware, a combination of hardware and software, software, or software in operation, examples of which are provided by the exemplary computing computer architecture 1500. For example, a component may be, but is not limited to, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and / or magnetic storage media), an object, an executable file, an execution thread, a program, and / or a computer. For example, both an application running on a server and the server itself may be components. One or more components may reside within a process and / or an execution thread, and components may be localized on one computer and / or distributed between two or more computers. Furthermore, components may be coupled together communicatively by various types of communication media to coordinate their operation. Coordination may include the unidirectional or bidirectional exchange of information. For example, components may communicate information in the form of signals communicated over a communication medium. Information may be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, further embodiments may use data messages instead. Such data messages can be transmitted over various connections. Illustrative connections include parallel interfaces, serial interfaces, and bus interfaces.

[0152] Computing architecture 1500 includes various common computing elements, such as one or more processors, multicore processors, coprocessors, 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 implementations of computing architecture 1500.

[0153] As shown in Figure 15, the computing architecture 1500 includes a processor 1512, system memory 1504, and a system bus 1506. The processor 1512 can be any of various commercially available processors.

[0154] The system bus 1506 provides the processor 1512 with interfaces for system components, including but not limited to system memory 1504. The system bus 1506 can be one of several types of bus structures that can further interconnect to the memory bus (with or without a memory controller), peripheral buses, and local buses using any of various commercially available bus architectures. Interface adapters can connect to the system bus 1506 via slot architectures. Exemplary slot architectures may include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, Industry Standard Architecture ((E)ISA), Microchannel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extensions) (PCI(X)), Peripheral Component Interconnect (PCI) Express, and the International Personal Computer Memory Card Association (PCMCIA).

[0155] The computing architecture 1500 may include or implement a variety of products. These products may include computer-readable storage media for storing logic. Examples of computer-readable storage media include any tangible media capable of storing electronic data, such as volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, and writable or rewritable memory. Examples of logic may include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, and visual code. Embodiments may also be implemented at least partially as instructions contained in or on non-temporary computer-readable media, where these instructions may be read and executed by one or more processors to enable the execution of the operations described herein.

[0156] The system memory 1504 may include various types of computer-readable storage media in the form of one or more high-speed memory units, such as ROM, RAM, dynamic RAM (DRAM), double data-rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), EEPROM, flash memory, polymer memory such as ferroelectric polymer memory, ovonic memory, phase-change or ferroelectric memory, silicon oxide nitride (SONOS) memory, magnetic or optical cards, arrays of devices such as independent disk redundant array (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 illustrated embodiment shown in Figure 15, the system memory 1504 may include non-volatile 1508 and / or volatile 1510. The basic input / output system (BIOS) may be stored in the non-volatile 1508.

[0157] The computer 1502 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 1530, a magnetic disk drive 1516 that reads and writes to a removable magnetic disk 1520, and an optical disk drive 1528 that reads and writes to a removable optical disk 1532 (e.g., a CD-ROM or DVD). The hard disk drive 1530, the magnetic disk drive 1516, and the optical disk drive 1528 can be connected to the system bus 1506 by a hard disk drive (HDD) interface 1514, a floppy disk drive (FDD) interface 1518, and an optical disk drive interface 1534, respectively. The HDD interface 1514 for external drive implementation may include at least one or both of the Universal Serial Bus (USB) and IEEE 1394 interface technologies.

[0158] The drive and associated computer-readable media provide volatile and / or non-volatile storage of data, data structures, computer-executable instructions, etc. For example, several program modules, including an operating system 1522, one or more applications 1542, other program modules 1524, and program data 1526, can be stored in the drive and non-volatile 1508 and volatile 1510. In one embodiment, the one or more applications 1542, other program modules 1524, and program data 1526 may include, for example, various applications and / or components of the system described herein.

[0159] The user can input commands and information to the computer 1502 via one or more wired / wireless input devices, such as a pointing device like a keyboard 1550 and a mouse 1552. Other input devices may include a microphone, infrared (IR) remote control, radio frequency (RF) remote control, gamepad, stylus pen, card reader, dongle, fingerprint reader, glove, graphics tablet, joystick, keyboard, retina reader, touchscreen (e.g., capacitive, resistive, etc.), trackball, trackpad, sensor, stylus, etc. These and other input devices are often connected to the processor 1512 via an input device interface 1536 coupled to the system bus 1506, but can also be connected via other interfaces such as a parallel port, IEEE 1394 serial port, game port, USB port, or IR interface.

[0160] Monitor 1544 or other types of display devices are also connected to the system bus 1506 via interfaces such as the video adapter 1546. Monitor 1544 may be located inside or outside the computer 1502. In addition to Monitor 1544, the computer typically includes other peripheral output devices such as speakers and printers.

[0161] Computer 1502 may operate in a network environment using logical connections via wired and / or wireless communication to one or more remote computers, such as remote computer 1548. Remote computer 1548 could be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment equipment, peer device, or other common network node, typically including many or all of the elements described with respect to computer 1502, but for brevity, only memory and / or storage device 1558 is shown. The illustrated logical connections include wired / wireless connections to a LAN 1556 and / or a larger network, such as a wide area network (WAN) 1554. Such LAN and WAN networking environments are common in offices and enterprises, facilitating enterprise-scale computer networks such as intranets, all of which may connect to global communication networks such as the Internet.

[0162] When used in a LAN1556 networking environment, computer 1502 connects to LAN1556 via a wired and / or wireless network interface or network adapter 1538. The network adapter 1538 can facilitate wired and / or wireless communication to LAN1556, which may also include a wireless access point deployed to communicate with the wireless capabilities of the network adapter 1538.

[0163] When used in a WAN1554 network environment, computer 1502 may include a modem 1540 that connects to a communication server on WAN1554, or has other means of establishing communication on WAN1554, such as via the Internet. The modem 1540 may be internal or external, and wired and / or wireless, and connects to the system bus 1506 via an input device interface 1536. In a networked environment, program modules shown with respect to computer 1502 or a part thereof can be stored in remote memory and / or storage device 1558. The illustrated network connection is illustrative, and it will be understood that other means of establishing communication links between computers may be used.

[0164] Computer 1502 may be capable of communicating with wired and wireless devices or entities using standards of the IEEE 802 family, such as wireless devices configured to operate wirelessly (e.g., IEEE 802.11 wireless modulation technology). This includes at least Wi-Fi, WiMAX, and Bluetooth® wireless technologies. Thus, communication can be a predefined structure, similar to conventional networks, or simply ad-hoc communication between at least two devices. Wi-Fi networks provide secure, reliable, and high-speed wireless connectivity using wireless technologies called IEEE 802.11 (a, b, g, n, etc.). Wi-Fi networks can be used to connect computers to each other, to the Internet, and to wired networks (using IEEE 802.3 related media and functions).

[0165] The various elements of a device as described herein may include various hardware elements, software elements, or combinations thereof. Examples of hardware elements may include devices, logic devices, components, processors, microprocessors, circuits, processors, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, ASICs, PLDs, DSPs, field-programmable gate arrays (FPGAs), memory units, logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software elements may include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, APIs, instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. However, the determination of whether an embodiment is implemented using hardware and / or software elements may vary according to any number of factors desired for a given implementation, such as desired computing speed, power level, heat resistance, processing cycle budget, input data rate, output data rate, memory resources, data bus rate, and other design or performance constraints.

[0166] The components and features of the device described above may be implemented using any combination of discrete circuits, ASICs, logic gates, and / or single-chip architectures. Furthermore, the features of the device may, where appropriate, be implemented using microcontrollers, programmable logic arrays, and / or microprocessors, or any combination thereof. Note that hardware, firmware, and / or software elements may be referred to collectively or individually as “logic” or “circuit” in this specification.

[0167] Figure 16 is a block diagram showing an exemplary communication architecture 1600 suitable for implementing the various embodiments described above. The communication architecture 1600 includes various common communication elements, such as transmitters, receivers, transceivers, radios, network interfaces, baseband processors, antennas, amplifiers, filters, power supplies, etc. However, embodiments are not limited to implementations of the communication architecture 1600 that may correspond to the systems and devices described herein.

[0168] As shown in Figure 16, the communication architecture 1600 includes one or more clients 1602 and a server 1604. The server 1604 may implement one or more functions and embodiments described herein. The clients 1602 and the server 1604 are operably connected to one or more respective client data stores 1606 and server data stores 1608, which can be used to store information local to each client 1602 and server 1604, such as cookies and / or associated contextual information.

[0169] Client 1602 and server 1604 can communicate information with each other using the communication framework 1610. The communication framework 1610 can implement any well-known communication technology and protocol. The communication framework 1610 can be implemented as a packet-switched network (e.g., a public network such as the Internet, a private network such as a corporate intranet), a circuit-switched network (e.g., a public switched telephone network), or a combination of a packet-switched network and a circuit-switched network (with appropriate gateways and converters).

[0170] The communication framework 1610 can implement various network interfaces for accepting, communicating, and connecting communication networks. A network interface can be considered a special form of input / output (I / O) interface. Network interfaces can use, but are not limited to, connection protocols including direct connection, Ethernet (e.g., thick, thin, twisted-pair 10 / 100 / 1000-base T, etc.), Token Ring, wireless network interfaces, cellular network interfaces, IEEE 802.7a-x network interfaces, IEEE 802.16 network interfaces, and IEEE 802.20 network interfaces. Furthermore, multiple network interfaces can be used to connect to various communication network types. For example, multiple network interfaces can be used to enable communication over broadcast, multicast, and unicast networks. If processing requirements demand a greater amount of speed and capacity, a distributed network controller architecture can similarly be used to pool, distribute the load, and increase the communication bandwidth otherwise required by the client 1602 and server 1604. Communication networks may include, but are not limited to, any one or combination of wired and / or wireless networks, including but not limited to direct interconnections, secure custom connections, private networks (e.g., corporate intranets), public networks (e.g., the Internet), PANs, LANs, metropolitan area networks (MANs), operating missions as nodes on the Internet (OMNI), WANs, wireless networks, cellular networks, and other communication networks.

Claims

1. It is a method, Receiving encryption from a contactless card using the short-range communication antenna of a mobile device, The encryption is verified by the processor of the mobile device, When the encryption is verified and the first mobile application is running on the mobile device, the second mobile application or shopping browser extension is launched on the mobile device. Methods that include...

2. In response to the first mobile application running on the mobile device, a request to communicate with the contactless card is displayed on the display screen of the mobile device. The method according to claim 1, further comprising:

3. In response to displaying the payment screen associated with the first mobile application on the display screen of the mobile device, the request for communication with the contactless card is displayed on the display screen of the mobile device. The method according to claim 2, further comprising:

4. In response to the items placed in the shopping cart associated with the first mobile application, the request for communication with the contactless card is displayed on the display screen of the mobile device. The method according to claim 2, further comprising:

5. To verify the aforementioned encryption, to successfully decrypt the aforementioned encryption. The method according to claim 1, further comprising:

6. Decrypting the protected data within the aforementioned encryption, The protection data is compared with the recorded data associated with the contactless card, If the protection data matches the recorded data, verify the customer associated with the contactless card. The method according to claim 5, further comprising:

7. The mobile device transmits the encryption to the server, The mobile device receives an instruction from the server that the encryption has been verified. The method according to claim 1, further comprising:

8. The method according to claim 1, wherein the second mobile application or the shopping browser extension automatically applies available coupons to items in the cart associated with the first mobile application.

9. The method according to claim 1, wherein the second mobile application or the shopping browser extension automatically searches for better prices for items in the cart associated with the first mobile application and displays the better prices found on alternative websites on the display screen of the mobile device.

10. A non-temporary computer-readable medium, which, when executed by a processor, the processor, The mobile device receives encryption from the contactless card via its near-field communication antenna. Let the aforementioned encryption be verified, When the encryption is verified and the first mobile application is running on the mobile device, the second mobile application or shopping browser extension is launched on the mobile device. A non-temporary computer-readable medium containing instructions.

11. The non-temporary computer-readable medium according to claim 10, wherein, in response to the first mobile application executed on the mobile device, the instruction further causes the processor to display a request on the display screen of the mobile device to communicate with the contactless card.

12. The non-temporary computer-readable medium according to claim 11, wherein, in response to displaying a payment screen associated with the first mobile application on the display screen of the mobile device, the instruction further causes the processor to display the request for communication with the contactless card on the display screen of the mobile device.

13. The non-temporary computer-readable medium according to claim 11, wherein, in response to an item placed in a shopping cart associated with the first mobile application, the instruction further causes the processor to display the request for communication with the contactless card on the display screen of the mobile device.

14. The non-temporary computer-readable medium according to claim 10, wherein the instruction further causes the processor to successfully decrypt the cipher in order to verify the cipher.

15. The instruction further tells the processor: Decrypt the protected data within the aforementioned encryption, The protection data is compared with the recorded data associated with the contactless card. A non-temporary computer-readable medium according to claim 14, wherein if the protection data matches the recorded data, the customer associated with the contactless card is verified.

16. The instruction further tells the processor: The mobile device transmits the encryption to the server, The non-temporary computer-readable medium according to claim 10, which causes the mobile device to receive an instruction from the server that the encryption has been verified.

17. The non-temporary computer-readable medium according to claim 10, wherein the second mobile application or the shopping browser extension automatically applies available coupons to items in a cart associated with the first mobile application.

18. The non-temporary computer-readable medium according to claim 10, wherein the second mobile application or the shopping browser extension automatically searches for better prices for items in the cart associated with the first mobile application and displays the better prices found on alternative websites on the display screen of the mobile device.

19. It is a mobile device, Short-range communication antenna and Processor and A memory for storing instructions, wherein when an instruction is executed by the processor, the processor receives The encryption is received from the contactless card via the aforementioned short-range communication antenna. Let the aforementioned encryption be verified, The encryption is verified, and when the processor is running the first mobile application, the memory and launch the second mobile application or shopping browser extension. A mobile device equipped with these features.

20. Furthermore, equipped with a display device, The mobile device according to claim 19, wherein the instruction further causes the processor to display on the display device a request to communicate with the contactless card in response to the processor running the first mobile application.

Images