System and method for secure read-only authentication

The transaction card with a radio frequency transmitter and dynamic counter or timestamp-based encryption addresses the limitations of EMV protocols by providing secure, read-only authentication, enhancing transaction security and preventing fraud.

CN119250814APending Publication Date: 2025-01-03CAPITAL ONE SERVICES LLC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411306419.X
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2018-06-21
Filing Date
2019-06-21
Publication Date
2025-01-03

AI Technical Summary

Technical Problem

Existing authentication methods, particularly those using EMV protocols, rely on two-way communication which many devices and operating systems do not support, leading to security vulnerabilities and the inability to complete transactions with EMV-enabled transaction cards.

Method used

A transaction card with a radio frequency transmitter, clock generator, and near field communication tag that generates an encrypted value based on a dynamic counter or timestamp, providing secure, read-only authentication without two-way communication.

Benefits of technology

Enhances transaction security by preventing unauthorized access through dynamic, encrypted values that change with each read, ensuring authentication integrity and preventing fraud.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119250814A_ABST
    Figure CN119250814A_ABST
Patent Text Reader

Abstract

A system and method for secure read-only authentication are disclosed. A system for authenticating a user having a mobile device includes a memory storing instructions, and a processor in communication with a network. The processor may be configured to execute the stored instructions to receive an authentication request from the mobile device; obtaining a permanent identifier associated with the transaction card from a database; generating a temporary identifier associated with the transaction card; generating a desired value by encrypting the permanent identifier and the temporary identifier; validating the desired value from an encrypted value received from the mobile device; and sending an authorization command to the mobile device.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] This application is a divisional application of application number 201980041892.0, application date June 21, 2019, and invention name “System and method for secure read-only authentication”.

[0002] Related Applications

[0003] This application claims the benefit of U.S. Provisional Patent Application No. 16 / 014,542, filed on June 21, 2018, the entire contents of which are incorporated herein by reference.

[0004] manual Technical Field

[0005] The disclosed embodiments relate generally to authenticating an account card and, more particularly, to authenticating an account card using a synchronized counter. Background Art

[0006] Many types of interactions on computer systems, such as authentication logins and other transaction-based processes, are not secure. For example, when attempting to log into a website on a computer, the website may request a username and password. Anyone with this set of information, whether an authorized user or a malicious user, can use the website for any purpose. To combat this insecurity, some transactions require multi-factor authentication, often referred to as "what you know and what you have." For example, when logging into a website, a website may request a username / password combination ("what you know"), as well as a six-digit number displayed on an electronic device ("what you have") or a fingerprint scan ("who you are"). This six-digit number (also known as a time-based one-time password (TOTP)) may change every 30 seconds to prevent reuse by unauthorized users. As another example, a credit card may have information stored on it that allows the credit card processor to know whether the user has the card in their possession. For example, while the card may have the card number printed on the front ("what you know"), some of the information may only be present as part of the EMV chip ("what you have"). Some devices may read information from the EMV chip for contactless authentication of the user. Some devices allow for multi-factor authentication using both a “what you know” factor and a “who you are” factor, such as biometric authentication such as face recognition, fingerprint authentication, and / or iris scanning.

[0007] Currently, the EMV protocol relies on two-way communication between the EMV chip of a transaction card and a payment terminal (e.g., a POS terminal). To complete a transaction, transaction information is sent from the payment terminal to the transaction card. The EMV chip receives the transaction information, digitally signs the information, and transmits the signed information back to the payment terminal for authentication. However, many devices and / or operating systems do not support two-way communication and therefore cannot complete transactions using EMV-enabled transaction cards.

[0008] Due to these and other disadvantages associated with authentication using two-way communication protocols, a need exists to allow for technically secure, read-only authentication. Summary of the invention

[0009] Consistent with the disclosed embodiments, a transaction card associated with a financial account and used to generate an encrypted value as part of an authentication request is provided. The transaction card includes a radio frequency transmitter; a clock generator coupled to the radio frequency transmitter, the clock generator configured to increment a counter value in response to a wireless read signal received from an external radio frequency reader device; and a near field communication tag coupled to the radio frequency transmitter and storing a permanent identifier and the counter value. The near field communication tag may be configured to respond to the received read signal to: generate an encrypted value based on the permanent identifier and the counter value; and provide the encrypted value to the radio frequency transmitter for transmission to the external radio frequency reader device.

[0010] Consistent with another disclosed embodiment, a transaction card is provided that is associated with a financial account and generates an encrypted value as part of an authentication request. The transaction card includes a radio frequency transmitter; a near field communication tag coupled to the radio frequency transmitter; and a clock coupled to the near field communication tag and powered by a power source. The clock may be configured to send a time value to the near field communication tag in response to a wireless read signal received by the near field communication tag from an external radio frequency reader device. The near field communication tag may be configured to: store a permanent identifier and a time value; and in response to the received read signal to: generate an encrypted value based on the permanent identifier and the time value; and provide the encrypted value to the radio frequency transmitter for transmission to the external radio frequency reader device.

[0011] In accordance with another disclosed embodiment, a transaction card associated with a financial account and used to generate an encrypted value as part of an authentication request is provided. The transaction card includes: a radio frequency transmitter; a near field communication tag coupled to the radio frequency transmitter; and a microprocessor coupled to the near field communication tag and powered by a power source. The microprocessor can be configured to calculate an update value in response to a wireless read signal received from an external radio frequency reader device. The near field communication tag can be configured to: store a permanent identifier and an update value, and in response to the received read signal: generate an encrypted value based on the permanent identifier and the update value, and provide the encrypted value to the radio frequency transmitter for transmission to the external radio frequency reader device.

[0012] Consistent with other disclosed embodiments, a tangible computer-readable storage medium may store program instructions executable by one or more processors for implementing any of the processes disclosed herein.

[0013] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosed embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments and, together with the description, serve to explain the principles of the present disclosure. In the drawings:

[0015] Figure 1 is a block diagram of an exemplary system consistent with the disclosed embodiments;

[0016] Figures 2A-2C is an illustration of an exemplary transaction card consistent with the disclosed embodiments;

[0017] Figures 3A-3C is a flow chart illustrating incrementing of a temporary identifier consistent with the disclosed embodiments; and

[0018] Figure 4 is a flow chart of an exemplary process for authenticating a user of a transaction card having a multi-state tag, consistent with the disclosed embodiments. DETAILED DESCRIPTION

[0019] Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings and disclosed herein. Wherever convenient, the same reference numerals are used throughout the drawings to refer to the same or like parts.

[0020] In the disclosed embodiments, a user may use a transaction card as a form of authentication when completing a financial transaction on a mobile device. The transaction card may be associated with a financial account held by the user with a financial service provider. Most transaction cards contain a static identifier in one or more RFID tags or other storage components. However, such static identifiers are easily copied by malicious users. The disclosed embodiments implement a transaction card that includes a dynamic polymorphic tag that changes each time the tag is read. Such a dynamic tag is more secure than a traditional static tag and can prevent a malicious user from simply copying and using the tag.

[0021] As used herein, the term "transaction card" refers to any physical card product that is configured to provide information, such as financial information (e.g., card number, account number, account balance, etc.), quasi-financial information (e.g., points balance, discount information, etc.), and / or personal identification information (e.g., name, address, etc.) when read by a reader. Examples of transaction cards include, but are not limited to, credit cards, debit cards, gift cards, points cards, frequent flyer cards, merchant cards, discount cards, and the like. The term "transaction card" may include identification cards, such as passport cards, driver's licenses, entry access cards, or similar documents. The physical characteristics of the transaction card (e.g., size, flexibility, location of various components within the card) may conform to various international standards, including, for example, ISO / IEC 7810, ISO / IEC 7811, ISO / IEC 7812, ISO / IEC 7813, ISO / IEC 7816, ISO 8583, ISO / IEC 4909, and ISO / IEC 14443. For example, according to ISO / IEC 7810, the size of a transaction card may be 85.60 mm (width)*53.98 mm (height)*0.76 mm (thickness).

[0022] Figure 1 1 shows a diagram of an exemplary system 100 consistent with the disclosed embodiments. Figure 1 As shown, the system 100 may include a user device 110, a transaction card 120, a network 130 that facilitates communication between the components of the system 100, and a service provider (SP) device 140. The components and arrangements of the components included in the system 100 may vary. Thus, the system 100 may further include other components that perform or assist in one or more processes consistent with the disclosed embodiments. Figure 1 The components and arrangements shown are not intended to limit the disclosed embodiments, as the components used to implement the processes and features of the disclosure may vary.

[0023] The system 100 may include one or more user devices 110. The user may operate the user device 110, which may be a desktop computer, a laptop computer, a tablet computer, a smartphone, a multi-function watch, a pair of multi-function glasses, a tracking device, or any suitable device with computing capabilities. The user device 110 may include one or more processors and one or more storage devices known to those skilled in the art. For example, the user device 110 may include one or more memory devices storing data and software instructions that, when executed by one or more processors, perform operations consistent with the disclosed embodiments. In one aspect, the user device 110 may have a transaction application installed thereon that enables the user device 110 to communicate with the transaction card 120 or the SP device 140 via the network 130 or other means (e.g., a near field communication device). For example, the user device 110 may be a smartphone or tablet computer or similar device that executes a stored mobile application to perform various electronic transactions, such as authentication operations (e.g., logging into a computer system), banking operations (e.g., fund transfers, purchases, or cash withdrawals), or similar operations. In other embodiments, the user device 110 may be connected to the SP device 140 by using browser software stored and executed by the user device 110. The user device 110 may be configured to execute software instructions to allow the user to access information stored in the SP device 140, such as, for example, private keys or other authentication information, financial information related to recent shopping transactions, financial discounts, financial statements, account information, loyalty points information, etc. In addition, the user device 110 may be configured to execute software instructions that initiate and conduct transactions with the SP device 140 and / or transaction card 120, such as login or authentication on a website or computer, cash withdrawal, wire transfer, PIN reset, or call center transaction.

[0024] The user device 110 may perform one or more operations consistent with the disclosed embodiments. The user device 110 may be operated by a user. In one aspect, the user may be a customer of a financial service provider (e.g., a financial service provider that operates the SP device 140). For example, a financial service provider may maintain a financial service account (e.g., a checking account, a savings account, a debit card account, or a credit card account) for a user of the user device 110. The user device 110 (and / or other items, such as a card, token, key card, or similar item) may access the account to purchase goods, services, or information. Additionally or alternatively, the user device 110 and the financial service account (e.g., via a mobile application installed on the user device 110) may initiate a cash withdrawal from an ATM, contact a customer call center, transfer or wire money, or reset their debit card PIN.

[0025] In some embodiments, user device 110 may include an RFID reader that may use one or more wireless protocols (e.g., near field communication (NFC), BLUETOOTH TM 、BLUETOOTH LE TM The transaction card 120 can be detected by the SP device 140 using a Bluetooth Low Energy (BLE) or Radio Frequency Identification (RFID). As described below, the transaction card 120 can include a polymorphic tag that enables the user to use the transaction card 120 as a factor in a multi-factor authentication process. The user device 110 can read the encrypted value of the tag and a "salt" (i.e., a piece of random data) stored on the transaction card 120 and compare the encrypted value with an expected value stored on the SP device 140.

[0026] The transaction card 120 may be configured to use a BLUETOOTH TM 、BLUETOOTH LE TM (BLE), Wi-Fi, near field communication (NFC) or similar protocols to transmit data. In some embodiments, the transaction card 120 may also include a wireless transmitter, such as an RFID transmitter.

[0027] In some embodiments, the transaction card 120 may include one or more storage devices that store one or more identifiers. For example, the transaction card 120 may store a tag or permanent identifier that can uniquely identify the transaction card 120, and one or more other temporary / rolling identifiers, such as salt values. For example, the transaction card 120 may be configured to store a tag that includes a private key and a salt value, which is incremented each time the user device 110 reads the transaction card 120. The transaction card 120 may store the salt value in a memory (e.g., by overwriting a previously recorded salt value). The transaction card 120 may include an encrypted RFID transmitter configured to send the permanent identifier and the temporary identifier to the user device 110. In some embodiments, the one or more identifiers may be stored in a database accessible to the SP device 120.

[0028] Consistent with the disclosed embodiments, SP device 140 may be a system associated with a website, such as a secure data storage website that stores data and provides data to users. SP device 140 may also be a system associated with a financial service provider (not shown), such as a bank, credit card company, lender, brokerage firm, or any other type of financial service entity that generates, provides, manages, and maintains financial service accounts for one or more users.

[0029] SP device 140 may be implemented as one or more computing systems configured to execute software instructions stored on one or more storage devices to perform one or more operations consistent with the disclosed embodiments. For example, SP device 140 may include one or more storage devices storing data and software instructions, and one or more processors configured to use the data and execute the software instructions to perform server-based functions and operations known to those skilled in the art. SP device 140 may include one or more general-purpose computers, mainframe computers, or any combination of these types of components.

[0030] In some embodiments, SP device 140 may be configured as a specific device, system, etc. based on the storage, execution, and / or implementation of software instructions (causing a processor to perform one or more operations consistent with the disclosed embodiments). SP device 140 may be independent or part of a subsystem, which in turn is part of a larger system. For example, SP device 140 may represent a remotely located distributed server and communicate through a public network (e.g., network 140) or a private network (such as a LAN) of a financial service provider.

[0031] SP device 140 may include or have access to one or more storage devices configured to store data and / or software instructions (used by one or more processors of SP device 140 to perform operations consistent with the disclosed embodiments). For example, SP device 140 may include a memory configured to store one or more software programs (which perform multiple functions when executed by the processor). The disclosed embodiments are not limited to separate programs or computers configured to perform dedicated tasks. For example, SP device 140 may include a memory storing a single program or multiple programs. In addition, SP device 140 may execute one or more programs located remotely from SP device 140. For example, SP device 140 may access one or more remote programs stored in a memory containing remote components, which perform operations consistent with the disclosed embodiments when executed. In some aspects, SP device 140 may include server software that generates, maintains, and provides services related to financial account management. In other aspects, SP device 140 may be connected to a separate one or more servers or similar computing devices that generate, maintain, and provide services associated with financial data for financial service providers associated with SP device 140.

[0032] The SP device 140 may be configured to generate and send an expected value to the user device 110. The expected value may correspond to the transaction card's tag and salted value 120. The SP device 140 may also be connected to a database and may store the generated tag and salted value pairs associated with one or more transaction cards 120.

[0033] The network 130 may include any type of computer networking arrangement for exchanging data. For example, the network 130 may be one or more of the Internet, a dedicated data network, a virtual private network on a public network, a Wi-Fi network, a LAN or WAN network, and / or other suitable connections that enable information exchange between the various components of the system 100. The network 130 may also include a public switched telephone network ("PSTN") and / or a wireless cellular network. The network 130 may be a secure network or an unsecured network. In other embodiments, one or more components of the system 100 may communicate directly via one or more dedicated communication links, such as a link between the user device 110 and the service provider device 140.

[0034] Additionally or alternatively, network 130 may include a direct communication network. Direct communication may use any suitable technology, including, for example, BLUETOOTH. TM 、BLUETOOTH LE TM (BLE), Wi-Fi, near field communication (NFC) or other suitable communication methods, which provide a medium for transmitting data between different devices. In some embodiments, user device 110 can connect and communicate through a direct communication network.

[0035] Other components known to those of ordinary skill in the art may be included in system 100 to process, transmit, provide, and receive information consistent with the disclosed embodiments.

[0036] Figure 2A is a diagram of an exemplary transaction card 200A, which may correspond to a transaction card 120 ( Figure 1 ). The card 200A may include a clock generator 201 , an NFC tag 202 , and an RFID transmitter 203 .

[0037] The clock generator 201 may be configured to initiate a cycle in response to electromagnetic radiation from an RFID reader. For example, the transaction card 200A may include a Javacard chip (including the NFC tag 202) using ISO 14443, so that upon receiving a signal having a frequency of 13.56 mHz from the RFID reader, the clock generator 201 may initiate a cycle. Each time the clock generator 201 initiates a cycle, a counter may be incremented by a preconfigured value unique to the transaction card. Thus, the clock generator 201 may be configured to "time" each read of the transaction card 120 by the RFID reader. The starting value of the counter may also be a unique, preconfigured, non-zero value. The clock generator 201 may be a clock generator circuit of any configuration known to those skilled in the art.

[0038] The NFC tag 202 may be a chip including an antenna and an integrated circuit (IC). In some embodiments, the NFC tag 202 may be an RFID tag. In another embodiment, the NFC tag 202 may be a component of a microchip or a microcontroller that operates via an NFC coil. In some embodiments, the transaction card 200A may include a microchip (e.g., an EMV chip), a communication device (e.g., a near field communication (NFC) antenna, Device, WiFi device), magnetic stripe, barcode, Quick Response (QR) code and / or other devices in addition to or instead of NFC tag 202. In some embodiments, NFC tag 202 can be a component of a Javacard chip operating in accordance with the ISO 14443 standard.

[0039] In some embodiments, the NFC tag 202 may store information including a permanent identifier and a temporary identifier (also referred to as a tag and a salt value, respectively). The permanent identifier may include an identification number that is unique to the user. In some embodiments, the permanent identifier may be an identification code that is unique to the transaction card. In another embodiment, the permanent identifier includes transaction data stored by the NFC tag 202. For example, a merchant ID for the past one, two, three, etc. transactions. In other embodiments, the stored transaction data may include a transaction type, a merchant ID, a transaction amount, or any combination thereof. The temporary identifier may be data, such as a numerical value, attached to the permanent identifier. Upon detecting an electromagnetic signal emitted by an RFID reader (e.g., an RFID reader placed in a mobile device), a current may be induced in the coil of the NFC tag 202, thereby powering the clock generator 201 to initiate a cycle, whereby the temporary identifier increases by a preconfigured increment. The NFC tag 202 then generates an encrypted value of the permanent identifier and the incremented temporary identifier. In some embodiments, the encrypted value may include a hash value of the permanent identifier and the incremented temporary identifier.

[0040] The RFID transmitter 203 may be configured to transmit the encrypted value to a device, such as the user device 110. The RFID transmitter 203 may be part of the NFC tag 202 and may be configured to transmit the encrypted value to the RFID reader in response to a signal received from the reader. The RFID transmitter 203 may further be configured to transmit the encrypted transaction card data to the user device 110.

[0041] For example, refer to Figure 3AIn the first cycle, the NFC tag 202 may detect a signal from an RFID reader, which senses the coil of the NFC tag 202. The NFC tag 202 may provide the power generated by the coil induction to the clock generator 201 (step 301). Each clock cycle starts when power is received from the NFC tag 202. For example, the power supply received from the NFC tag 202 may initiate clock cycle 1, clock cycle 2, ... clock cycle n. In response, the clock generator 201 may return a signal 302 to the NFC tag 202. In step 303, in response to the receipt of the signal 302, the NFC tag 202 may increment the counter 305 by a value N to generate a salt value in the form of a temporary identifier C1. In some embodiments, N may be an integer value. N and / or the initial counter value may be unique to the transaction card 200A. In step 304, the NFC tag 202 may then append the salt value C1 (e.g., counter+N) to the permanent identifier 306 (e.g., tag) and generate an encryption of (PI+C1). The NFC tag 202 may store C1 as the new counter value.

[0042] The above process is repeated each time the NFC tag 202 receives a signal from the RFID reader. At the same time, the SP device 140 may receive an indication from the user device 110 that the mobile application initiated the RFID reader. The SP device 140 may store the permanent identifier, the initial counter value, and the incremented value. The SP device 140 may increment the counter each time it receives information from the user device 110 indicating that the RFID reader is initiated. When the user requests authentication via the user device 110, the device's RFID reader may receive the encrypted value generated by the NFC tag 202 from the RFID transmitter 203 and send the encrypted value to the SP device 140. In order to authenticate the user, the SP device 140 may verify the encrypted value by comparing the encrypted value from the transaction card 200A with the encrypted value generated by the SP device 140.

[0043] In some embodiments, the counter value of the transaction card may not be synchronized with the counter value of the SP device. For example, if the transaction card is not successfully read, the user device 110 may not be able to communicate with the SP device 140 to increment the counter. However, even if the transaction card is not read, the NFC tag 202 may receive a signal from the RFID reader that causes the counter to increment. In some embodiments, if the transaction card 120 is not synchronized with the SP device 140, the SP device 140 may instruct the user via the user device 110 to tap the card to the mobile device 110 a certain number of times, thereby generating a certain number of readings of the card that causes the counter 305 of the card to increment. The SP device 140 may determine that the sequence of encrypted values ​​generated by performing the certain number of taps matches the expected sequence of encrypted values. If the sequence matches, the SP device 140 may cause the user device 110 to send an instruction to the transaction 120 to reset.

[0044] The system may include a threshold number of cycles that the NFC tag 202 and the SP device 140 may be out of sync. For example, a harmless action such as an imperfect card placement or a failed attempt may cause the transaction card and the SP device to be out of sync. A threshold number may be set such that as long as the counter values ​​match within a threshold number of cycles, the user may be authenticated. In this embodiment, if the card's counter value is within the threshold number of cycles, the card's counter value is set to the current counter value of the SP device. In another example, the counters may be out of sync due to fraudulent activity. If the counters do not match within a threshold number of cycles, the authentication request may be denied and a fraud alert may be sent to the user and / or the financial service provider. In addition, this authentication method may prevent fraud because even if the encryption of the permanent identifier and the temporary identifier is copied, the malicious user cannot replay the copied encryption value and cannot be authenticated by the system.

[0045] Figure 2B is a diagram of another example card 200B, which may correspond to a transaction card 120 ( Figure 1 ). The transaction card 200B may include an NFC tag 202 and an RFID transmitter 203 , as well as a real-time clock (RTC) 204 powered by a power source 205 .

[0046] The RTC 204 may be an integrated circuit configured to maintain accurate time. That is, the RTC 204 may cycle once per second, thereby incrementing the stored time. When the NFC tag 202 receives a signal from the RFID reader, the RTC 204 may respond by sending a timestamp to the NFC tag 202, so that the timestamp may be attached to the permanent identifier. In another embodiment, the timestamp may be attached to the value. To enhance user security, the RTC 204 may set a unique start time for each transaction card, so that the timestamp at a given moment is different for each card.

[0047] For example, refer to Figure 3B , upon receiving a reading from the RFID reader and inducing a current in the IC of the NFC tag 202, the NFC tag 202 sends a ping 301 to the RTC 204. In response, the RTC 204 initiates cycle 1 and sends a signal 302 containing a current timestamp, Time 1, to the NFC tag 202. In step 303, the NFC tag 202 appends the current timestamp Time 1 to an identifier 307 unique to the transaction card to generate a salted value C1. In step 304, the NFC tag 202 appends C1 to a permanent identifier 306 associated with the transaction card and generates an encrypted value of PI+C1. In some embodiments, the encrypted value may be a hash value of PI+C1. In some embodiments, the timestamp itself may be a salted value and may be directly appended to the PI 306 without first appending and / or adding to the identifier 307. The generated encrypted value may be compared to the encrypted value of the permanent identifier (generated by the SP device 140) and the timestamp in the first clock cycle. If the encrypted values ​​match, the user may be authenticated. The RTC 204 of the transaction card 200B and the corresponding RTC of the SP device 140 can be synchronized by initiating both RTCs simultaneously. In this embodiment, since the temporary identifier (e.g., salt value) at any given clock cycle is only valid for a short period of time, the authentication through the transaction card 200B is highly secure. For example, the encrypted value can be valid for a predetermined time window, such as 30 seconds, 60 seconds, etc. In some embodiments, in order to account for the drift between the server clock and the RTC 204, the system can accept a certain number of values ​​before and after the currently accepted value. Although using the RTC to generate the salt value is highly secure, the RTC 204 requires a power source 205 (e.g., a battery or other power source) to operate accurately.

[0048] Figure 2C 200C, which may correspond to a transaction card 120 ( Figure 1). The transaction card 200C may include an NFC tag 202 and an RFID transmitter 203, as well as a microprocessor 206 powered by a power source 205 (eg, a battery).

[0049] Microprocessor 206 may be an Intel TM Pentium TM or Xeon TM Series microprocessors, AMD TM Turion TM The microprocessor 206 may be a programmable logic device. The microprocessor 206 may be configured to implement an algorithm such that the counter stored in the NFC tag 202 increments by a different value at each clock cycle.

[0050] Figure 3C is a simplified example of a series of clock cycles. As described above, the NFC tag 202 sends a ping 301 to the microprocessor 206 upon receiving a signal from the RFID reader. The microprocessor 206 responds by sending the result of the algorithm application to X of the NFC tag 202. For example, the microprocessor 206 can be configured as the value X divided by the number of clock cycles. Therefore, in the first clock cycle (cycle 1), the counter 305 increments X / 1 to generate a temporary identifier, such as the salt value C1 (step 303). In cycle 2, the salt value C1 generated during cycle 1 is incremented by X / 2 to generate the salt value C2, and so on. A more complex algorithm can be implemented to generate a temporary identifier at each clock cycle. In step 304, the NFC tag 202 appends the salt value generated in step 303 to the permanent identifier 306 associated with the transaction card, and determines the encrypted value of the permanent identifier 306 and the salt value. Depending on the required complexity, the algorithm stored by the processor can be directly applied to the counter 305. In other embodiments, the result of the algorithm can be a temporary identifier C1. As described above, by verifying the encryption value generated at step 304 with the expected encryption value generated by the SP device 140, the user may be authenticated.

[0051] In some embodiments, if the transaction card 120 is out of sync with the SP device 140, the SP device 140 may send an instruction to the user device 110 to send a signal to the NFC tag 202 to reset the counter. In some embodiments, the user may be required to provide multiple authentication factors before resetting the NFC tag 202. When the NFC tag 202 is reset, the counter or RTC may be set to its initial starting value. In other embodiments, for increased security, the counter or RTC may be set to a value different from the starting value. In another embodiment, the user device 110 may transmit a new algorithm to the microprocessor 206, or may change the counter (see Figure 3A ) increases by an increment.

[0052] Figure 4 is a flow chart describing an exemplary process 400 for authenticating a user using a transaction card with a polymorphic tag.

[0053] In step 401, the system 100 receives an authentication request from the user device 110 at the SP device 140. In some embodiments, the authentication request may be associated with, for example, shopping, transferring money, or paying via a mobile application of a financial service provider. The financial service provider may require one or more factors to authenticate the user. The authentication request may include identification information (such as a user ID, account number, etc.) to associate the user with a transaction card.

[0054] In step 402, the SP device 140 obtains a permanent identifier associated with the transaction card from a memory or database. In some embodiments, the permanent identifier is a private key.

[0055] In step 403, the SP device 140 generates a temporary identifier. The temporary identifier can be used as described above. Figures 3A-3C Any of the methods described can be used to generate

[0056] In step 404, SP device 140 generates an encryption of the permanent identifier and the temporary identifier.

[0057] In step 405, the SP device 140 receives an encrypted value from the user device 110 via the network 130. The encrypted value may be obtained from the transaction card 120 via the RFID reader of the user device 110.

[0058] In step 406, SP device 140 verifies the generated encrypted value based on the received encrypted value. In some embodiments, verification may include a comparison of the encrypted values. If the values ​​are equal, the user may be authenticated. In some embodiments, SP device 140 may store an expected encrypted value associated with one or more clock cycles, up to a threshold number of clock cycles. Thus, in some embodiments, if the received encrypted value matches any of the values, the user may be authenticated.

[0059] In step 407, SP device 140 may transmit an authentication command to a mobile device associated with the user. For example, SP device 140 may transmit via network 130 an instruction that causes the mobile device to complete a transaction requiring user authentication.

[0060] In some embodiments, a transaction card associated with a financial account and used to generate an encrypted value as part of an authentication request is provided. The transaction card may include a radio frequency transmitter; a clock generator coupled to the radio frequency transmitter, the clock generator configured to increment a counter value in response to a wireless read signal received from an external radio frequency reader device; and a near field communication tag coupled to the radio frequency transmitter and storing a permanent identifier and the counter value. The near field communication tag may be configured to, in response to the received read signal,: generate an encrypted value based on the permanent identifier and the counter value; and provide the encrypted value to the radio frequency transmitter for transmission to the external radio frequency reader device.

[0061] The persistent identifier may contain a private key.

[0062] When a clock generator cycle begins, the RF transmitter may be configured to generate a digital signal.

[0063] The clock generator may be configured to increment the counter value by a preconfigured amount when a clock generator cycle begins. The clock generator may also be configured to update the temporary identifier, the numerical value, and the incremented counter value when a clock generator cycle begins. The numerical value may be unique to the transaction card. The near field communication tag may be configured to generate an encrypted value based on the permanent identifier, the counter value, and the numerical value. The near field communication tag may also be configured to store the numerical value after transmission by the radio frequency transmitter.

[0064] In some embodiments, a transaction card may include a radio frequency transmitter; a near field communication tag coupled to the radio frequency transmitter; and a clock coupled to the near field communication tag and powered by a power source. The clock may be configured to send a time value to the near field communication tag in response to a wireless read signal received from the near field communication tag by an external radio frequency reader device. The near field communication tag may be configured to: store a permanent identifier and a time value; and in response to the received read signal to: generate an encrypted value based on the permanent identifier and the time value; and provide the encrypted value to the radio frequency transmitter for transmission to the external radio frequency reader device.

[0065] The power source may include a battery. The power source may provide power to at least one of the radio frequency transmitter or the near field communication tag.

[0066] The time value may include a timestamp from a clock. The time value may include a timestamp and a numeric value unique to the transaction card. The time value may be valid only during a preconfigured time period.

[0067] In another embodiment, a transaction card may include: a radio frequency transmitter; a near field communication tag coupled to the radio frequency transmitter; and a microprocessor coupled to the near field communication tag and powered by a power source. The microprocessor may be configured to calculate an update value in response to a wireless read signal received from an external radio frequency reader device. The near field communication tag may be configured to: store the permanent identifier and the update value, and in response to the received read signal: generate an encrypted value based on the permanent identifier and the update value, and provide the encrypted value to the radio frequency reader for transmission to the external radio frequency transmitter reader device.

[0068] The near field communication tag may be configured to generate a temporary identifier based on the updated value upon transmission by the radio frequency transmitter.

[0069] The microprocessor may be further configured to change the update value between subsequent transmissions. The update value may be calculated based on an algorithm. The algorithm may be unique to the transaction card.

[0070] The transaction card may further include a memory component coupled to the microprocessor.

[0071] Exemplary embodiments of the present disclosure describe systems and methods for authenticating a user having a transaction card containing a polymorphic tag. The above description is presented for purposes of illustration. It is not exhaustive, nor is it limited to the precise forms or embodiments of the present disclosure. Modifications and adaptations of the embodiments will be apparent from consideration of the specification and practice of the disclosed embodiments. For example, the described embodiments include hardware and software, but systems and methods consistent with the present disclosure may be implemented as hardware alone.

[0072] Computer programs based on the written description and methods of this specification are within the skill of software developers. Various programs or program modules can be created using various programming techniques. For example, program parts or program modules can be designed in or with the aid of Java, C, C++, assembly language, or any such programming language. One or more such software parts or modules can be integrated into a computer system, a computer readable medium, or existing communication software.

[0073] In addition, although illustrative embodiments have been described herein, the scope includes any and all embodiments having equivalent elements, modifications, omissions, combinations (e.g., across aspects of different embodiments), adaptations, or variations based on the present disclosure. The elements in the claims are to be interpreted broadly according to the language used in the claims and are not limited to the examples described in this specification or during the prosecution of the application, which examples are to be interpreted as non-exclusive. In addition, the steps in the methods of the present disclosure may be modified in any manner, including by reordering steps or inserting or deleting steps.

[0074] Furthermore, while various aspects of the disclosed embodiments are described in association with data stored in memory and other tangible computer-readable storage media, those skilled in the art will appreciate that these aspects may also be stored and executed on many types of non-transitory computer-readable media, such as secondary storage devices, like hard disks, floppy disks, CD-ROMs, or other forms of RAM and ROM.

[0075] Accordingly, it is intended that the specification and examples be considered as exemplary only, with a true scope and spirit being indicated by the following claims along with their full scope of equivalents.

Claims

1. A transaction card comprising: Radio frequency transmitters; a clock generator coupled to the radio frequency transmitter and having a dynamic frequency configured to have a period begin when the transmitter is transmitting and a period end when the transmitter is not transmitting; as well as A near field communication tag is coupled to the clock generator and stores a permanent identifier and a temporary identifier, the temporary identifier including a numerical value and a counter value.

2. The transaction card according to claim 1, wherein: The permanent identifier includes a private key.

3. The transaction card of claim 1, wherein: The radio frequency transmitter is configured to generate a digital signal when a cycle of the clock generator begins.

4. The transaction card of claim 1, wherein: The near field communication tag is configured to increment the counter by a preconfigured amount when the clock generator cycle begins.

5. The transaction card of claim 4, wherein: The near field communication tag is configured to update the temporary identifier, the numerical value, and the incremented counter value when a clock generator cycle begins.

6. The transaction card of claim 1, wherein: The value is unique to the transaction card.

7. The transaction card of claim 1, wherein: The near field communication tag is configured to generate an encryption of the permanent identifier and the temporary identifier.

8. The transaction card of claim 4, wherein: The near field communication tag is configured to store the temporary identifier after transmission by the radio frequency transmitter.

9. A transaction card comprising: Radio frequency transmitters; a near field communication tag coupled to the radio frequency transmitter; as well as a real-time clock coupled to the near field communication tag and powered by a power source, wherein: The near field communication tag is configured to store a permanent identifier and a temporary identifier; The near field communication tag is configured to cause the temporary identifier to increment a value of the real time clock upon transmission by the radio frequency transmitter.

10. The transaction card of claim 9, wherein: The power source includes a battery.