A technology for storing and processing data for trial transactions using trading cards.

Abstract

The present invention provides a computing device, trading card, system, and method for storing and processing data for trial trading using a trading card. [Solution] In the computing system 100, data related to each transaction attempt collected by the transaction card 102 is provided to the transaction system 106 through the transaction terminal 108 and the computing device 104, and the transaction system 106 detects the failure and notifies the customer and operator of the transaction terminal 108.

Description

Technical Field

[0001] This application claims priority to U.S. Non-Provisional Application No. 16 / 863,437, filed Apr. 30, 2020, entitled "Techniques for Storing and Processing Data for Trials of Transactions with Transaction Cards", the content of which is hereby incorporated by reference in its entirety.

Background Art

[0002] Payment cards, such as credit cards and debit cards, are widely used in all forms of financial transactions. The use of payment cards has greatly evolved with recent technological developments. Originally, transactions were conducted on paper and verified by an imprint of the transaction card and a signature. This approach has been largely replaced by passing the magnetic stripe of the transaction card through a magnetic stripe reader of a POS (Point of Sales) terminal to conduct the transaction. Transaction cards have been developed to include an integrated circuit ("chip card" or "smart card") and communicate with a smart card reader of a POS terminal. In this method, typically, the transaction is verified by a personal identification number (PIN) entered by the card user. This type of card is usually operated under the EMV standard regarding the interoperability of chip cards and related devices (such as POS terminals and ATMs). ISO / IEC 7816 provides standards regarding the operation of this type of card.

[0003] Furthermore, contactless payment cards are being developed. These cards typically allow POS terminals to automatically read account numbers from the card using short-range wireless technologies such as radio frequency identification (RFID). One specific method of contactless payment utilizes near-field communication (NFC). However, NFC and other RF technologies used for transactions may not be adopted for various reasons. For example, users may not perceive compatibility, may not know how to perform transactions using NFC, or the transaction terminal may not be properly configured. The embodiments discussed here generally aim to resolve issues related to the trial of contactless transactions. [Overview of the project]

[0004] Embodiments may generally be directed toward technologies and systems for detecting errors or anomalies in contactless transaction processing. These systems may include transaction cards, POS (Point-of-Sale) terminals, and transaction processing systems. For example, an embodiment may include a transaction card that includes a plurality of interfaces, a processor, and memory for storing instructions. In an embodiment, the processor may process instructions to detect a transaction attempt through one of the plurality of interfaces, determine data related to the transaction attempt, the data including a timestamp related to the transaction attempt and the interface type of the interface on which the transaction attempt was detected, and store the data related to the transaction attempt in memory. The processor may detect a read of data by a computing device made through one of the plurality of interfaces, generate encrypted data from the data related to the transaction attempt stored in memory, and provide the encrypted data to the computing device through the interface on which the read was detected.

[0005] Embodiments may also include a transaction processing system including a processor, storage including a data store, and memory for storing instructions. The processor processes instructions and processes incoming data associated with multiple transaction attempts executed on a transaction card associated with a user account, the data including entries associated with the transaction attempts, each entry for each transaction attempt including a timestamp of the transaction attempt and the interface type of the transaction attempt, the processor stores the data in the data store, determines interface information for one or more interfaces of the transaction card based on the data, the interface information indicates anomalies and interface usage statistics associated with one or more interfaces, and takes action based on the interface information. [Brief explanation of the drawing]

[0006] [Figure 1] Figure 1 shows a computing system 100 according to one embodiment.

[0007] [Figure 2] Figure 2 shows a transaction card 102 according to one embodiment.

[0008] [Figure 3] Figure 3 shows a transaction card component 300 according to one embodiment.

[0009] [Figure 4] Figure 4 shows a sequence flow 400 according to one embodiment.

[0010] [Figure 5] Figure 5 shows an NDEF message 500 according to one embodiment.

[0011] [Figure 6] Figure 6 shows a logic flow 600 according to one embodiment.

[0012] [Figure 7]Figure 7 shows a logic flow 700 according to one embodiment.

[0013] [Figure 8] Figure 8 shows data 800 according to one embodiment.

[0014] [Figure 9] Figure 9 shows a computer architecture 900 according to one embodiment.

[0015] [Figure 10] Figure 10 shows a communication architecture 1000 according to one embodiment. [Modes for carrying out the invention]

[0016] To facilitate discussion of specific elements or actions, the most significant digit of the reference number indicates the figure number in which that element was first introduced.

[0017] Figure 1 shows an example configuration of a computing system 100 that processes and communicates transaction-related data and detects problems in one or more components of a transaction processing system. The computing system 100 may include numerous systems, devices, etc., including a transaction system 106, a computing device 104, a transaction card 102, and one or more transaction terminals 108. The components are connected via one or more network connections, including wired and wireless network connections, and can communicate data. Note that for simplification, the computing system 100 is illustrated with a limited number of components and connections, and the computing system 100 may include additional computing and communication components not shown.

[0018] In an embodiment, the computing system 100 may be part of a banking system or a transaction processing system that enables a user to purchase goods or services using a transaction card. For example, the user may use the transaction card 102 at the transaction terminal 108 or a point-of-sale (POS) terminal by inserting the transaction card 102 into the transaction terminal 108, swiping the transaction card 102 at the transaction terminal 108, and / or tapping the transaction card 102 at the transaction terminal 108. The transaction terminal 108 may communicate with the transaction system 106 to process the transaction. Through these operations, data may be communicated among the transaction card 102, the transaction terminal 108, and / or the transaction system 106. For example, the transaction terminal 108 may include an EMV (Europay, Mastercard, Visa) interface that can be coupled to the EMV interface of the transaction card 102 to exchange data for executing the transaction. In another example, the transaction terminal 108 may include a magnetic stripe interface configured to read the magnetic stripe of the transaction card 102 for executing the transaction. In a third example, the transaction card 102 may include a near-field communication (NFC) interface that wirelessly couples and communicates with the NFC interface of the transaction card 102 for executing the transaction. In the normal operation, the transaction terminal 108 may exchange data and information with the transaction card 102 and execute a verification / validation routine with the transaction system 106 to execute the transaction.

[0019] In an example, a trial of a transaction may fail for one reason or another, such as a failed verification / confirmation, corrupted data, reading of bad data, interference, an improperly configured terminal, etc. Usually, the user may notice the failed trial of the transaction but may not know the cause. In other examples, the user may not even notice the trial of the transaction. Therefore, the embodiment is directed to enabling the transaction card 102 to collect data related to each trial of a transaction, provide the data to the transaction system 106 to detect a failure, and notify the customer and the operator of the transaction terminal 108.

[0020] In some embodiments, the trading card 102 may include an applet for collecting data for each trading attempt. The data may be collected based on information in the card's memory and / or by communicating with a trading terminal. The trading card 102 may, from time to time, transmit the collected data to another device for a system to analyze the data. For example, the trading card 102 may exchange information, such as the collected data, with a computing device 104, which may be a mobile phone. The computing device 104 may exchange information with the trading system 106, including transmitting the collected data to the trading system 106. The collected data may include information about each trading attempt, such as a timestamp of the trading attempt, a trading identifier to identify the trading attempt, a trading terminal identifier to identify the trading terminal for the trading attempt, and an interface type to identify the interface used for the trading attempt.

[0021] In the embodiment, the transaction system 106 may perform a data analysis routine on the data collected by the transaction card and transaction terminal. The data analysis routine may determine usage statistics based on the data, such as the number of times a user or customer encountered a contactless (NFC) transaction terminal, the number of times a user used a contactless NFC transaction terminal for contactless (NFC) payment, the number of times a customer encountered a contactless payment terminal and failed to make a contact (EMV / swipe) payment, and the number of failed transaction attempts that the user indicated as “given up.” This data may be used to detect problems with the payment card or payment terminal.

[0022] In an embodiment, the transaction system 106 may utilize usage statistics to provide insights to users and owners of transaction cards and transaction terminals. In some examples, data analysis routines may be used to determine detailed insights and detect patterns. For example, a data analysis routine may recognize usage patterns where a user attempts to execute a transaction using the NFC interface, the transaction attempt fails, and the user switches to another method (swipe or EMV interface) to execute the transaction. This pattern may be detected based on multiple consecutive transaction attempts on a transaction terminal for a transaction card with close time stamps (within a configurable retry transaction threshold), for example, attempts corresponding to the NFC interface and attempts corresponding to the EMV interface. The transaction system may consider that there is an abnormality or problem with the NFC interface of the transaction card if the pattern occurs with the same transaction card at different transaction terminals.

[0023] Similarly, based on a data analysis routine, the transaction system 106 may determine that there is a problem with the transaction terminal if a similar pattern is detected at the same transaction terminal but with different transaction cards. More specifically, the transaction system 106 can detect multiple consecutive transaction attempts with close time stamps on a transaction terminal for multiple transaction cards (above a configurable retry transaction threshold).

[0024] In an embodiment, the transaction system 106 may detect anomalies based on other statistics. For example, if the number of times a certain user uses the NFC interface of their transaction card is statistically less than that of other similar users, such as those in the same region, gender, age group, etc. The transaction system 106 may determine that there is a problem with the customer's transaction card or that the customer needs instructions on how to execute transactions using the contactless NFC interface. In another example, the transaction system may determine that there is a problem or anomaly with the transaction terminal if the transaction terminal is being used in a statistically different manner from similar terminals, for example, at the same location, the same type of location / facility, etc.

[0025] The trading system 106 may perform data analysis routines that include applying machine learning to the data, and that include scoring the data with a model to detect anomalies in trading cards and / or trading terminals. For example, the data analysis routine may include applying supervised or unsupervised machine learning techniques to detect patterns in the data that may indicate problems with trading cards or terminals. The machine learning may include training one or more models on known datasets (created / generated) or actual datasets to detect patterns. Embodiments are not limited thereto.

[0026] In embodiments, the trading system 106 may trigger one or more actions based on the detection of anomalies or problems based on data analysis routines applied to the data. For example, if the trading system 106 determines that there is a problem with the interface for the trading card, it may cause the user to issue a new trading card. In another embodiment, if the trading system determines that the NFC interface is functioning properly, but the user appears not to know how to use it correctly, for example, based on periodic successful attempts, it may send instructions on the proper way to use the NFC interface. In a third embodiment, the trading system may send a message to the operator of the trading terminal indicating that the interface is malfunctioning and / or improperly configured. Embodiments are not limited to these examples, and other improvement operations may be performed.

[0027] Figure 2 shows an example configuration of the transaction card 200, which may include a payment card such as a contactless card, credit card, debit card, or gift card issued by a service provider, as displayed on the front or back of the transaction card 200 as a service provider marking 202. In some embodiments, the transaction card 200 is the same as the transaction card 102 illustrated in Figure 1. In some examples, the transaction card 200 may include an identification card, not limited to, and not related to a payment card. In some examples, the transaction card 200 may include a dual-interface contactless payment card, a rewards card, etc. The transaction card 200 may include a substrate 208 which may include a single layer or one or more laminated layers made of plastic, metal, and other materials. Examples of substrates 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 transaction card 200 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7816 standard, or it may otherwise conform to the ISO / IEC 14443 standard. However, the transaction card 200 provided in this disclosure may have different characteristics, and it should be understood that this disclosure does not require the transaction card 200 to be implemented in a settlement card.

[0028] The transaction card 200 may also include identification information 206 displayed on the front and / or back of the card, and contact pads 204. The contact pads 204 may include one or more pads and be configured to establish contact via the transaction card with other client devices such as ATMs, user devices, smartphones, laptops, desktops, transaction terminals, POS terminals, or tablet computers. The contact pads 204 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 transaction card 200 may also include processing circuits, antennas, and other components, as further illustrated in Figure 3. These components may be located behind the contact pads 204 or elsewhere on the substrate 208, for example, in different layers of the substrate 208, and may be electrically and physically coupled to the contact pads 204. The transaction card 200 may also include a magnetic strip or tape, which may be located on the back of the card (not shown in Figure 2). The transaction card 200 may also include a Near Field Communication (NFC) device coupled with an antenna capable of communicating via the NFC protocol. Embodiments are not limited thereto.

[0029] As shown in Figure 3, the contact pads 204 of the transaction card 200 may include a processing circuit 316 for storing, processing, and communicating information, which includes a processor 302, memory 306, and one or more interfaces 304. It will be understood that the processing circuit 316 may include additional components necessary to perform the functions described herein, such as a processor, memory, error and parity / CRC checker, data encoder, collision avoidance algorithm, controller, command decoder, security primitives, and tamperproofing hardware.

[0030] Memory 306 may be read-only memory, write-once read-multiple memory, or read / write memory, such as RAM, ROM, or EEPROM, and the transaction card 200 may include one or more of these memories. Read-only memory may be factory-programmable as read-only, or it may be one-time programmable. One-time programmable provides multiple opportunities to read after it has been written once. Write-once read-multiple memory can be programmed after the memory chip has left the factory. Once programmed, memory cannot be rewritten but can be read multiple times. Read / write memory may be programmed and reprogrammed multiple times after leaving the factory. Also, read / write memory may be read multiple times after it leaves the factory. In some examples, memory 306 may be encrypted memory that utilizes an encryption algorithm performed by processor 302 to encrypt data.

[0031] Memory 306 may store one or more applets 308, one or more counters 312, a customer identifier 314, and an account number 310, which may be a virtual account number. The one or more applets 308 may consist of one or more software applications that run on one or more contactless cards, such as JavaCard applets. However, it will be understood that the applet 308 is not limited to JavaCard applets, but may instead be any software application that can run on contactless cards. The one or more counters 312 may include numeric counters sufficient to store integers. The customer identifier 314 may include a unique alphanumeric identifier assigned to a user of the transaction card 200, the identifier may distinguish a user of one contactless card from a user of another contactless card. In some examples, the customer identifier 314 may identify both the customer and the account assigned to that customer, and may further identify the transaction card 200 associated with the customer's account. As stated, the account number 310 may include a virtual account number of thousands of one-time use associated with the transaction card 200. The applet 308 of trading card 200 may manage account number 310 (for example, by selecting account number 310, marking the selected account number 310 as used, and sending account number 310 to a mobile device for automatic deposit via the autofilling service).

[0032] The processor 302 and memory elements of the exemplary embodiments described above are described with reference to the contact pad 204, but the disclosure is not limited thereto. It will be understood that these elements may be implemented as additional elements in addition to the processor 302 and memory 306 elements located outside the contact pad 204, completely separate from it, or within the contact pad 204.

[0033] In some examples, the trading card 200 may include one or more antennas 318. One or more antennas 318 may be located within the trading card 200 and around the processing circuit 316 of the contact pad 204. For example, one or more antennas 318 may be integrated with the processing circuit 316, and one or more antennas 318 may be used with an external booster coil. In another example, one or more antennas 318 may be located outside the contact pad 204 and the processing circuit 316.

[0034] In one embodiment, the coil of the transaction card 200 may act as the secondary side of an air-core transformer. The terminal may communicate with the transaction card 102 by cutting power or by amplitude modulation. The contactless card 101 may infer data transmitted from the terminal by using a gap in the contactless card's power connection, which can be functionally maintained through one or more capacitors. The transaction card 102 may return the communication by switching the load on the contactless card's coil or by load modulation. Load modulation may be detected by interference in the terminal's coil. More generally, using an antenna 318, a processor 302, and / or memory 306, the contactless card 101 provides a communication interface for communicating via NFC, Bluetooth, and / or Wi-Fi communication.

[0035] As described above, the transaction card 200 may be built on a software platform capable of running on smart cards or other devices with limited memory, such as JavaCard, and one or more applications or applets may be securely executed. The applet 308 may be added to the contactless card to provide functionality such as generating one-time passwords (OTPs) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet 308 may be configured to respond to one or more requests, such as a Near Field Data Exchange request from a reader (e.g., on a mobile device or POS terminal), and generate an NDEF message consisting of a cryptographically secure OTP encoded as an NDEF text tag.

[0036] An example of an NDEF OTP is the NDEF short-record layout (SR=1). In such an example, one or more applet 308 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 308 may add one or more static tag records in addition to the OTP record.

[0037] In some examples, one or more applets 308 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 that may indicate the authenticity of the contactless card is presented. Based on one or more applets 308, the NFC reading of the tag may be processed, and the data may be sent to a server, such as a server of the transaction system 106, via a computing device 104, and the data may be verified by the server.

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

[0039] One or more counters 312 may prevent replay attacks. For example, if a ciphertext is obtained and replayed, and counters 312 are read, used, or otherwise passed over, the ciphertext is immediately rejected. If counters 312 are not used, the ciphertext may be replayed. In some examples, a counter incremented on a card is different from a counter incremented for a transaction. Transaction card 200 cannot determine the application transaction counter 312 because there is no communication between applets 308 on transaction card 102.

[0040] In some cases, counter 312 may become out of sync. In some cases, counter 312 may increment to account for accidental readings that initiate a transaction, such as diagonal readings, but the application does not process counter 312. In some cases, when the mobile device is awakened, NFC is enabled and device 110 may read available tags, but does not perform any action to respond to the read.

[0041] To keep counter 312 synchronized, an application such as a background application may be run that is configured to detect when the mobile device 110 wakes up and to synchronize with a server in the banking system indicating that the reads resulting from the detection subsequently advance counter 312. In another example, a hashed one-time password may be used to allow for a window of missynchronization. For example, counter 312 may be configured to advance if it is within a threshold of 10. However, if it is within a different threshold number, e.g., 10 or 1000, a request to perform resynchronization may be processed, which requires the user to indicate through one or more applications via the user's device one or more times by tapping, gesture, or otherwise. If counter 312 is increasing in the appropriate order, the user may be able to know that it has done so.

[0042] The key diversification techniques described herein with reference to counter 312, the master key, and the diversified key are one example of encryption and / or decryption key diversification techniques. Since this disclosure is equally applicable to other types of key diversification techniques, this exemplary key diversification technique should not be considered limiting to this disclosure.

[0043] In the process of creating the transaction card 200, two unique encryption keys may be assigned to each card. The encryption keys may include a symmetric key used for both data encryption and decryption. In EMV, the Triple DES (3DES) algorithm may be used and implemented by the hardware of the transaction card 200. By using a key diversification process, one or more keys may be derived from the master key based on uniquely identifiable information of each entity requiring a key.

[0044] In some examples, to overcome vulnerabilities in the 3DES algorithm, a session key may be derived (e.g., a key unique to each session), but instead of using a master key, unique card derivation keys and counters may be used as diversification data. For example, each time transaction card 200 is used, a different key may be used to generate the Message Authentication Code (MAC) and perform encryption. This results in triple encryption. The session key may be generated by one or more applets and derived by using application transaction counters with one or more algorithms (defined in EMV 4.3 Book 2 A1.3.1 Common Session Key Derivation).

[0045] Furthermore, the increment for each card may be unique, either assigned by personal settings or algorithmically assigned by some identifier. For example, odd-numbered cards may increment by 2, and even-numbered cards may increment by 5. In some examples, the increment may also vary by sequential reading, such that one card increments sequentially as 1, 3, 5, 3, 2, ... The specific sequence or algorithmic sequence may be defined at the time of personalization, or from one or more processes derived from a unique identifier. This makes it difficult for a replay attacker to generalize from a small number of card instances. The authentication message may be delivered as the content of a text NDEF record in hexadecimal ASCII format. In another example, the NDEF record may be encoded in hexadecimal format.

[0046] In an embodiment, applet 308 may include a transaction applet that can be started or executed based on the detection of a transaction attempt. For example, the transaction applet may be started when a transaction attempt is detected via one of the interfaces 304, such as an EMV interface and / or an NFC interface. Based on the detection of a transaction attempt, the transaction applet may exchange data with another device, such as a transaction terminal, to perform the transaction. The data may include user identification information, account identification information, card information (expiration date / CVV), etc. In an embodiment, the transaction applet may exchange information in a secure manner based on the interface standard. For example, the transaction applet may exchange information according to the EMV standard or the NFC standard, based on the interface used for the transaction.

[0047] In an embodiment, applet 308 may include a quality assurance applet that collects and / or exchanges data corresponding to each transaction attempt. In an embodiment, the quality assurance applet may detect transaction attempts via the interface of interface 304. For example, the quality assurance applet may be a JavaCard applet and be configured as a default applet so that it is selectable or selected by default when the transaction card 200 enters the magnetic field of the transaction terminal or at the start of EMV exchange. The quality assurance applet may be set as the default applet of the transaction card 200 at the time of manufacture and / or original programming of the transaction card 200 by installing an applet with default parameters set. In this example, once the quality assurance applet is set, changes to the quality assurance applet may be prohibited, for example, the applet may be locked down. In one example, the quality assurance applet may be set as the default applet after installation and may be reconfigurable. To set the quality assurance applet as the default applet, for example, -make-default <aid>Java operations such as (AID is the quality assurance applet identifier) ​​may be performed on the quality assurance applet.

[0048] In one embodiment, once started, the Quality Assurance applet may execute instructions in the processor 302 and / or processing circuit 316 of the transaction card 200 to determine data related to the transaction attempt and store the data in memory 306. For example, the transaction card 200 may enter the magnetic field of an NFC reader or receive a signal from an EMV device, and the Quality Assurance applet may determine data related to the transaction attempt, such as a timestamp related to the transaction attempt and the type of interface that detected the transaction attempt (NFC interface, EMV interface, magnetic stripe interface, etc.). The data may further include a transaction identifier that identifies the transaction attempt and a transaction terminal identifier that identifies the transaction terminal related to the transaction attempt. The Quality Assurance applet may determine at least some of the data based on information exchange between the transaction card 200 and the transaction terminal. For example, the Quality Assurance applet may determine at least one of the timestamp, interface type, transaction identifier, and transaction terminal identifier from the data received in the data exchange with the transaction terminal.

[0049] The Quality Assurance applet may store data related to trading attempts in the memory 306 of the trading card 200. The data may be stored in a data structure in memory, such as an array, and in a data format, such as ASCII. For example, the portion of memory 306 that stores the data for trading attempts may be allocated when the Quality Assurance applet is installed on the trading card 200, or memory 306 may be allocated to the Quality Assurance applet as needed when the Quality Assurance applet writes data to memory 306. The Quality Assurance applet may store the data related to each trading attempt until a read operation is performed to read data from memory 306, for example, until the data is transferred to the computing device 104 and / or server of the trading system 106. Memory 306 may be cleared by the Quality Assurance applet after being read from memory 306 to ensure that not all of memory 306 is used.

[0050] In an embodiment, the quality assurance applet detects a request or read of data associated with a transaction attempt and stored in memory 306. For example, the quality assurance applet may respond to one or more requests, such as a Near Field Data Exchange request from a reader, such as a mobile NFC reader (e.g., a mobile device or POS terminal). The quality assurance applet may generate one or more messages, such as encrypted messages in NDEF format, for example, an NDEF message containing data related to a transaction attempt. In one example, the quality assurance applet may encrypt the data before communicating with another device. The quality assurance applet may generate encrypted data from the data related to the transaction attempt stored in memory 306 based on an encryption algorithm, a customer identifier, and a secret key. For example, the quality assurance applet may apply an encryption algorithm such as the 3DES algorithm, use a customer identifier (or counter value) to generate diverse data, and encrypt the data with a secret key. The secret key may be one of the keys assigned to the transaction card 200, as described earlier. In another embodiment, the secret key may be a session key uniquely generated for each communication. The session key may be generated by a quality assurance applet or another applet and derived by using an application transaction counter with one or more algorithms.

[0051] In some embodiments, the quality assurance applet may provide encrypted data to the computing device via an interface where a read has been detected. For example, the quality assurance applet may send encrypted data to the computing device in one or more NDEF messages. In some embodiments, encrypted data may be provided in batch communication. Note that in one example, the data may not be encrypted, and the quality assurance applet may provide the data in raw or unencrypted format. Figure 4 shows details of exchanges or sequences for communicating data between the transaction card 102 and the computing device 104, and between the computing device and the transaction system 106.

[0052] Figure 4 shows an example of a sequence flow 400 for communicating data according to one or more embodiments of the present disclosure. The sequence flow 400 may include a transaction card 102, a computing device 104, and a transaction system 106. In embodiments, the computing device 104 may include one or more applications, including a mobile application that can run on a mobile platform such as Android® or Apple iOS. In one example, the mobile application may relate to a banking system such as the transaction system 106, and possibly a mobile banking application. The sequence flow 400 may be executed to communicate data related to a transaction attempt from the transaction card 102 to the computing device 104 and to the transaction system 106.

[0053] In line 402, the computing device 104 communicates with the trading card 102 (for example, after being brought close to the trading card 102) and establishes a communication link. Communication between the computing device 104 and the trading card 102 may involve the trading card 102 being brought close enough to the card reader (not shown) of the computing device 104 to enable NFC data transfer between the computing device 104 and the trading card 102. Once a communication link is established between the computing device 104 and the trading card 102, data related to the trading attempt can be communicated between them. While the illustrated example involves communication by NFC data transfer, embodiments are not limited in this way, and data may be communicated by other methods, such as WiFi (802.11 standard).

[0054] On line 404, the computing device 104 may generate a read message, which may be generated according to the NFC Data Exchange format, such as an NFC read of an NDEF tag. The transaction card 102, including the Quality Assurance applet, may detect the read and initiate one or more instructions to generate data in response to the read message. Specifically, on line 406, the transaction card 102, including the Quality Assurance applet, may retrieve data related to the transaction attempt for transmission to the computing device 104. In embodiments, the Quality Assurance applet may generate one or more NDEF messages, as also shown in Figure 5, and the message payload may include data related to the transaction attempt. The data may be in an encrypted or unencrypted form in the NDEF message. The transaction card 102 may transmit the data in the NDEF message to the computing device 104.

[0055] In an embodiment, the computing device 104 may establish a communication link with the trading system 106 on line 408. The computing device 104 may include a mobile application or programming code that establishes a secure communication link with the trading system 106 via one or more wireless and wired network connections. One or more communication links conforming to WiFi and / or cellular standards may be secure communication links.

[0056] In line 410, the computing device 104 may transmit data of the trading attempt to the trading system 106. In an embodiment, the trading system 106 may receive data related to the trading attempt and store that data in a database data structure. The trading system 106 may use the data, along with the data of the actual trades performed, to detect problems with the trading card and / or trading terminal, as will be described in more detail below.

[0057] Figure 5 shows an example of an NDEF message 500 for communicating data between a transaction card 102 and another device such as a computing device 104 or a transaction terminal 108. In embodiments, the NDEF message 500 may include a number of records that can be configured according to the NDEF format in the ISO-1443 infrastructure. Furthermore, each record may have a header and a payload, the header including a record identifier, the record length, and the record type. In embodiments, the type may specify, for example, the type of content that the record contains. When the type is set as follows: 0 - Empty: The record contains no information. 1 - Well-known: Data is defined according to the RTD (Record Type Definition) specification. 2 - Multipurpose Internet Mail Extension (MIME): Data types defined by RFC2046 3 - URI (Uniform Resource Identifier): A pointer to a resource that conforms to the syntax of RFC3986. 4 - External: User-defined data that depends on the format defined in the RTD specification. 5 - Unknown: Data type is unknown. 6 - Unchanged: Chunk of record 7 - Reserved: Reserved value

[0058] An NDEF message 500 can contain multiple records. The first record in a message contains the MB (Message Start) flag, which is set to true to indicate the first record. The last record in a message has the ME flag set to indicate the last record. All intermediate records have both the MB and ME flags set to false.

[0059] In an embodiment, the NDEF message 500 may include a Type Length field, which includes the length of the payload type in bytes. The payload type specifies the exact type of data found in the payload. The payload length field includes the length of the payload in bytes. A single record can be up to 4,294,967,295 bytes (or 2 32 - Can contain data up to 1 byte.

[0060] Figure 6 shows an exemplary logic flow 600 that may be executed by a computing device, such as the processing circuitry of a trading card. In one example, the operation of logic flow 600 may be executed by an applet, such as a quality assurance applet, which is executed in the circuitry of the trading card. Logic flow 600 illustrates one possible set of operations that may be performed by the applet to collect and store data on trading attempts, successes, and failures. In one example, the quality assurance applet may include software instructions programmed according to the JavaCard programming language. However, embodiments are not thus limited, and the operations discussed herein may be programmed and / or executed according to other languages, such as Extensible Markup Language (XML), and languages ​​such as C, Perl, C++, and Assembly.

[0061] In block 602, logic flow 600 includes detecting a transaction attempt via one of several interfaces. For example, a quality assurance applet may be configured as a default applet and may be started when detected via an NFC interface or an EMV interface. Specifically, a quality assurance applet may be started when a transaction card including an NFC interface detects an electromagnetic signal, or when communication exchange is initiated via an EMV interface.

[0062] In block 604, logic flow 600 includes determining data related to a trading attempt. The data may be received through one or more communication exchanges with other devices via an interface, or it may be determined based on data on the trading card itself. For example, the quality assurance applet may receive data from the trading terminal such as a timestamp related to the trading attempt, a trading terminal identifier related to the trading terminal, a trading identifier for identifying the trading attempt, an indication of whether the trading attempt was successful or unsuccessful, and the interface type of the trading attempt. The applet may also determine data from the trading card. For example, the quality assurance applet may determine a timestamp from the trading card's clock, an interface type based on the detection of the trading attempt, and a trading identifier generated by the trading card.

[0063] In block 606, logic flow 600 includes storing data in a memory storage structure. For example, a quality assurance applet may store data in an array containing blocks of memory, and the data may also be stored so that it is associated with a trading attempt. Thus, each trading attempt may correspond to a specific dataset.

[0064] Logic flow 600, in block 608, includes the detection of a request for data related to a transaction attempt. For example, a quality assurance applet may detect a read of data by a computing device via the transaction card's near-field communication (NFC) interface. The read may be received after a communication channel has been established between the transaction card and the computing device, such as the user's mobile device. Establishing the communication channel may involve the execution of one or more verification routines.

[0065] In block 610, logic flow 600 includes communicating data to a computing device via an NFC interface. The quality assurance applet may generate one or more NDEF messages containing records with data related to a transaction attempt in the payload, and communicate the NDEF messages to other computing devices. In some embodiments, the quality assurance applet may encrypt the data. For example, the quality assurance applet may use an encryption algorithm, a customer identifier, and a key (private or shared key) to generate encrypted data to share with other computing devices.

[0066] Figure 7 shows a logic flow 700 that may be executed by one or more systems, such as a trading system, to detect anomalies and problems in trading cards and trading terminals. The operation in Figure 7 may be executed by a system including one or more servers, which include a processor and memory that execute instructions for detecting anomalies based on data collected by trading cards and trading terminals. The data may correspond to both successful and unsuccessful trading attempts.

[0067] In block 702, logic flow 700 includes determining data related to multiple trading attempts performed on multiple trading cards associated with a user account. The data may be collected by one or more trading cards or by one or more trading terminals, as previously described. For example, data may be collected by the trading card each time a trading attempt is performed on the trading card. For example, data may be collected by the trading terminal and provided to the trading system during the processing of a transaction, for example, when a user is using the trading card for goods or services. For each trading attempt, the data may include timestamp data, trading terminal identifier data, transaction identifier data, interface type data, user account data, etc.

[0068] In block 704, logic flow 700 includes applying one or more data analysis routines or processes to the data. The data analysis routines may compare the data to determine any number of usage statistics, including the number of times a user or customer encountered a contactless (NFC) transaction terminal, the number of times a user used an NFC transaction terminal for contactless (NFC) payment, the number of times a customer encountered a contactless payment terminal and reverted to contact (EMV / swipe) payment, and the number of failed transaction attempts indicating that the user “gave up”. This data can be used to detect problems with payment cards or terminals.

[0069] In one embodiment, a data analysis routine can detect a pattern in which a user attempts to execute a transaction using the NFC interface, the transaction attempt fails, and the user switches to another method (swipe or EMV interface) to execute the transaction. This pattern may be detected based on multiple consecutive transaction attempts for a transaction card at the trading terminal with close timestamps (within a configurable retry threshold), e.g., attempts corresponding to the NFC interface and attempts corresponding to the EMV interface. The trading system may determine that there is an anomaly or problem with the NFC interface of a transaction card if the pattern occurs with the same transaction card at different trading terminals. Similarly, the data analysis routine may determine that there is a problem with the trading terminal if a similar pattern is detected at the same trading terminal but with different transaction cards. More specifically, the trading system may detect multiple consecutive transaction attempts with close timestamps at the trading terminal for multiple transaction cards (above a configurable retry threshold). The routine may also detect anomalies based on other statistics, such as a user using their transaction card's NFC interface statistically less often than other similar users, e.g., those in the same region, gender, age group, etc. In another example, a trading system may determine that a trading terminal is problematic or abnormal if it is being used statistically differently from similar terminals in the same location, of the same type, or in the same type of location / facility.

[0070] The trading system may include performing data analysis routines, which may include performing statistical analysis on the data, and may include scoring the data with a model to detect anomalies in trading cards and / or terminals. For example, the data analysis routine may include applying supervised or unsupervised machine learning techniques to detect patterns in the data that may indicate problems with trading cards or terminals. The machine learning may include training one or more models on known datasets (created / generated) or real datasets to detect patterns. Embodiments are not limited thereto.

[0071] In block 706, the logic flow 700 includes detecting anomalies or problems based on data analysis routines applied to the data. For example, the trading system may determine that there is a problem with a trading card or trading terminal. Furthermore, in block 708, the logic flow 700 includes causing an action to be performed based on the detected anomaly. For example, if the trading system determines that there is a problem with the interface for trading, it may cause the user to issue a new trading card. In another example, if the system determines that the NFC interface is functioning correctly but the user does not seem to know how to use it correctly, for example, based on periodic successful attempts, the trading system may send instructions on how to use the NFC interface correctly. In a third example, the trading system may send a message to the operator of a trading terminal indicating that the interface is malfunctioning and / or improperly configured. Embodiments are not limited to these examples, and other improvement operations may be performed.

[0072] Figure 8 shows an example of data 800 corresponding to a trading attempt on a trading card. The illustrated data 800 contains numerous entries corresponding to trading attempts, with each column corresponding to a specific trading attempt. In some embodiments, column 814 contains timestamp data (date and time) of the trading attempt detected and stored by the quality assurance applet on the trading card. Column 816 contains additional data detected and stored by the quality assurance applet. The data in column 816 may include the interface type and the trading identifier. In some embodiments, the data in column 816 may include a trading terminal identifier (not shown). Column 818 contains data corresponding to the actual trading performed by the trading system. The data in column 818 also includes the trading interface type and the trading identifier. The data may also include a trading terminal identifier. Column 820 contains timestamp data corresponding to the actual trading in column 818.

[0073] Data 800 may also contain a number of rows, each row corresponding to a specific successful or failed transaction attempt detected and stored by the quality assurance applet. For example, a row with data in columns 814 and 816 but no data in columns 818 and 820 indicates that a transaction attempt was recorded by the quality assurance applet but not executed by the trading system. For example, row 802 contains data in columns 814 and 816 but no data in 818 and 820. This indicates that a transaction attempt may have occurred but was not actually executed by the trading system. The trading system may apply data analysis routines to determine that this pattern indicates a problem with the user's trading card. In some examples, the trading system may require a threshold number of occurrences of the pattern before an anomaly or problem is indicated. For example, the trading system may require five or more instances similar to row 802 before the trading system determines that there is an anomaly or problem.

[0074] Line 804 shows another pattern that may be detected by the trading system. The data in line 804 indicates that both the quality assurance applet and the trading system processed a contact transaction (EMV interface or Magstripe interface) using a transaction identifier. Although the timestamps are slightly different, the trading system may determine that they are within an acceptable threshold and that the data detected by the quality assurance applet and the trading system pertains to the same transaction. Line 806 shows a similar pattern. However, in this example, the transaction is executed over a different interface, such as an NFC interface.

[0075] Line 808 indicates that the quality assurance applet detected an attempt at a transaction using the contactless interface and saved the data. However, the transaction system did not receive the transaction corresponding to the transaction attempt in line 808. Line 810 includes an attempt at a transaction corresponding to a transaction executed by the transaction system. Note that the transaction attempt in line 810 occurred after the transaction attempt detected in line 808. This pattern may also indicate that a user attempted to execute a transaction via the contactless interface (line 808), but the transaction attempt failed, and the user then used the contact interface to execute the transaction (line 810). The transaction system may determine that this pattern indicates an anomaly or problem with the contactless interface of the transaction card and / or the contactless interface of the transaction terminal. The problem may be that the customer is misusing the contactless interface, the terminal is misconfigured, or there is a malfunction in one or both the card and / or the terminal.

[0076] Line 812 indicates that a contactless transaction attempt was successful with the trading card. Since this transaction attempt occurred after the failed attempt in line 808, the trading system may determine that the contactless interface of the trading card is functioning correctly. The trading system may also determine that the problems detected in lines 808 and 810 are due to proper attempts by the trading terminal and / or the user. Embodiments are not limited to these examples, and the trading system described above may detect many patterns and may utilize machine learning and modeling.

[0077] Figure 9 shows an example embodiment of a computer architecture 900 suitable for implementing the various embodiments described above. In this embodiment, the computer architecture 900 may include or be implemented as part of a system 100, a trading system 106, and a trading terminal 108.

[0078] As used in this application, the terms “system” and “component” are intended to refer to computer-related entities that are either hardware, a combination of hardware and software, software, or running software, examples of which are provided by the exemplary computing architecture 900. For example, a component may be, but is not limited to, a process running on a processor, a processor, a hard disk drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable, a thread of execution, a program, and / or a computer. Exemplarily, both an application running on a server and the server may be components. One or more components may reside within a process and / or a thread of execution, 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 operations. Coordination may include unidirectional or bidirectional information exchange. 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 assignments, each message is a signal. However, further embodiments may alternatively employ data messages. Such data messages can be transmitted across various connections. Illustrative connections include parallel interfaces, serial interfaces, and bus interfaces.

[0079] Computer architecture 900 includes a variety of 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, and power supplies. However, embodiments are not limited to implementations of computing architecture 900.

[0080] As shown in Figure 9, the computer architecture 900 includes a processor 904, system memory 906, and a system bus 908. The processor 904 may be any of the various commercially available processors.

[0081] The system bus 908 provides an interface for connecting system components, including but not limited to system memory 906, to the processor 904. The system bus 908 may further be any of several types of bus structures that can 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 via slot architectures. Exemplary slot architectures may include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, (Enhanced) Industry Standard Architecture ((E)ISA), Microchannel Architecture (MCA), NuBus, Peripheral Component Interconnect (Enhanced) (PCI(X)), PCI Express, and the Personal Computer Memory Card International Association (PCMCIA).

[0082] The computing architecture 100 may include or implement various manufactured articles. These manufactured articles may include computer-readable storage media for storing logic. Examples of computer-readable storage media may include any tangible medium capable of storing electronic data, such as volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, or writable or rewritable memory. Examples of logic may include executable computer program instructions implemented using any appropriate type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, or visual code. Furthermore, embodiments may be implemented, at least in part, as instructions contained in or on non-transient computer-readable media, which may be read and executed by one or more processors to enable the execution of the operations described herein.

[0083] The system memory 906 may include various types of computer-readable storage media in the form of one or more high-speed memory units, such as read-only memory (ROM), random access memory (RAM), dynamic RAM (DRAM), double data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), eraseable programmable ROM (EPROM), EEPROM (Electrically Erasable Programmable ROM), flash memory, ferroelectric polymer memory, ovonic memory, phase-change or ferroelectric memory, silicon-oxide-silicon oxide (SONOS) memory, magnetic or optical cards, arrays of devices such as RAID (Redundant Array of Independent Disks) drives, solid-state memory devices (e.g., USB memory, solid-state drives (SSDs)), and any other type of storage media suitable for storing information. In the embodiment shown in Figure 9, the system memory 906 may include non-volatile 910 and / or volatile 912. The basic input / output system (BIOS) can be stored in the non-volatile 910.

[0084] Computer 902 may include various types of computer-readable storage media in the form of one or more low-speed memory units, such as an internal (or external) hard disk drive 914, a magnetic disk drive 916 for reading from or writing to a removable magnetic disk 918, and an optical disk drive 920 for reading from or writing to a removable optical disk 922 (e.g., a CD-ROM or DVD). The hard disk drive 914, magnetic disk drive 916, and optical disk drive 920 can be connected to the system bus 908 by an HDD interface 924, an FDD interface 926, and an optical disk drive interface 928, respectively. The HDD interface 924 for external drive implementation may include at least one or both of the Universal Serial Bus (USB) and IEEE 1394 interface technologies.

[0085] The drive and associated computer-readable media provide volatile and / or non-volatile storage of data, data structures, computer executable instructions, etc. For example, a number of program modules, including an operating system 930, one or more applications 932, other program modules 934, and program data 936, can be stored in the drive and non-volatile 910 and volatile 912. In one embodiment, the one or more applications 932, other program modules 934, and program data 936 may include, for example, various applications and / or components of the system discussed herein.

[0086] The user can input commands and information to the computer 902 via one or more wired / wireless input devices, such as a keyboard 938 and a pointing device such as a mouse 940. Other input devices include microphones, infrared (IR) remote controls, radio frequency (RF) remote controls, gamepads, stylus pens, card readers, dongles, fingerprint readers, gloves, graphics tablets, joysticks, keyboards, retina readers, touchscreens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors, and styluses. These and other input devices are often connected to the processor 904 via an input device interface 942 coupled to the system bus 908, but can also be connected via other interfaces such as parallel ports, IEEE 1394 serial ports, game ports, USB ports, and IR interfaces.

[0087] Additionally, the monitor 944 and other types of display devices are connected to the system bus 908 via interfaces such as the video adapter 946. The monitor 944 may be internal or external to the computer 902. In addition to the monitor 944, the computer typically includes other peripheral output devices such as speakers and printers.

[0088] Computer 902 can operate in a network environment using wired and / or wireless logical connections to one or more remote computers, such as remote computer 948. The remote computer 948 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer device, or other common network node, typically including many or all of the elements described in relation to computer 902, but for brevity, only the memory and / or storage device 950 is illustrated. The logical connections depicted include wired / wireless connections to the local area network 952 and / or larger networks, such as the wide area network 954. 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.

[0089] When used in the networking environment of the local area network 952, the computer 902 is connected to the local area network 952 via a wired and / or wireless communication network interface or network adapter 956. The network adapter 956 can facilitate wired and / or wireless communication to the local area network 952 and may also include a wireless access point placed on it for communication with the wireless function of the network adapter 956.

[0090] When used in a networking environment of a wide area network 954, computer 902 may include a modem 958, or may be connected to a communication server on the wide area network 954, or may have other means of establishing communication on the wide area network 954, such as via the Internet. The modem 958 may be internal or external, may be a wired and / or wireless device, and may be connected to the system bus 908 via an input device interface 942. In a network environment, program modules, or parts thereof, written in relation to computer 902 may be stored in remote memory and / or storage device 950. The illustrated network connection is an example, and it will be understood that other means of establishing communication links between computers may be used.

[0091] Computer 902 is capable of communicating with wired and wireless devices or entities using the Institute of Electrical and Electronics Engineers (IEEE) 802 family of standards, such as wireless devices configured to operate wirelessly (e.g., using the wireless modulation techniques of IEEE 802.11). This includes at least Wi-Fi (or Wireless Fidelity), WiMAX, and Bluetooth® wireless technologies. Thus, communication may have a predetermined structure, like a conventional network, or it may simply be ad-hoc communication between at least two devices. Wi-Fi networks provide secure, reliable, and high-speed wireless connectivity using wireless technologies known as IEEE 802.118 (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).

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

[0093] Figure 10 is a block diagram showing an example of a communication architecture 1000 suitable for implementing the various embodiments described above. The communication architecture 1000 includes various common communication elements such as transmitters, receivers, transceivers, radios, network interfaces, baseband processors, antennas, amplifiers, filters, and power supplies. However, the embodiments are not limited to implementations using the communication architecture 1000 and may be consistent with the computing system 100.

[0094] As shown in Figure 10, the communication architecture 1000 includes one or more clients 1002 and servers 1004. The server 1004 may implement one or more devices of the computing system 100. The client 1002 and server 1004 are operationally connected to one or more respective client data stores 1008 and server data stores 1010, which can be used to store information local to each client 1002 and server 1004, such as cookies and / or associated contextual information.

[0095] Client 1002 and server 1004 can communicate information with each other using the communication framework 1006. The communication framework 1006 may implement any well-known communication technology and protocol. The communication framework 1006 may be implemented as a packet-switched network (e.g., a public network such as the Internet, a private network such as an intranet within a company), 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 translators).

[0096] The communication framework 1006 may implement various network interfaces arranged to accept, communicate with, and connect to communication networks. Network interfaces can be considered special forms of input / output (I / O) interfaces. Network interfaces may employ connection protocols including, but are not limited to, direct connect, Ethernet (e.g., thick, thin, twisted-pair 10 / 100 / 1000 base T, etc.), token ring, wireless network interfaces, cellular network interfaces, IEEE 802.11 Ax network interfaces, IEEE 802.16 network interfaces, and IEEE 802.11 network interfaces. Furthermore, multiple network interfaces can be used to engage various types of communication networks. For example, multiple network interfaces can be employed to enable communication in broadcast, multicast, and unicast networks. If processing requirements demand greater speed and capacity, a distributed network controller architecture may similarly be employed to increase the communication bandwidth required by client 1002 and server 1004 through pooling, load balancing, and other means. A communication network can be any one or combination of any unlimited wired and / or wireless networks, including direct interconnections, protected custom connections, private networks (e.g., corporate intranets), public networks (e.g., the Internet), personal area networks (PANs), local area networks (LANs), metropolitan area networks (MANs), Operational Missions as Nodes on the Internet (OMNIs), wide area networks (WANs), wireless networks, mobile networks, and other communication networks.

[0097] The components and functions of the device described above can be implemented using any combination of discrete circuits, application-specific integrated circuits (ASICs), logic gates, and / or single-chip architectures. Furthermore, the features of the device may preferably be implemented using a microcontroller, a programmable logic array, and / or a microprocessor, or any combination thereof. Note that the hardware, firmware, and / or software elements may be referred to here collectively or individually as “logic” or “circuit.”< / aid>

Claims

1. A trading card comprising multiple interfaces, a processor, and a memory for storing instructions that, when executed by the processor, cause the following to occur in the processor. Detection of transaction attempts via one of multiple interfaces by a quality assurance applet executed on the aforementioned processor, Determination of data related to the transaction preference by the quality assurance applet, including a timestamp related to the transaction attempt and the interface type of the interface on which the transaction attempt was detected. The storage of the data related to the trial of the transaction into memory by the quality assurance applet, Detection of data reading by a computing device via one of the multiple interfaces using the aforementioned quality assurance applet, The aforementioned quality assurance applet generates encrypted data from the transaction trial data stored in memory, based on an encryption algorithm, a customer identifier, and a private key. The quality assurance applet provides the computing device in which the reading of encrypted data via the interface has been detected.

2. The interface on which the transaction attempt is detected is either a contact interface or a non-contact interface, The contact interface includes a magnetic stripe interface or an EMV interface. The aforementioned contactless interface includes a near-field communication (NFC) interface. The transaction card according to claim 1.

3. The aforementioned quality assurance applet is the default applet of the transaction card in order to enable the detection of the transaction attempt. The transaction card according to claim 1.

4. The data relating to the trial of the transaction further includes a transaction identifier that identifies the trial of the transaction and a transaction terminal identifier that identifies the transaction terminal. The transaction card according to claim 1.

5. The detection of the attempted transaction includes receiving at least a portion of the data from the transaction terminal. Some of the aforementioned data includes a timestamp, interface type, or a combination thereof. The transaction card according to claim 4.

6. The data related to the aforementioned transaction trial is stored together with other data corresponding to other transaction trials. The transaction card according to claim 1.

7. The encrypted data further includes other data corresponding to the other transaction trials, The processor is instructed to provide encrypted data, including the data and other data, to the computing device as batch communication. The transaction card according to claim 6.

8. The interface on which the reading is performed is detected, The encrypted data is provided via a near-field communication (NFC) interface. The encrypted data is provided in one or more NFC Data Interchange Format (NDEF) messages. The transaction card according to claim 1.

9. A trading system comprising a processor, storage with a data store, and memory that stores instructions, when executed by the processor, causing the following to occur in the processor. The interface coupled to the processor includes entries related to trading attempts relating to multiple trading attempts executed on trading cards associated with a user account, and each entry for each trading attempt includes a timestamp of the corresponding trading attempt and the interface type of the trading attempt, and data reception, Storage of the aforementioned data into the data store, Based on the data, determination of interface information for one or more interfaces of the transaction card, showing statistics on the use of the interface related to anomalies and one or more interfaces, Initiating an operation based on the aforementioned interface information.

10. The aforementioned data is encrypted and received from the transaction card by a computing device that is communicably coupled via the interface. The system according to claim 9.

11. Each entry related to each transaction trial includes a transaction identifier and a POS (Point of Sales) identifier that identifies the POS terminal. The system according to claim 9.

12. The aforementioned processor, By comparing consecutive timestamps of data trading attempts, The timestamp difference is determined to be within the threshold for retrying the transaction. Determine the interface type related to the first time-limited trading trial in a series of trading trials. An entry corresponding to the first time-limited trading attempt, indicating the failure of the trading attempt. The system according to claim 9.

13. The aforementioned usage statistics indicate the number of failed transaction attempts corresponding to the interface of the transaction card. The system according to claim 9.

14. The aforementioned usage statistics show the number of transaction attempts using the contact interface and the number of transaction attempts using the contactless interface. The system according to claim 9.

15. The aforementioned usage statistics indicate whether the trial of each transaction using the contact interface and the contactless interface was successful or not. The system according to claim 14.

16. The aforementioned processor, We received additional data related to multiple transaction cards and user accounts. The additional data is stored in the aforementioned data store. Based on the aforementioned data, the interface information of the multiple transaction cards is determined. Based on the interface information of the plurality of transaction cards, an abnormality related to the POS terminal is determined. The system according to claim 9.

17. The operation includes transmitting the notification of the abnormality to a device associated with the POS terminal. The system according to claim 16.

18. The aforementioned operation is, Sending a replacement transaction card to the user associated with the aforementioned user account, Text message communication with the device associated with the aforementioned user account, Sending instructions to the relevant device to perform a contactless interface transaction, or Those combinations, The system according to claim 9, including the following:

19. A method implemented in a computer, A quality assurance applet running on the processor detects attempted transactions through one of several interfaces. The quality assurance applet receives data related to the transaction trial, including a timestamp related to the transaction trial and one interface type among the plurality of interfaces. The storage of the data into the memory storage structure by the aforementioned quality assurance applet, Detection of data reading by a computing device via the Near Field Communication (NFC) interface among the multiple interfaces by the aforementioned quality assurance applet, The aforementioned quality assurance applet uses an encryption algorithm, a customer identifier, and a private key to encrypt the data related to the trial transaction, and The aforementioned quality assurance applet communicates data to the computing device via the NFC interface. A method that includes this.

20. The interface on which the transaction attempt is detected is either a contact interface or a non-contact interface. The aforementioned contact interface includes a magnetic stripe interface or an EMV interface. The aforementioned contactless interface includes an NFC interface. The method according to claim 19.

Images