System and method for disabling contactless cards to prevent fraud

Abstract

A method of disabling a contactless card to prevent fraud is provided. The method includes determining that the contactless card is fraudulent, including at least one of determining that a trust level score of the contactless card is below a trust level threshold, determining that the contactless card has been lost, or determining that the contactless card has been stolen. The method also includes disabling the contactless card, including at least one selected from the group of: covering an applet on the contactless card, changing a public key on the contactless card, deleting a public key and a private key on the contactless card, changing the private key on the contactless card, and modifying a payment applet on the contactless card to accept a temporary disable signal.

Description

Cross-references to related applications

[0001] This application claims priority to U.S. Patent Application No. 18 / 918,482, filed October 17, 2024, and U.S. Provisional Patent Application No. 63 / 544,985, filed October 20, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure generally relates to contactless card security, and more specifically, to systems and methods for disabling contactless cards to prevent fraud. Background Technology

[0003] Contactless card data security and transaction integrity are critical to businesses and consumers. Fraudulent transactions can be costly and damaging to both, and attempts by fraudsters to carry out fraudulent transactions or other fraudulent activities are on the rise.

[0004] Currently, financial institutions or other card issuers and / or service providers cannot disable contactless cards. For example, when a contactless card is reported lost or stolen, future transactions associated with that card may be rejected. However, since such contactless cards are unmodified, transactions can still be processed before future transactions are rejected, allowing fraudsters to attempt fraudulent transactions or other fraudulent activities before being prevented.

[0005] These and other shortcomings still exist. Therefore, there is a need for systems and methods to overcome these shortcomings, improve data security and transaction integrity, prevent financial losses, and reduce fraud. Summary of the Invention

[0006] Embodiments of this disclosure provide a method for disabling contactless cards to prevent fraud. The method includes: determining that the contactless card is fraudulent, including at least one of the following: determining that the trust level score of the contactless card is below a trust level threshold, determining that the contactless card is lost, and determining that the contactless card has been stolen; and disabling the contactless card, including at least one of the following: overwriting a mini-program on the contactless card, changing the public key on the contactless card, deleting the public and private keys on the contactless card, changing the private key on the contactless card, and modifying the payment mini-program on the contactless card to accept a temporary disable signal.

[0007] Embodiments of this disclosure provide a system for disabling contactless cards to prevent fraud. The system includes a server. The server includes a processor and memory coupled to the processor. The server is configured to: determine that a contactless card is fraudulent, including at least one selected from the group consisting of: determining that the contactless card's trust level score is below a trust level threshold, determining that the contactless card is lost, and determining that the contactless card has been stolen; and disable the contactless card, including at least one selected from the group consisting of: overwriting a payment app on the contactless card, changing the public key on the contactless card, deleting the public and private keys on the contactless card, changing the private key on the contactless card, and modifying the payment app on the contactless card to accept a temporary disable signal.

[0008] Embodiments of this disclosure provide a non-transitory computer-readable medium comprising: instructions for disabling a contactless card to prevent fraud, the instructions, when executed on a computer device, performing actions including: determining that the contactless card is fraudulent, including at least one selected from the group consisting of: determining that the trust level score of the contactless card is below a trust level threshold, determining that the contactless card is lost, and determining that the contactless card has been stolen; and disabling the contactless card, including at least one selected from the group consisting of: overwriting a small program on the contactless card, changing the public key on the contactless card, deleting the public and private keys on the contactless card, changing the private key on the contactless card, and modifying the payment small program on the contactless card to accept a temporary disable signal.

[0009] The following will explain in more detail the further features of the disclosed system and method, and the advantages therefrom, with reference to specific example embodiments shown in the accompanying drawings. Attached Figure Description

[0010] Figure 1 This is a diagram of a system for disabling contactless cards according to an example embodiment.

[0011] Figure 2 According to the example embodiment Figure 1 A diagram showing the sequential interactions between the components of the system.

[0012] Figure 3A This is a contactless card for disabling contactless cards according to an example embodiment.

[0013] Figure 3B According to the example embodiment Figure 3A A diagram of the contact pad of a contactless card.

[0014] Figure 4 This is a flowchart of a method for disabling contactless cards according to an example embodiment.

[0015] Figure 5 This is a flowchart of a method for determining a contactless card as fraud based on an example embodiment.

[0016] Figure 6 This is a flowchart of a method for disabling contactless cards according to an example embodiment.

[0017] Figure 7 This is a flowchart of a method for disabling contactless cards according to an example embodiment. Detailed Implementation

[0018] The following description of the embodiments provides reference numerals to specifically describe non-limiting representative examples of the features and teachings of different aspects of the invention. The described embodiments should be recognized as being achievable individually or in combination with other embodiments described herein. Those skilled in the art who review the description of the embodiments should be able to learn and understand the different descriptive aspects of the invention. The description of the embodiments is intended to facilitate an understanding of the invention such that other embodiments not specifically covered but within the knowledge of those skilled in the art upon reading the description of the embodiments will be understood to be consistent with the application of the invention.

[0019] The features and teachings of the embodiments described can be combined in any suitable manner. Those skilled in the art will recognize that this embodiment can be practiced without one or more specific features and teachings of a particular embodiment. In other instances, additional features and teachings that may not be present in all embodiments may be identified in some embodiments. Those skilled in the art will understand that the features and teachings of any embodiment can be combined interchangeably with the features and teachings of any other embodiment.

[0020] When a contactless card is determined to be fraudulent, lost, or stolen, financial institutions such as banks currently cannot physically disable it. While further transactions on such contactless cards may be rejected, the contactless card itself remains unmodified. The systems and methods provided in the example embodiments of this disclosure enable the Europay, Mastercard, and Visa (EMV) applets on the contactless card itself to be disabled or deactivated, and / or then reactivated via near-field communication (NFC) from a mobile phone. Specifically, this can be achieved through a software development kit (SDK) (e.g., a bank SDK embedded in a merchant website at the time of purchase). The SDK can be configured to connect back to the financial institution deploying the SDK via an application programming interface (API).

[0021] In some embodiments, the SDK and the contactless card can exchange digital certificates containing public keys, which can establish a secure communication channel between the SDK and the contactless card.

[0022] The SDK can be configured to build a customer fraud profile as the customer browses a merchant's website and use identifiers such as cookies and Internet Protocol (IP) addresses to assess the customer's likelihood of fraud.

[0023] If a customer is identified as a fraudster, the contactless card can be disabled, for example, when establishing NFC communication with the contactless card during the checkout process, or even before the transaction. If fraud is suspected before checkout, the contactless card can be disabled during the transaction when the customer taps it against their phone.

[0024] In some embodiments, contactless cards may be disabled for a variety of reasons, including but not limited to: data during a transaction indicating possible fraud; the contactless card being reported lost or stolen; or fraud on the contactless card being reported to a bank.

[0025] When a contactless card communicates with a mobile device and / or point-of-sale terminal, the card can be disabled in several ways, some reversible and others permanent. Disabling methods may include, but are not limited to: overwriting the contactless card's EMV app, which can permanently disable the card; changing the contactless card's public key to prevent initial authorization, which may also permanently disable the card; deleting the contactless card's public and private keys; changing the contactless card's private key, which can be changed back to reactivate the card; and modifying the EMV payment app to accept temporary disable signals, which can be achieved by sending a signature command to the contactless card, and the contactless card can use an embedded public key to verify the signature of the signed command.

[0026] This disclosure provides example embodiments of systems and methods for disabling contactless cards to prevent fraud, thereby preventing fraudulent transactions and other fraudulent activities on contactless cards. The systems and methods disclosed herein can aggregate fraud data or information on contactless cards to create better fraud profiles on them. Fraud data can be collected from software development kits (SDKs) embedded in merchant checkout processes or from information that merchants may provide. A trust level score for the contactless card can be generated based on the fraud profile to determine whether the contactless card is fraudulent. Example embodiments of this disclosure can disable contactless cards before a transaction occurs based on fraud data pre-collected by the network and the SDK. The SDK can be embedded in the merchant's website. Fraud data may include customer behavioral data, customer geolocation, customer browsing history, customer mouse movements, customer base location, etc.

[0027] In some embodiments, this disclosure can be applied to tapping a mobile phone against a point-of-sale or transaction device. Such a mobile phone can be configured to have one or more payment applications installed thereon, enabling the mobile phone to effectively act as a contactless card for transaction payments.

[0028] Figure 1 A system 100 for disabling contactless cards to prevent fraud, according to an example embodiment, is shown. As discussed further below, system 100 may include a first device 110, a second device 120, a server 130, a database 140 communicating via a network 150, and a contactless card 160 signal-communicating with the first device 110. Although Figure 1 A single instance of a component is shown, but system 100 may include any number of components.

[0029] The first device 110 may be associated with a merchant with whom the user transacts; for example, the first device 110 may be a point-of-sale terminal associated with that merchant. The first device 110 may also be a user device (e.g., a mobile device) associated with the user for conducting online transactions (such as online purchases). The first device 110 may also be configured to host an online shopping website for the merchant, on which the user can browse and / or purchase products and / or services offered by the merchant. The first device 110 may be configured to store the user's online merchant account and present a shopping interface on which the user can transact with the merchant.

[0030] The first device 110 may be a network-enabled computer device. Exemplary network-enabled computer devices include, but are not limited to, servers, network devices, personal computers, workstations, telephones, handheld personal computers, personal digital assistants, thin clients, fat clients, internet browsers, mobile devices, kiosks, contactless cards, or other computer or communication devices. For example, a network-enabled computer device may include an iPhone, iPod, iPad, or any other mobile device running Apple's iOS® operating system from Apple®, any device running Microsoft's Windows® Mobile operating system, any device running Google's Android® operating system, and / or any other smartphone, tablet, or similar wearable mobile device.

[0031] The first device 110 may include a processor 111, a memory 112, and an application 113. The processor 111 may be a processor, microprocessor, or other processor, and the first device 110 may include one or more of these processors. The processor 111 may include processing circuitry that may include additional components, including additional processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware, to perform the functions described herein as needed.

[0032] Processor 111 may be coupled to memory 112. Memory 112 may be read-only memory, write-multiple-read memory, or read / write memory, such as RAM, ROM, and EEPROM, and first device 110 may include one or more of these memories. Read-only memory may be factory-programmed to be read-only or programmable only once. One-time programmability provides the opportunity to write once and then read many times. Write-multiple-read memory can be programmed at some point after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten, but it can be read multiple times. Read / write memory can be programmed and reprogrammed many times after leaving the factory. It can also be read multiple times. Memory 112 may be configured to store one or more software applications, such as application 113, as well as other data, such as a user's shopping and financial account information.

[0033] Application 113 may include one or more software applications that include instructions for execution on the first device 110. In some examples, the first device 110 may execute one or more applications, such as software applications, that are capable of, for example, networking with one or more components of system 100, transmitting and / or receiving data, and performing the functions described herein. After execution by processor 111, application 113 may provide the functions described herein, specifically, execute and perform the steps and functions in the processing flow described herein. For example, application 113 may be executed to perform user authentication or send an authentication request for an authenticated user to server 130. Application 113 may also be executed to perform processing transactions for users who may shop online from merchants and / or collect user risk data. Such processes may be implemented in software, such as software modules, for execution by a computer or other machine. Application 113 may provide a graphical user interface (GUI) through which a user can view and interact with other components and devices within system 100. The GUI can be formatted as, for example, Hypertext Markup Language (HTML), Extensible Markup Language (XML), or any other suitable form that the user uses to interact with the system 100 to render on the display device.

[0034] The first device 110 may further include a display 114 and an input device 115. The display 114 may be any type of device for presenting 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 115 may include any device available to and supported by the first device 110 for inputting information into the first device 110, 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 the software and other devices described herein.

[0035] The second device 120 can be used by an entity such as a merchant to process online transactions. The second device 120 can be a merchant server. The second device 120 can be configured to present a user interface from which the user can log in, for example, to their online account. The second device 120 can also store the user's transaction history, such as the user's purchase history including the purchase location, purchase date, and purchase time.

[0036] The second device 120 may be a network-enabled computer device. Exemplary network-enabled computer devices include, but are not limited to, contactless cards, servers, network devices, personal computers, workstations, telephones, handheld personal computers, personal digital assistants, thin clients, fat clients, internet browsers, mobile devices, kiosks, contactless cards, or other computer or communication devices. For example, a network-enabled computer device may include an iPhone, iPod, iPad, or any other mobile device running Apple's iOS® operating system from Apple®, any device running Microsoft's Windows® Mobile operating system, any device running Google's Android® operating system, and / or any other smartphone, tablet, or similar wearable mobile device.

[0037] The second device 120 may include a processor 121, a memory 122, an application 123, a display 124, and an input device 125. The processor 121 may be a processor, microprocessor, or other processor, and the second device 120 may include one or more such processors. The processor 121 may include processing circuitry that may include additional components, including additional processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware, to perform the functions described herein as needed.

[0038] Processor 121 may be coupled to memory 122. Memory 122 may be read-only memory, write-multiple-read memory, or read / write memory, such as RAM, ROM, and EEPROM, and the second device 120 may include one or more such memories. Read-only memory may be factory-programmed to be read-only or programmable only once. One-time programmability provides the opportunity to write once and then read many times. Write-multiple-read memory can be programmed at some point after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten, but it can be read many times. Read / write memory can be programmed and reprogrammed many times after leaving the factory. It can also be read many times. Memory 122 may be configured to store one or more software applications, such as application 123, as well as other data, such as private information and personal information.

[0039] Application 123 may include one or more software applications that include instructions for execution on the second device 120. In some examples, the second device 120 may execute one or more applications, such as software applications, that are capable of, for example, networking with one or more components of system 100, transmitting and / or receiving data, and performing the functions described herein. After execution by processor 121, application 123 may provide the functions described herein, specifically, execute and perform the steps and functions in the processing flow described herein. Such processes may be implemented in software, such as software modules, for execution by a computer or other machine. Application 123 may provide a graphical user interface (GUI) through which a user can view and interact with other components and devices within system 100. The GUI may be formatted as, for example, Hypertext Markup Language (HTML), Extensible Markup Language (XML), or any other suitable form for presentation on a display device, depending on the application used by the user to interact with system 100.

[0040] The second device 120 may also include a display 124 and an input device 125. The display 124 may be any type of device for presenting 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 125 may include any device available to and supported by the second device 120 for inputting information into the second device 120, 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 the software and other devices described herein, such as selecting the option to create an online account with a merchant.

[0041] Server 130 may be associated with an institution such as a financial institution and may be configured to communicate with first device 110 and second device 120. The institution associated with server 130 may be a bank that issues contactless cards (such as contactless card 160 for users to use to make purchases from merchants) or a central bank authentication entity. The server may be configured to authenticate and / or verify users based on the contactless card 160 associated with them. Server 130 may also be configured to receive user risk data from first device 110 and / or second device 120.

[0042] Server 130 may be a network-enabled computer device. Exemplary network-enabled computer devices include, but are not limited to, contactless cards, servers, network devices, personal computers, workstations, telephones, handheld personal computers, personal digital assistants, thin clients, fat clients, internet browsers, mobile devices, kiosks, contactless cards, or other computer or communication devices. For example, a network-enabled computer device may include an iPhone, iPod, iPad, or any other mobile device running Apple's iOS® operating system from Apple®, any device running Microsoft's Windows® Mobile operating system, any device running Google's Android® operating system, and / or any other smartphone, tablet, or similar wearable mobile device.

[0043] Server 130 may include processor 131, memory 132, and application 133. Processor 131 may be a processor, microprocessor, or other processor, and server 130 may include one or more such processors. Processor 131 may include processing circuitry that may include additional components, including additional processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware, to perform the functions described herein as needed.

[0044] Processor 131 may be coupled to memory 132. Memory 132 may be read-only memory, write-multiple-read memory, or read / write memory, such as RAM, ROM, and EEPROM, and server 130 may include one or more such memories. Read-only memory may be factory-programmed to be read-only or programmable only once. One-time programmability provides the opportunity to write once and then read many times. Write-multiple-read memory can be programmed at some point after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten, but it can be read multiple times. Read / write memory can be programmed and reprogrammed many times after leaving the factory. It can also be read multiple times. Memory 132 may be configured to store one or more software applications, such as application 133, as well as other data, such as user financial account information and contactless card information.

[0045] Application 133 may include one or more software applications, such as a card authentication module, which includes instructions for execution on server 130. In some examples, server 130 may execute one or more applications, such as software applications, that implement network communication with one or more components of system 100, transmit and / or receive data, and perform the functions described herein. After execution by processor 131, application 133 may provide the functions described herein, specifically, execute and perform the steps and functions in the processing flow described herein. For example, the card authentication module of application 133 may be executed to authenticate and / or verify a user based on contactless card 160. Such processes may be implemented in software, such as software modules, for execution by a computer or other machine. Application 133 may provide a GUI through which a user can view and interact with other components and devices within system 100. The GUI may be formatted as, for example, Hypertext Markup Language (HTML), Extensible Markup Language (XML), or any other suitable form for presentation on a display device, depending on the application used by the user to interact with system 100.

[0046] Server 130 may also include a display 134 and an input device 135. Display 134 may be any type of device for presenting 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. Input device 135 may include any device available to and supported by server 130 for inputting information into server 130, 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 the software and other devices described herein.

[0047] Database 140 may be one or more databases configured to store data, including but not limited to user's private information, user's financial account, contactless card information, online merchant account information, user transactions, user fraud risk data, and merchant records indicating corresponding merchants. Database 140 may include relational databases, non-relational databases, or other database implementations and any combination thereof, including multiple relational databases and non-relational databases. In some examples, database 140 may include a desktop database, a mobile database, or an in-memory database. Furthermore, database 140 may be hosted internally by server 130 or externally by server 130, such as by a server, a cloud-based platform, or any storage device that communicates with server 130.

[0048] System 100 may include one or more networks 150. In some examples, network 150 may be one or more of a wireless network, a wired network, or any combination of wireless and wired networks, and may be configured to connect a first device 110, a second device 120, a server 130, and a database 140. For example, network 150 may include one or more of the following: fiber optic network, passive optical network, cable network, Internet network, satellite network, wireless local area network (LAN), Global System for Mobile Communications (GSMO), personal communication service, personal area network, wireless application protocol, multimedia messaging service, enhanced messaging service, short message service, time division multiple access based system, code division multiple access based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth, NFC, radio frequency identification (RFID), Wi-Fi and / or similar protocols.

[0049] Additionally, network 150 may include, but is not limited to, telephone lines, fiber optic cables, IEEE Ethernet 902.3, wide area networks, wireless personal area networks, LANs, or global networks such as the Internet. Furthermore, network 150 may support Internet networks, wireless communication networks, cellular networks, or similar networks, or any combination thereof. Network 150 may also include one network or any number of networks of the exemplary types mentioned above, operating independently or collaboratively with each other. Network 150 may utilize one or more protocols coupled to one or more network elements. Network 150 may convert other protocols to or from one or more protocols of network devices. Although network 150 is depicted as a single network, it should be understood that, according to one or more examples, network 150 may include multiple interconnected networks, such as, for example, the Internet, a service provider's network, a cable television network, a corporate network (such as a credit card association network), and a home network. Network 150 may also include or be configured to create one or more forward channels and one or more secure backward channels, wherein the forward channel may be publicly accessible and communication through the forward channel is observable, and the backward channel may be not publicly accessible and communication through the backward channel is not observable.

[0050] In some examples, communication between the first device 110, server 130, and second device 120 using network 150 may use one or more forward channels and one or more secure backward channels. The forward channel may employ a communication protocol that uses publicly accessible and / or insecure communication channels, allowing communication sent to the first device 110, server 130, and / or second device 120 to originate from any other device, whether the first device 110, server 130, and / or second device 120 are known or unknown, as long as that device possesses the addresses (e.g., network addresses, Internet Protocol (IP) addresses) of the first device 110, server 130, and / or second device 120. Exemplary forward channels include, but are not limited to, the Internet, open networks, and other publicly accessible communication networks. In some examples, communication sent using a forward channel is susceptible to unauthorized observation by another device. In some examples, forward channel communication may include Hypertext Transfer Protocol (HTTP) Secure Sockets Layer (SSL) communication, HTTP Secure (HTTPS) communication, and browser-based communication with servers or other devices.

[0051] A secure backchannel can be a communication protocol employing a secure and / or publicly inaccessible communication channel. Secure backchannel communication sent to the first device 110, server 130, and / or second device 120 may not originate from any single device, but may originate only from a selected number of parties. In some examples, the selected number of devices may include known, trusted, or otherwise previously authorized devices. Exemplary secure backchannels include, but are not limited to, closed networks, private networks, virtual private networks, offline private networks, and other dedicated communication networks. In some examples, communication sent using a secure backchannel may not be subject to unauthorized observation by another device. In some examples, secure backchannel communication may include Hypertext Transfer Protocol (HTTP) Secure Sockets Layer (SSL) communication, HTTP Secure (HTTPS) communication, and browser-based communication with servers or other devices.

[0052] The contactless card 160 can be any type of card, such as a credit card, payment card, ID card, or similar card. The contactless card 160 can be issued by banks to users for identity verification of their bank accounts. The contactless card 160 can be used as a user's universal identifier (ID) to identify the user across multiple banks, thus eliminating the need for a social security card number to identify the user across multiple banks, which can enhance data security and user privacy.

[0053] The contactless card 160 can be configured to transmit encrypted text to the first device 110 when tapped. The first device 110 can be configured to read the encrypted text from the contactless card 160 after it enters the communication field of the first device 110. The first device 110 can then transmit the encrypted text to a second device 120 or a server 130. The server 130 can be configured to verify the encrypted text by searching a database 140.

[0054] The contactless card 160 can perform authentication and numerous other functions that would otherwise require the user to carry a separate physical token, in addition to the contactless card 160 itself. By employing a contactless interface, the contactless card 160 provides a method for interaction and communication between the user's device (such as a mobile phone) and the card itself. For example, the EMV protocol, which underlies many credit card transactions, includes an authentication process sufficient for the Android® operating system, but presents challenges for iOS®, which has greater limitations on the use of Near Field Communication (NFC) as it can only be used in read-only mode. An exemplary embodiment of the contactless card 160 described herein utilizes NFC technology. The contactless card 160 may include a substrate 162 and a contact pad 164. Further details of example contactless cards will be provided later. Figure 3A and Figure 3BThe description is as follows. When the contactless card 160 is determined to be fraudulent, stolen, or lost, the contactless card 160 can be disabled by the second device 120 or the server 130.

[0055] Figure 2 Figure 200 illustrates a sequence of interactions between components of a system 100 according to an example embodiment. Figure 2 Can be quoted and Figure 1 The same or similar components shown include a first device, a server, a database, a second device, and a contactless card.

[0056] When a user wants to make an online or offline purchase, in step 205, the first device 110 (e.g., a user's mobile phone or point-of-sale terminal) can transmit an NFC query to the contactless card 160. Application 113 of the first device 110 may include an application capable of reading the contactless card 160. The first device 110 may be configured to support NFC and includes an NFC interface configured to establish NFC communication with other NFC-enabled devices (the contactless card 160 in this embodiment). In some of these embodiments, the NFC interface of the first device 110 may be or include an NFC receiver configured to selectively activate a magnetic field for establishing near-field communication with an NFC transmitter. When a passive NFC tag or other NFC-enabled device is brought into the magnetic field and within the NFC communication range of the first device 110, the NFC interface of the first device 110 is configured to establish NFC communication. When the contactless card 160 is brought into the communication range of the first device 110 (e.g., when the contactless card 160 is tapped onto the first device 110 by a user), the NFC interface of the first device 110 is specifically configured to communicate with the NFC-enabled contactless card 160. As used herein, tapping the first device 110 with the contactless card 160 can indicate that the contactless card 160 makes physical contact with the first device 110, and tapping the first device 110 with the contactless card 160 can indicate that the contactless card 160 enters the NFC communication field within the first device 110.

[0057] In response, after the contactless card 160 enters the NFC communication field of the first device 110, the contactless card 160 transmits NFC response information (e.g., ciphertext) to the first device 110 at step 210, which is used by the server 130 to authenticate the user. The NFC response information may be, or includes, for example, security information encrypted by the contactless card 160 using a private key known only to the server 130 and unique to the contactless card 160. The ciphertext may be stored in the memory of the contactless card 160. The ciphertext includes a unique identifier for the contactless card 160, which can be used as a general identifier for the user.

[0058] At step 215, the first device 110 transmits NFC response information (ciphertext) to the second device 120. The second device 120 may be a device associated with a merchant, such as a merchant server that communicates with the first device 110 (the user's mobile device or the merchant's point-of-sale terminal).

[0059] At step 220, the second device 120 transmits ciphertext to the server 130. At step 225, the server 130 can authenticate the contactless card using a unique identifier. The server 130 can verify the ciphertext, decrypt the ciphertext, and extract the unique identifier of the contactless card 160 through its card authentication module. When the server 130 receives the ciphertext, it can decrypt it after verification. The server 130 can then extract the unique identifier of the contactless card 160 uniquely associated with the user. The server 130 can verify the unique identifier of the contactless card 160 by searching the database 140. The server 130 can authenticate the user based on the unique identifier of the contactless card 160.

[0060] After the contactless card 160 is authenticated, at step 230, the server 130 can retrieve the fraud risk profile associated with the contactless card 160 from the database 140. This fraud risk profile may include, but is not limited to: fraud risk data associated with the user when browsing the website and / or purchasing products and / or services from the website; user behavior data, such as whether the user browses like a typical customer; network connectivity information, as the user's browser identifies the user's connection to the website; the user's geographic location; the user's browsing history, such as including time, location, and website content viewed; mouse movements while browsing the website; the orientation of the user's device; the website's fonts and language; image data associated with the website; the user's IP address; hardware and software details, such as user device details, operating system details, and web browser details; first-party and / or third-party cookies; autofill data; input logs; browser fingerprints, such as which websites the browser visited; sharing the same network access information; and / or the user's device's media access control address; the user's previous transactions at the merchant; recent changes to the user's email address or phone number; indications of an attempt by a third party to take over the user's account (ATO); and / or recent authentication using contactless cards or other methods in banking applications.

[0061] Fraud risk profiles generated using machine learning models of fraud risk can indicate the level of trust (also known as risk level) of a contactless card user as a potential fraudster. Trust levels can be numerical, such as from 1 to 5, where 1 is the lowest trust level and 5 is the highest. Trust levels can also be categorized as low, medium, and high trust levels.

[0062] In step 235, server 130 may determine that a contactless card is fraudulent based on a trust level determined from a fraud risk profile. The trust level may also be determined based on data indicating the likelihood of fraud during the transaction; the contactless card being reported lost; the contactless card being reported stolen; and / or fraud on the contactless card being reported to a bank.

[0063] At step 240, when it is determined that the contactless card is fraudulent, server 130 may disable the contactless card via first device 110. When the contactless card is communicating with first device 110 (such as a mobile device and / or point-of-sale terminal), the contactless card can be disabled in various ways, some of which may be reversible and others may be permanent (e.g., breaking the contactless card). Disabling methods may include, but are not limited to: overwriting the contactless card's EMV app, which can permanently disable the contactless card; changing the contactless card's public key to prevent initial authorization, which may permanently disable the contactless card; deleting the contactless card's public and private keys; changing the contactless card's private key, which can be changed back to reactivate the contactless card; and modifying the EMV payment app to accept temporary disable signals, which can be achieved by sending a signature command to the contactless card, and the contactless card can use an embedded public key to verify the signature of the signed command.

[0064] At step 245, server 130 may transmit a notification to second device 120 that the contactless card is disabled. At step 250, second device 120 may transmit a notification to first device 110 that the contactless card is disabled, thereby informing the user of the contactless card that the contactless card has been disabled due to potential fraud.

[0065] This allows contactless cards to self-destruct or self-deactivate, which can offer several advantages. For example, a fraudster might enter a store to make an offline or online purchase. In this case, the contactless card remains valid because authentication is present on the card, effectively indicating that it is a valid card. If the contactless card is determined to be fraudulent at that time, the server can instruct the SDK to disable the contactless card via NFC. That is, when instructed by the SDK, disabling can be performed by the contactless card itself via a applet on the contactless card. In some embodiments, the contactless card can be reactivated, for example, by tapping the contactless card into the first device 110.

[0066] The applet on the contactless card may contain keys (public and / or private keys) and security elements such as APIs. The contactless card can be disabled by deleting the keys and security elements, which may cause authentication to fail and effectively render the contactless card inoperable. In some embodiments, the applet on the contactless card may be modified to always return an error state so that it never communicates with the first device 110 again, thereby disabling the contactless card. In some embodiments, the SDK may transmit an update binary command to the applet of the contactless card that will disable the contactless card. In some embodiments, the contactless card can be reactivated by tapping the contactless card against the first device 110 to receive a command from the SDK containing a Message Authentication Code (MAC) created using a shared key between the contactless card and the SDK.

[0067] In some embodiments, a secret or key needs to be shared to determine the validity of disabling and reactivating messages. A public key system can be used. For example, the MAC digital signature of a message can be signed with a private key, and then the public key can be used to verify the signature on the contactless card. The public key can be stored on the contactless card. If the contactless card needs to be disabled or reactivated, the signed message can be sent to the contactless card via an Application Protocol Data Unit (APDU) command, which then turns the contactless card on or off.

[0068] In some embodiments, disabling a contactless card can be performed during the same checkout session. For example, when a contactless card is tapped onto the first device 110 to actually pay for a purchase, if the contactless card is determined to be fraudulent during the contactless card verification process, a disable command can be sent by the SDK to the contactless card to disable it within the same session. In some other embodiments, the contactless card can be disabled in a separate session. For example, a user can be asked to tap the contactless card again for confirmation, and the contactless card can be disabled when it is tapped for confirmation.

[0069] The disable command can be transmitted through a secure channel between the contactless card and the SDK. For example, a certificate can be used to perform public-key digital signatures. In some embodiments, the strength of the fraud profile signal can determine whether the disablement of the contactless card is reversible or permanent.

[0070] In some embodiments, a trust level signal can be added to an encrypted message on the contactless card, which is transmitted with each transaction. The contactless card app can include such a protocol to include the trust level signal in the encrypted message. For example, trust level 4 could mean all content on the contactless card is allowed, and trust level 0 could indicate that the contactless card may be fraudulent. Trust level 0 can trigger the SDK to transmit a disable command to the contactless card to disable it. A trust level 2 signal can reduce restrictions on individual transactions, for example, it might reduce the limit to $50 transactions, with any transaction exceeding $50 blocked. If the contactless card's fraud risk profile improves, commands from the SDK can be written to the contactless card to raise the trust level to a more trusted level. The trust level can be adjusted by the SDK each time it is written to the contactless card. The rules for determining the trust level can be defined by the merchant or bank issuing the contactless card. Third parties involved in each transaction between the merchant and the bank can also intervene and set their own rules at that trust level.

[0071] Contactless cards can contain a public key and a private key. The public key can be used for offline authentication, and the private key can be used for online authentication. For online authentication, contactless card authentication can be performed using a symmetric algorithm by a server 130 (e.g., a bank server), because the key is stored on both the contactless card and the server 130. When the payment terminal is offline, the contactless card can be authenticated using the public key, which contains the RSA key being used. Disabling this public key is crucial for disabling offline transactions for these contactless cards.

[0072] Figure 3A Describes what can be used as Figure 1 The system 100 includes a contactless card 300 (contactless card 160). The contactless card 300 is configured to communicate with the user equipment of the first device 110 and / or the user of the system 100. The contactless card 300 may include a payment card, such as a credit card, debit card, or gift card, issued by a service provider 305 (such as a bank associated with server 130) displayed on the front or back of the contactless card 300. In some examples, the contactless card 300 is not a payment card and may include, but is not limited to, ID cards, membership cards, and transportation cards. In some examples, the contactless card 300 may include a dual-interface contactless payment card.

[0073] The contactless card 300 may include a substrate 310, which may include a single layer or one or more laminates made of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 300 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7810 standard, and the contactless card 300 may otherwise conform to the ISO / IEC 14443 standard. However, it should be understood that the contactless card 300 according to this disclosure may have different characteristics, and this disclosure does not require the contactless card 300 to be implemented as a payment card.

[0074] The contactless card 300 may also include identification information 315 displayed on the front and / or back of the contactless card 300, and a contact pad 320. The contact pad 320 may be configured to establish contact with another communication device, such as a user equipment, smartphone, laptop, desktop computer, or tablet computer. The contactless card 300 may also include processing circuitry, an antenna, and other components. These components may be located behind the contact pad 320 or elsewhere on the substrate. The contactless card 300 may also include a magnetic stripe or magnetic tape, which may be located on the back of the contactless card 300.

[0075] Figure 3B An example contact pad 320 of a contactless card 300 is shown. The contact pad 320 of the contactless card 300 may include processing circuitry 325 for storing and processing information, including a processor 330 and a memory 335. It should be understood that the processing circuitry 325 may include additional components necessary to perform the functions described herein, including a processor, memory, error and parity / CRC checkers, a data encoder, anti-collision algorithms, a controller, a command decoder, security primitives, and tamper-proof hardware.

[0076] Memory 335 can be read-only memory, write-multiple-read memory, or read / write memory, such as RAM, ROM, and EEPROM, while the contactless card 300 may include one or more of these memories. Read-only memory can be factory-programmed to be read-only or programmable only once. One-time programmability provides the opportunity to write once and then read many times. Write-multiple-read memory can be programmed at some point after the memory chip leaves the factory. Once programmed, the memory cannot be rewritten, but it can be read multiple times. Read / write memory can be programmed and reprogrammed many times after leaving the factory. It can also be read multiple times.

[0077] In some embodiments, memory 335 may also store public and private card encryption keys. In some embodiments, the private and public encryption keys may be permanently hardwired into memory 335. In various embodiments, memory 335 may store instructions for generating encrypted information and transmitting it to a receiving device (e.g., first device 110). Such encrypted information may be or include encrypted verification blocks or signatures that can be used to authenticate and verify the presence of contactless card 300 during transaction processing. In some embodiments, the encrypted information may be unique for a specific communication (e.g., a specific NFC transmission of contactless card 300).

[0078] Memory 335 may be configured to store one or more applets 340, one or more counters 345, and a unique customer identifier 350. The one or more applets 340 may include one or more software applications, such as Java card applets, configured to execute on one or more contactless cards. As described above, the one or more applets 340 may be configured to disable the contactless card 300. However, it should be understood that the one or more applets 340 are not limited to Java card applets, but may be any software application that can operate on a contactless card or other device with limited memory. The one or more counters 345 may include numeric counters sufficient to store integers. The unique customer identifier 350 may include a unique alphanumeric identifier assigned to 300 users of the contactless card, and the unique customer identifier 350 distinguishes users of the contactless card 300 from users of other contactless cards, and therefore may be a general identifier for the card's users. In some examples, the customer identifier 350 may identify both the customer and the account assigned to that customer, and may also identify the contactless card 300 associated with the customer's account.

[0079] The processor 330 and memory 335 elements of the exemplary embodiments described above are described with reference to contact pad 320, but this disclosure is not limited thereto. It should be understood that these elements may be implemented outside of contact pad 320, or completely separated from it, or as further elements beyond the processor 330 and memory 335 elements located within contact pad 320.

[0080] In some examples, the contactless card 300 may include one or more antennas 355. The one or more antennas 355 may be placed within the contactless card 300 and around the processing circuitry 325 of the contact pad 320. For example, the one or more antennas 355 may be integrated with the processing circuitry 325, and the one or more antennas 355 may be used in conjunction with an external gain coil. As another example, the one or more antennas 355 may be located outside the contact pad 320 and the processing circuitry 325.

[0081] In one embodiment, the coil of the contactless card 300 can act as the secondary winding of an air-core transformer. A terminal (such as the first device 110 or a user's user equipment) can communicate with the contactless card 300 by cutting off power or amplitude modulation. The contactless card 300 can infer data transmitted from the terminal using gaps in the contactless card's power connection, the function of which can be maintained by one or more capacitors. The contactless card 300 can perform reverse communication by switching loads or load modulation on the coil of the contactless card. Load modulation can be detected in the terminal coil by interference.

[0082] As explained above, the contactless card 300 can be built on a software platform that operates on smart cards or other devices with limited memory, such as JavaCards, and can securely execute one or more applications or applets (e.g., applet 340). Applets can be added to the contactless card to provide a one-time password (OTP) for multi-factor authentication (MFA) in various mobile application-based use cases. Applets can be configured to respond to one or more requests from a reader, such as a near-field data exchange request, and generate an NDEF message that includes an encrypted secure OTP encoded as an NDEF text tag.

[0083] The contactless card 300 can be configured to communicate with a first device 110 or a user's device via a communication interface configured to establish communication with the first device 110 or the user's device. The communication interface can be configured for contact-based communication, in which case the interface can have electronic circuitry and contact pads on the surface of the contactless card 300 for establishing direct electrical communication between the contactless card 300 and the first device 110 or the user's device. Alternatively or additionally, the communication interface can be configured for contactless communication with the first device 110 or the user's device. In such embodiments, the communication interface may be or include an NFC communication interface configured to communicate with other NFC communication devices when the contactless card 300 is within a predetermined NFC range. In some embodiments, the contactless card 300 may include a second communication interface configured to establish short-range communication with the first device 110 or the user's device via Bluetooth or other short-range communication methods. In such embodiments, the contactless card 300 may have a short-range communication antenna included in or connected to the short-range communication interface. The contactless card 300 may also include a power management system for managing power distribution during NFC transactions.

[0084] The contactless card 300 can be configured to transmit encrypted text to the first device 110 or the user's user device when tapped. The first device 110 or the user's user device can be configured to read the encrypted text from the contactless card 300 after it enters the communication field of the first device 110 or the user's user device. The first device 110 or the user's user device can then transmit the encrypted text to the server 130. The server 130 can be configured to verify the encrypted text by searching the database 140.

[0085] Figure 4 A flowchart of an example method 400 for disabling contactless cards according to an example embodiment is shown. Figure 4 Can be quoted and Figure 1 , Figure 2 , Figure 3A and Figure 3B The same or similar components shown include the first device and / or user equipment, server, database, second device, and contactless card. Method 400 can be implemented in system 100 and may include, but is not limited to, the following steps.

[0086] As described above, when a user wants to make an online or offline purchase, the user can be asked to tap the contactless card 160 against the first device 110. In response, after the contactless card 160 enters the NFC communication field of the first device 110, the contactless card 160 transmits NFC response information (e.g., ciphertext) to the first device 110 that can be used by the server 130 to authenticate the user / contactless card 160. The ciphertext includes a unique identifier for the contactless card 160, which can be used as a general identifier for the user. The first device 110 can transmit the ciphertext to a second device 120. The second device 120 can be a device associated with a merchant, such as a merchant server that communicates with the first device 110 (the user's mobile device or the merchant's point-of-sale terminal). The second device 120 transmits the ciphertext to the server 130. Therefore, at step 405, the server 130 receives the ciphertext of the contactless card 160.

[0087] At step 410, server 130 can authenticate the contactless card based on the encrypted message. Server 130 can decrypt the encrypted message and extract the unique identifier of contactless card 160 through its card authentication module. Server 130 can verify the unique identifier of contactless card 160 by searching database 140. Server 130 can authenticate the user / contactless card 160 based on the unique identifier of contactless card 160.

[0088] After the contactless card 160 is authenticated, at step 415, the server 130 can retrieve a fraud risk profile associated with the contactless card 160 from the database 140. This fraud risk profile may include fraud risk data associated with the user. The fraud risk profile, generated using a fraud risk machine learning model, can indicate the contactless card user's trust level (also referred to as risk level) as a fraudster. Trust levels can be numerical levels, such as from 1 to 5, where 1 is the lowest trust level and 5 is the highest. Trust levels can also be categorized as low trust, medium trust, and high trust.

[0089] In step 420, server 130 may determine that a contactless card is fraudulent based on a trust level determined from a fraud risk profile. The trust level may also be determined based on data indicating the likelihood of fraud during the transaction; the contactless card being reported lost; the contactless card being reported stolen; and / or fraud on the contactless card being reported to a bank.

[0090] At step 425, when it is determined that the contactless card is fraudulent, server 130 may disable the contactless card. The contactless card can be disabled in a variety of ways, some of which are reversible and others are permanent (e.g., breaking the contactless card).

[0091] At step 430, server 130 may transmit a notification to second device 120 that the contactless card is disabled. Then, second device 120 may transmit a notification to first device 110 that the contactless card is disabled, thereby informing the user of contactless card 160 that contactless card 160 has been disabled due to potential fraud.

[0092] Figure 5A flowchart of an example method 500 for determining a contactless card as fraudulent according to an example embodiment is shown. In block 505, server 130 may retrieve a fraud risk profile associated with contactless card 160. This fraud risk profile may include fraud risk data associated with a user. The fraud risk profile may indicate the trust level (also referred to as risk level) of the user of contactless card 160 as a fraudster. The trust level may be a numerical level, such as from 1 to 5, where 1 is the lowest trust level and 5 is the highest trust level. Trust levels may also be categorized as low trust level, medium trust level, and high trust level. Server 130 may compare the trust level to a predetermined trust level threshold. When it is determined that the trust level score of contactless card 160 is below the trust level threshold, contactless card 160 may be determined to be fraudulent. In block 510, server 130 may determine whether contactless card 160 is lost. For example, the user of contactless card 160 may report that contactless card 160 has been lost to a bank associated with server 130. In box 515, server 130 can determine that the contactless card has been stolen. For example, a user of contactless card 160 can report that contactless card 160 has been stolen to a bank associated with server 130. In box 520, server 130 can determine whether contactless card 160 is fraudulent when one or more of boxes 505, 510, and 515 are true.

[0093] Figure 6 A flowchart of an example method 600 for disabling a contactless card according to an example embodiment is shown. When a contactless card is determined to be fraudulent, server 130 can disable the contactless card. The contactless card can be disabled in various ways, some reversibly and others permanently (e.g., breaking the contactless card). Disabling methods may include, but are not limited to: covering the EMV applet of the contactless card (as shown in box 605), which can permanently disable the contactless card; changing the public key of the contactless card to prevent initial authorization (as shown in box 610), which may permanently disable the contactless card; deleting the public and private keys of the contactless card (as shown in box 615); changing the private key of the contactless card (as shown in box 620), which can be changed back to reactivate the contactless card; and modifying the EMV payment applet to accept a temporary disable signal (as shown in box 625), which can be achieved by sending a signature command to the contactless card, and the contactless card can use an embedded public key to verify the signature of the signed command. In some embodiments, the disabling method can be performed according to... Figure 6 The methods are executed in the order shown; however, it is understood that the disabling methods may be executed in a different order in other embodiments. Furthermore, it should be understood that only a subset of the disabling methods may be executed in other embodiments.

[0094] Figure 7 A flowchart of an example method 700 for disabling contactless cards according to an example embodiment is shown. Figure 7 Can be quoted and Figures 1 to 6 The same or similar components shown include a first device and / or user equipment, a server, a database, a second device, and a contactless card. Method 700 can be implemented in system 100 and may include, but is not limited to, the following steps.

[0095] As described above, a trust level signal can be added to the encrypted message of the contactless card, which is transmitted with each transaction. The contactless card app can include such a protocol to include the trust level signal in the encrypted message. For example, trust level 4 could mean that all content on the contactless card is accepted, while trust level 0 could indicate that the contactless card may be fraudulent.

[0096] At step 705, server 130 determines whether the contactless card's trust level is lower than a first trust level threshold. If server 130 determines that the contactless card's trust level is lower than the first trust level threshold, then at step 710, server 130 may reduce the limit on a single transaction, for example, from $200 / transaction to $50 / transaction, and this means that any transaction exceeding $50 will not be allowed. For example, in the first transaction, the contactless card's trust level could be level 2, lower than the first trust level threshold (e.g., trust level 4).

[0097] At step 715, server 130 determines whether the trust level of the contactless card is lower than a second trust level threshold. This second trust level threshold is lower than a first trust level threshold. For example, the first trust level threshold could be trust level 4, and the second trust level threshold could be trust level 2. If server 130 determines that the trust level of the contactless card is lower than the second trust level threshold, then at step 715, server 130 can disable the contactless card. For example, at the second transaction, the trust level of the contactless card could be level 0, which is lower than the second trust level threshold (trust level 2). This can trigger the SDK to transmit a disable command to the contactless card to disable it.

[0098] In some embodiments, if the fraud risk profile of the contactless card improves, commands from the SDK can be written to the contactless card to raise its trust level to a more trusted level; for example, the trust level of the contactless card can be raised from level 0 to level 2. If the trust level of the contactless card is raised, for example, above a second trust level threshold, the contactless card can be reactivated by the server 130 via the SDK.

[0099] In some aspects, the technology described herein relates to a method for disabling contactless cards to prevent fraud, the method comprising: determining that the contactless card is fraudulent, including at least one selected from the group consisting of: determining that the trust level score of the contactless card is below a trust level threshold, determining that the contactless card has been lost, and determining that the contactless card has been stolen; and disabling the contactless card, including at least one selected from the group consisting of: overwriting a mini-program on the contactless card, changing the public key on the contactless card, deleting the public and private keys on the contactless card, changing the private key on the contactless card, and modifying the payment mini-program on the contactless card to accept a temporary disable signal.

[0100] In some respects, the technology described herein relates to a method in which the mini-program on the contactless card is an EMV mini-program.

[0101] In some respects, the technology described herein relates to a method in which an applet covering a contactless card permanently disables the contactless card.

[0102] In some respects, the techniques described herein relate to a method that also includes recovering the private key on a contactless card to reactivate the contactless card.

[0103] In some respects, the techniques described herein relate to a method that also includes: establishing a fraud profile for contactless cards; and generating a trust level score for contactless cards based on the fraud profile.

[0104] In some respects, the techniques described herein relate to a method in which changing the public key on a contactless card results in no initial authorization occurring on the contactless card.

[0105] In some respects, the technology described herein relates to a method in which contactless cards are disabled via near field communication (NFC) from a telephone.

[0106] In some respects, the technology described herein relates to a method in which changing the public key on a contactless card permanently disables the contactless card.

[0107] In some aspects, the technology described herein relates to a system for disabling contactless cards to prevent fraud, including a server, wherein the server includes a processor and memory coupled to the processor, and the server is configured to: determine that a contactless card is fraudulent, including at least one selected from the group consisting of: determining that the trust level score of the contactless card is below a trust level threshold, determining that the contactless card has been lost, and determining that the contactless card has been stolen; and disable the contactless card, including at least one selected from the group consisting of: overwriting a mini-program on the contactless card, changing the public key on the contactless card, deleting the public and private keys on the contactless card, changing the private key on the contactless card, and modifying the payment mini-program on the contactless card to accept a temporary disable signal.

[0108] In some respects, the technology described herein relates to a system in which the server is also configured to send a signature command to a contactless card to temporarily disable the contactless card.

[0109] In some respects, the technology described herein relates to a system in which the server is also configured to enable contactless cards to verify signatures using an embedded public key in a signed command.

[0110] In some respects, the technology described herein relates to a system in which contactless cards are disabled via a software development kit (SDK) embedded in a merchant's website.

[0111] In some respects, the technology described herein relates to a system in which an SDK communicates with a server via one or more application programming interfaces (APIs).

[0112] In some respects, the technology described herein relates to a system in which the challenge and public key are held by a server and communicated to an SDK via one or more APIs.

[0113] In some respects, the techniques described herein relate to a system in which public-key cryptography is used for mutual authentication between contactless cards and SDKs.

[0114] In some aspects, the technology described herein relates to a non-transitory computer-readable medium comprising: instructions for disabling a contactless card to prevent fraud, which, when executed on a computer device, perform actions including: determining that the contactless card is fraudulent, including at least one selected from the group consisting of: determining that the trust level score of the contactless card is below a trust level threshold, determining that the contactless card is lost, and determining that the contactless card has been stolen; and disabling the contactless card, including at least one selected from the group consisting of: overwriting a applet on the contactless card, changing the public key on the contactless card, deleting the public and private keys on the contactless card, changing the private key on the contactless card, and modifying the payment applet on the contactless card to accept a temporary disable signal.

[0115] In some respects, the techniques described herein relate to a non-transitory computer-readable medium in which the disabling of contactless cards is accomplished via a software development kit (SDK) embedded in a merchant's website.

[0116] In some respects, the technology described herein relates to a non-transitory computer-readable medium in which a contactless card exchanges a digital certificate containing its public key with an SDK, which opens a secure communication channel between the contactless card and the SDK.

[0117] In some respects, the techniques described herein relate to non-transitory computer-readable media in which the SDK establishes fraud profiles of users associated with contactless cards.

[0118] In some respects, the techniques described herein relate to non-transitory computer-readable media in which website cookies or IP addresses are used to assess a user's fraud profile.

[0119] As used herein, the terms “bank” and “financial institution” are not limited to a particular bank or financial institution or a particular type of bank or financial institution. Rather, it should be understood that this disclosure includes any type of bank, financial institution, or other enterprise involved in the sale or otherwise provision of products or services.

[0120] As used herein, the term "merchant" is not limited to a specific merchant or type of merchant. Rather, it should be understood that this disclosure includes any type of merchant, supplier, or other entity involved in the sale or otherwise provision of products or services.

[0121] As used herein, the term "account" is not limited to a specific type of account. Rather, it should be understood that the term "account" can refer to a variety of accounts, including but not limited to financial accounts (e.g., credit accounts, debit accounts), membership accounts, loyalty accounts, subscription accounts, service accounts, utility accounts, transportation accounts, and physical access accounts. It should also be understood that this disclosure is not limited to accounts issued by a specific entity.

[0122] As used herein, the term "card" is not limited to a particular type of card. Rather, it should be understood that, unless otherwise indicated, the term "card" can refer to a contact-based card, a contactless card, or any other card. Further, this disclosure is not limited to cards for a specific purpose (e.g., payment cards, gift cards, ID cards, membership cards, transportation cards, access cards), cards associated with a specific type of account (e.g., credit accounts, debit accounts, membership accounts), or cards issued by a specific entity (e.g., commercial entities, financial institutions, government entities, or social clubs). Rather, it should be understood that this disclosure includes cards for any purpose, account associated with, or issued by any entity.

[0123] In some examples, exemplary programs according to this disclosure described herein can be executed by processing means and / or computing means (e.g., computer hardware means). Such processing and / or computing means can be, for example, all or part of a computer / processor, or include, but are not limited to, a computer / processor that may include, for example, one or more microprocessors, and uses instructions stored on computer-accessible media (e.g., RAM, ROM, hard disk drives, or other storage devices). For example, the computer-accessible media may be part of the memory of a first device, user equipment, server, or other computer hardware means.

[0124] In some examples, a computer-accessible medium (e.g., a storage device as described herein, such as a hard disk, floppy disk, memory stick, CD-ROM, RAM, ROM, etc., or a combination thereof) may be provided (e.g., to communicate with a processing device and / or a computing device). The computer-accessible medium may contain executable instructions thereon. Additionally, or alternatively, a storage device may be provided separately from the computer-accessible medium, which may provide instructions to the processing device to configure the processing device, for example, to perform certain exemplary programs, processes, and methods as described above herein.

[0125] It should be further noted that the systems and methods described herein can be tangibly embodied in one or more physical media, such as, but not limited to, optical discs (CDs), digital versatile optical discs (DVDs), floppy disks, hard disks, read-only memory (ROM), random access memory (RAM), and other physical media capable of storing data. For example, data storage devices may include random access memory (RAM) and read-only memory (ROM), which can be configured to access and store data and information, as well as computer program instructions. Data storage may also include storage media or other suitable types of storage (such as, for example, RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), disks, optical discs, floppy disks, hard disks, removable magnetic tape cassettes, flash drives, and any type of tangible and non-transitory storage media), in which files constituting an operating system, applications (including, for example, web browser applications, email applications, and / or other applications), and data files can be stored. Data storage devices for network-enabled computer systems can include electronic information, files, and documents stored in various ways, including, for example, flat files, indexed files, hierarchical databases, relational databases such as those created and maintained using software from, for example, Oracle® Corporation, Microsoft® Excel files, Microsoft® Access files, solid-state storage devices (which may include flash arrays, hybrid arrays, or server-side products), enterprise storage (which may include online or cloud storage), or any other storage mechanism. Furthermore, these diagrams illustrate various components (e.g., servers, computers, processors, etc.). Functions described as performing at various components can be performed at other components, and the components can be combined or separated. Other modifications are also possible.

[0126] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing and / or processing devices, or downloaded to external computers or external storage devices via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). This network may include copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the corresponding computing and / or processing device.

[0127] Computer-readable program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and similar languages, and traditional procedural programming languages ​​such as the "C" programming language or similar languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be established to an external computer (e.g., via the Internet through an Internet service provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) may be personalized using state information from the computer-readable program instructions to perform aspects of the invention.

[0128] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for carrying out the functions specified herein. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, and / or other device to operate in a certain manner, such that the computer-readable storage medium in which the instructions are stored constitutes an article of writing comprising instructions for carrying out aspects of the functions specified herein.

[0129] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus or other device to perform a series of operational steps on the computer, other programmable apparatus or other device, thereby producing a computer-implemented process, such that the instructions executed on the computer, other programmable apparatus or other device perform the function specified herein.

[0130] Implementations of the various techniques described herein can be carried out in digital electronic circuits, or in computer hardware, firmware, software, or combinations thereof. Implementations can be carried out as computer program products, i.e., computer programs tangibly embodied in an information carrier, such as in a machine-readable storage device or in a propagating signal, for execution or control of their operation by a data processing apparatus (e.g., a programmable processor, a computer, or multiple computers). Computer programs (such as one or more computer programs described above) can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as standalone programs or as modules, components, subroutines, or other units suitable for use in a computing environment. Computer programs can be deployed to execute on a single computer, or on multiple computers at a single site or distributed across multiple sites and interconnected via a communication network.

[0131] The method steps can be executed by one or more programmable processors that execute one or more computer programs to perform functions by manipulating input data and generating output. The method steps can also be executed by special-purpose logic circuitry (e.g., FPGA (Field-Programmable Gate Array) or ASIC (Application-Specific Integrated Circuit)), and the apparatus can be implemented as special-purpose logic circuitry.

[0132] Throughout this disclosure, unless the context clearly specifies otherwise, the following terms will have at least the meaning explicitly relevant herein. The term “or” means containing “or”. Furthermore, the terms “a,” “an,” and “the” mean one or more, unless otherwise specified or the context clearly indicates that they refer to the singular form.

[0133] Numerous specific details have been set forth in this specification. However, it should be understood that embodiments of the disclosed technology can be practiced without these specific details. In other instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this description. References to “some examples,” “other examples,” “an example,” “example,” “various examples,” “an embodiment,” “an embodiment,” “some embodiments,” “example embodiments,” “various embodiments,” “an implementation,” “implementation,” “example implementation,” “various implementations,” “some implementations,” etc., indicate that one or more embodiments of the disclosed technology thus described may include a particular feature, structure, or characteristic, but not every embodiment must include that particular feature, structure, or characteristic. Furthermore, the repeated use of the phrases “in an example,” “in an embodiment,” or “in an implementation” does not necessarily refer to the same example, embodiment, or implementation, although it may.

[0134] As used herein, unless otherwise specified, the use of ordinal adjectives such as “first,” “second,” “third,” etc., to describe common objects merely indicates that different instances of similar objects are referenced, and does not imply that the objects described must be in a given sequence in time, space, rank, or any other way.

[0135] While some embodiments of the disclosed technology have been described in conjunction with what are currently considered the most practical and varied implementations, it should be understood that the disclosed technology is not limited to the disclosed embodiments and is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims. Although specific terms are used herein, they are used only in a general and descriptive sense and not for limiting purposes.

[0136] This written description uses examples to disclose certain embodiments of the disclosed technology, including best practices, and also enables those skilled in the art to practice certain embodiments of the disclosed technology, including making and using any device or system and performing any combined methods. The patentable scope of certain embodiments of the disclosed technology is defined in the claims and may include other examples that would occur to those skilled in the art. Such other examples are intended to fall within the scope of the claims if they have structural elements that are indistinguishable from the literal language of the claims, or if they include equivalent structural elements that differ only in non-substantially from the literal language of the claims.

Claims

1. A method for disabling contactless cards to prevent fraud, the method comprising: Determining that the contactless card is fraudulent includes selecting at least one of the following: determining that the trust level score of the contactless card is below a trust level threshold, determining that the contactless card has been lost, and determining that the contactless card has been stolen; as well as Disabling the contactless card includes at least one of the following: overwriting the app on the contactless card, changing the public key on the contactless card, deleting the public and private keys on the contactless card, changing the private key on the contactless card, and modifying the payment app on the contactless card to accept a temporary disable signal.

2. The method according to claim 1, wherein, The mini-programs on the contactless card are Europay, Mastercard, and Visa (EMV) mini-programs.

3. The method according to claim 1, wherein, Covering the contactless card with a mini-program will permanently disable the contactless card.

4. The method of claim 1, further comprising recovering the private key on the contactless card to reactivate the contactless card.

5. The method according to claim 1, further comprising: Establish a fraud profile for the contactless card; as well as A trust level score for the contactless card is generated based on the fraud profile.

6. The method according to claim 1, wherein, Changing the public key on the contactless card results in no initial authorization occurring on the contactless card.

7. The method according to claim 1, wherein, The contactless card was disabled via Near Field Communication (NFC) from a telephone.

8. The method according to claim 1, wherein, Changing the public key on the contactless card will permanently disable the contactless card.

9. A system for disabling contactless cards to prevent fraud, the system comprising a server, wherein, The server includes a processor and memory coupled to the processor, and the server is configured to: Determining that the contactless card is fraudulent includes selecting at least one of the following: determining that the trust level score of the contactless card is below a trust level threshold, determining that the contactless card has been lost, and determining that the contactless card has been stolen; as well as Disabling the contactless card includes selecting at least one of the following: overwriting the app on the contactless card, changing the public key on the contactless card, deleting the public and private keys on the contactless card, changing the private key on the contactless card, and modifying the payment app on the contactless card to accept a temporary disable signal.

10. The system according to claim 9, wherein, The server is further configured to send a signed command to the contactless card to temporarily disable the contactless card.

11. The system according to claim 10, wherein, The server is also configured to enable the contactless card to verify the signature using an embedded public key in a signed command.

12. The system according to claim 9, wherein, Disabling the contactless card is done through a software development kit (SDK) embedded in the merchant's website.

13. The system according to claim 12, wherein, The SDK communicates with the server via one or more application programming interfaces (APIs).

14. The system according to claim 13, wherein, The challenge and public key are held by the server and communicated to the SDK via one or more APIs.

15. The system according to claim 12, wherein, Public-key cryptography is used for mutual authentication between the contactless card and the SDK.

16. A non-transitory computer-readable medium comprising instructions for disabling contactless cards to prevent fraud, the instructions, when executed on a computer device, performing actions including: Determining that the contactless card is fraudulent includes selecting at least one from the group consisting of: determining that the trust level score of the contactless card is below a trust level threshold, determining that the contactless card has been lost, and determining that the contactless card has been stolen; and Disabling the contactless card includes selecting at least one of the following: overwriting the app on the contactless card, changing the public key on the contactless card, deleting the public and private keys on the contactless card, changing the private key on the contactless card, and modifying the payment app on the contactless card to accept a temporary disable signal.

17. The non-transitory computer-readable medium according to claim 16, wherein, Disabling the contactless card is done via a software development kit (SDK) embedded in the merchant's website.

18. The non-transitory computer-readable medium according to claim 17, wherein, The contactless card exchanges a digital certificate containing its public key with the SDK, which opens a secure communication channel between the contactless card and the SDK.

19. The non-transitory computer-readable medium according to claim 17, wherein, The SDK establishes fraud profiles for users associated with the contactless card.

20. The non-transitory computer-readable medium according to claim 19, wherein, Website cookies or Internet Protocol (IP) addresses are used to assess the user's fraud profile.

Images