System for and method of authentication dedicated for safe reading

Abstract

To provide a transaction card for authentication of a user with a portable device having a memory including instructions and a processor communicating with a network.SOLUTION: A system according to the present invention has a processor of a service provider device which accepts an authentication request from a suer device, acquires a permanent identifier associated with a transaction card from a database, generates a temporary identifier associated with the transaction card, encrypts the permanent identifier and the temporary identifier to generate an encrypted value, verifies an expected value for the encrypted value accepted from a portable device, and executes stored instructions to transmit authentication commands to the portable device.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The disclosed embodiments relate generally to authenticating account cards, and more particularly to authenticating account cards using synchronized counters.

[0002] (Related Applications) This application claims priority to U.S. patent application Ser. No. 16 / 014,542, filed June 21, 2018, the entire disclosure of which is incorporated herein by reference. [Background technology]

[0003] Many interactions on computer systems, such as authenticated logins and other transaction-based processes, are insecure. For example, when attempting to log in to a website on a computer, the website may require a username and password. Anyone with that set of information, whether an authorized user or a malicious user, can use the website for any purpose. To address this concern, some transactions require multi-factor authentication, often referred to as "what you know and what you have." For example, when logging in to a website, the website may require a username and password combination ("what you know") along with a six-digit number displayed on an electronic device ("what you have") or a fingerprint scan ("who you are"). This six-digit number, 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 store information that allows a credit card processor to know whether the card is physically present in the user's hand. For example, a card may have a card number printed on the front ("what you know"), while some information may only exist as part of the EMV chip ("what you have"). Certain devices may read information from the EMV chip for contactless authentication of the user. Some devices allow for multi-factor authentication using "what you know" and "who you are." For example, biometric authentication such as facial recognition, fingerprint authentication, or iris scanning is possible.

[0004] Currently, the EMV protocol relies on two-way communication between an EMV chip on a transaction card and a payment terminal, such as a point of sale (POS). 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 sends the signed information back to the payment terminal for verification. However, many devices and / or operating systems do not support two-way communication and therefore cannot complete transactions with EMV-enabled transaction cards.

[0005] Due to these and other drawbacks associated with authentication using two-way communication protocols, there is a need for techniques that enable secure read-only authentication. Summary of the Invention

[0006] Consistent with disclosed embodiments, a transaction card is provided for generating an encrypted value associated with a financial account as part of an authentication request. The transaction card includes a radio frequency transmitter, a clock generator coupled to the radio frequency transmitter and configured to increment a counter value in response to a radio 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 persistent identifier and the counter value. The near field communication tag may be configured to generate the encrypted value based on the persistent identifier and the counter value in response to the received read signal and provide the encrypted value to the radio frequency transmitter for transmission to the external radio frequency reader device.

[0007] Consistent with another disclosed embodiment, a transaction card is provided for generating an encrypted value associated with a financial account 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 transmit a time value to the near field communication tag in response to a radio 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 persistent identifier and the time value, generate an encrypted value based on the persistent identifier and the time value in response to the received read signal, and provide the encrypted value to the radio frequency transmitter for transmission to the external radio frequency reader device.

[0008] Consistent with another disclosed embodiment, a transaction card is provided for generating an encrypted value associated with a financial account 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 microprocessor coupled to the near field communication tag and powered by a power source. The microprocessor may be configured to calculate an updated 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 a persistent identifier and an updated value, generate an encrypted value based on the persistent identifier and the updated value in response to the received read signal, and provide the encrypted value to the radio frequency transmitter for transmission to the external radio frequency reader device.

[0009] Consistent with another disclosed embodiment, a tangible computer-readable storage medium may store program instructions executable by one or more processors to perform any of the processes disclosed herein.

[0010] 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 explanation of the drawings]

[0011] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments and, together with the detailed description, serve to explain the disclosed principles. [Figure 1] 1 is a block diagram of an exemplary system consistent with disclosed embodiments. [Figure 2A] 1 is a diagram of an exemplary transaction card consistent with disclosed embodiments; [Figure 2B] 1 is a diagram of an exemplary transaction card consistent with disclosed embodiments; [Figure 2C] 1 is a diagram of an exemplary transaction card consistent with disclosed embodiments; [Figure 3A] 1 is a flowchart illustrating temporary identifier incrementation consistent with disclosed embodiments. [Figure 3B] 1 is a flowchart illustrating temporary identifier incrementation consistent with disclosed embodiments. [Figure 3C] 1 is a flowchart illustrating temporary identifier incrementation consistent with disclosed embodiments. [Figure 4] 1 is a flowchart of an exemplary process for authenticating a user with a transaction card having a polymorphic tag, consistent with a disclosed embodiment. DETAILED DESCRIPTION OF THE INVENTION

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

[0013] In the disclosed embodiments, a user can use a transaction card as a form of authentication when completing a financial transaction on a mobile device. The transaction card can be associated with a financial account the user holds with a financial services provider. Most transaction cards include a static identifier in one or more RFID tags or other storage elements. However, such static identifiers are easily cloned by malicious users. The disclosed embodiments provide a transaction card that includes a dynamic, polymorphic tag that changes each time the tag is read. This dynamic tag is more secure than traditional static tags, preventing malicious users from simply cloning and using the tag.

[0014] As used herein, the term "transaction card" refers to any physical card product configured to provide information such as financial information (e.g., card number, account number, account balance, etc.), quasi-financial information (e.g., rewards balance, discount information, etc.), and / or personally identifying information (e.g., name, address, etc.) when the card is swiped by a card reader. Examples of transaction cards include, but are not limited to, credit cards, debit cards, gift cards, loyalty cards, frequent flyer cards, merchant-specific cards, discount cards, etc. The term "transaction card" may include identification cards such as passport cards, driver's licenses, entry point access cards, etc. The physical characteristics of a transaction card (e.g., size, flexibility, location of various elements included on the card, etc.) may meet various international standards such as 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, a transaction card may have dimensions, as specified by ISO / IEC 7810, of 85.60 mm (width) x 53.98 mm (height) x 0.76 mm (thickness).

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

[0016] The system 100 may include one or more user devices 110. A user may operate the user device 110, which may be a desktop computer, laptop, tablet, smartphone, multifunction watch, multifunction eyeglasses, tracking device, or any suitable device with computing capabilities. The user device 110 may include one or more processors and memory devices known to those skilled in the art. For example, the user device 110 may include a memory device that stores data and software instructions that, when executed by the 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, enabling 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 that runs 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), etc. In other embodiments, the user device 110 may connect 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 that allow a user to access information stored on the SP device 140, such as private keys or other authentication information, financial information related to recent purchase transactions, financial discounts, financial statements, account information, loyalty program information, etc. Additionally, the user device 110 may be configured to execute software instructions to initiate and execute transactions with the SP device 140 and / or transaction card 120, such as logging in or authenticating with a website or computer, cash withdrawals, wire transfers, PIN resets, or call center transactions.

[0017] The user device 110 may perform one or more operations consistent with 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., the financial service provider operating the SP device 140). For example, the financial service provider may maintain financial services accounts (e.g., checking accounts, savings accounts, debit card accounts, or credit card accounts) for the user of the user device 110. The user device 110 (and / or other items, such as cards, tokens, key fobs, etc.) may access such accounts to facilitate the purchase of goods, services, or information. Additionally or alternatively, the user device 110 and financial services accounts (e.g., via a mobile application installed on the user device 110) may initiate cash withdrawals from ATMs, contact customer call centers, transfer or wire funds, or reset PINs for their debit accounts.

[0018] In some embodiments, user device 110 may include an RFID reader that can detect transaction card 120 using one or more wireless protocols (e.g., Near Field Communication (NFC), BLUETOOTH®, BLUETOOTH LE® (BLE), Radio Frequency Identification (RFID)). As described below, transaction card 120 may include a polymorphic tag that allows a user to use transaction card 120 as a factor in a multi-factor authentication process. User device 110 may read the encryption of the tag and a "salt," i.e., random data, stored on transaction card 120 and compare the encryption to an expected value stored in SP device 140.

[0019] Transaction card 120 may be configured to transmit data using protocols such as BLUETOOTH®, BLUETOOTH LE® (BLE), Wi-Fi, Near Field Communication (NFC), etc. In some embodiments, transaction card 120 may also include a wireless transmitter, for example, an RFID transmitter.

[0020] In some embodiments, transaction card 120 may include one or more memory devices that store one or more identifiers. For example, transaction card 120 may store a tag or permanent identifier that uniquely identifies transaction card 120, as well as one or more other temporary / rolling identifiers, such as a salt value. For example, transaction card 120 may be configured to store a tag that includes a secret key and a salt that is incremented each time transaction card 120 is read by user device 110. Transaction card 120 may store the salt in memory (e.g., by overwriting a previously stored salt). Transaction card 120 may include an RFID transmitter configured to transmit encryption of the permanent and temporary identifiers to user device 110. In some embodiments, the one or more identifiers may be stored in a database accessible to SP device 120.

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

[0022] SP device 140 may be implemented as one or more computing systems configured to execute software instructions stored in one or more memory devices to perform one or more operations consistent with the disclosed embodiments. For example, SP device 140 may include one or more memory devices that store 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 elements.

[0023] In particular embodiments, SP device 140 may be configured as a particular apparatus, system, etc. based on storing, executing, and / or implementing software instructions that cause a processor to perform one or more operations consistent with the disclosed embodiments. SP device 140 may be standalone or may be part of a subsystem, which is part of a larger system. For example, SP device 140 may represent distributed servers that communicate over a large distance, either a public network (e.g., network 140) or a private network such as a LAN for a financial services provider.

[0024] The 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 the SP device 140 to perform operations consistent with the disclosed embodiments. For example, the SP device 140 may include memory configured to store one or more software programs that, when executed by a processor, perform certain functions. The disclosed embodiments are not limited to separate programs or computers configured to perform dedicated tasks. For example, the SP device 140 may include memory storing a single program or multiple programs. Furthermore, the SP device 140 may execute one or more programs located remotely from the SP device 140. For example, the SP device 140 may access one or more remote programs stored in memory included in a remote component that, when executed, performs operations consistent with the disclosed embodiments. In certain aspects, the SP device 140 may include server software that generates, maintains, and provides services associated with financial account management. In other aspects, the SP device 140 may connect to a separate server or similar computing device that generates, maintains, and provides services associated with financial data for a financial service provider associated with the SP device 140.

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

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

[0027] Additionally or alternatively, network 130 may include a direct communication network. Direct communication may use any suitable technology, including, for example, BLUETOOTH, BLUETOOTH LE (BLE), Wi-Fi, Near Field Communication (NFC), or other suitable communication method that provides a medium for transmitting data between separate devices. In particular embodiments, user devices 110 may connect and communicate via a direct communication network.

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

[0029] 2A is a diagram of an exemplary transaction card 200A that may correspond to transaction card 120 (FIG. 1) consistent with disclosed embodiments. Card 200A may include clock generator 201, NFC tag 202, and RFID transmitter 203.

[0030] The clock generator 201 may be configured to cycle in response to electromagnetic radiation from an RFID reader. For example, transaction card 200A may include a Java Card chip that includes an NFC tag 202 using ISO 14443, such that clock generator 201 may cycle upon receiving a signal having a frequency of 13.56 mHz from the RFID reader. Each time clock generator 201 cycles, a counter may increment by a preset value that is unique to the transaction card. Thus, clock generator 201 may be configured to "clock" each time the RFID reader reads transaction card 120. The counter's starting value may be a unique, preset, non-zero value. Clock generator 201 may be any implementation of a clock generator circuit known to those skilled in the art.

[0031] 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 other embodiments, the NFC tag 202 may be a component of a microchip or 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, a BLUETOOTH® device, a WiFi device), a magnetic strip, a barcode, a quick response (QR) code, and / or other devices in addition to or instead of the NFC tag 202. In some embodiments, the NFC tag 202 may be a component of a JavaCard chip that operates under the ISO 14443 standard.

[0032] In some embodiments, the NFC tag 202 can store information including a permanent identifier and a temporary identifier, also referred to as a tag and a salt, respectively. The permanent identifier may include an identification number unique to a user. In some embodiments, the permanent identifier may be an identification number unique to a transaction card. In another embodiment, the permanent identifier includes transaction data stored by the NFC tag 202. For example, merchant IDs for the last one, two, three, etc. transactions. In other embodiments, the stored transaction data may include transaction type, merchant ID, transaction amount, or any combination thereof. The temporary identifier may be data, such as a numeric value, that may be appended to the permanent identifier. Upon detecting an electromagnetic signal emitted from an RFID reader, for example, an RFID reader located on a mobile device, a current may be induced in the coil of the NFC tag 202, which powers and cycles the clock generator 201, increasing the temporary identifier by a preset increment. The NFC tag 202 then generates an encryption of the permanent identifier and the incremented temporary identifier. In some embodiments, the encryption may include a hash of the persistent identifier and the incremented temporary identifier.

[0033] 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 an RFID reader in response to a signal received from the reader. The RFID transmitter 203 may be further configured to transmit the encrypted transaction card data to the user device 110.

[0034] For example, referring to FIG. 3A , in a first cycle, the NFC tag 202 may detect a signal from the RFID reader that induces a coil in the NFC tag 202. The NFC tag 202 may supply power generated by the induction of the coil to the clock generator 201 (step 301). Each clock cycle begins upon receiving power from the NFC tag 202. For example, receipt of a supply of power 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 receiving the signal 302, the NFC tag 202 may increment a counter 305 by a value N to generate a salt 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. Next, in step 304, the NFC tag 202 may append this salt C1, e.g., counter+N, to a persistent identifier 306, e.g., tag, to generate an encryption of (PI+C1). The NFC tag 202 may store C1 as the new counter value.

[0035] The above process is repeated each time the NFC tag 202 receives a signal from the RFID reader. In parallel, the SP device 140 may receive an indication from the user device 110 that a mobile application has activated the RFID reader. The SP device 140 may store a persistent identifier, an initial counter value, and an increment value. The SP device 140 may increment the counter each time information indicating that the RFID reader has been activated is received from the user device 110. When a user requests authentication via the user device 110, the device's RFID reader may receive an encrypted value generated by the NFC tag 202 from the RFID transmitter 203 and transmit the encrypted value to the SP device 140. 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.

[0036] In some embodiments, the transaction card counter value may become out of sync with the SP device counter value. For example, if the transaction card is not successfully swiped, the user device 110 may not communicate with the SP device 140 to increment the counter. However, even if the transaction card is not swiped, the NFC tag 202 may receive a signal from the RFID reader and increment the counter. In some embodiments, if the transaction card 120 is out of sync with the SP device 140, the SP device 140 may instruct the user, via the user device 110, to tap the card against the mobile device 110 a specific number of times, thereby generating a specific number of reads to increment the card counter 305. The SP device 140 may determine that the sequence of encrypted values ​​generated by performing the specific number of taps matches the expected sequence of encrypted values. If the sequences match, the SP device 140 may cause the user device 110 to send a reset instruction to the transaction 120 to reset.

[0037] The system may include a threshold number of cycles within which the NFC tag 202 and the SP device 140 may be out of sync. For example, harmless actions such as suboptimal card placement or aborted attempts may cause the transaction card and SP device to become out of sync. The threshold number may be set so that the user can be authenticated as long as the counter values ​​match within the threshold number of cycles. In this embodiment, the card's counter value is set as the SP device's current counter value if the counter value is within the threshold number of cycles. In another example, the counters may become out of sync as a result of fraudulent activity. If the counters do not match within the threshold number of cycles, the authentication request may be rejected and a fraud alert may be sent to the user and / or financial service provider. Furthermore, this authentication method protects against fraud because even if the encryption of the persistent and temporary identifiers is duplicated, a malicious user could replay the duplicated encrypted values ​​and not be authenticated by the system.

[0038] 2B is a diagram of another exemplary card 200B that may correspond to transaction card 120 (FIG. 1) consistent with disclosed embodiments. 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.

[0039] The RTC 204 may be an integrated circuit configured to keep accurate time. That is, the RTC 204 may cycle every 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 can be added to the persistent identifier. In another embodiment, the timestamp may be added to a numeric value. To enhance user security, the RTC 204 may be set to a unique start time for each transaction card, so that the timestamp for a particular moment in time is different for each card.

[0040] 3B , upon receiving a read from an RFID reader and inducing a current in the NFC tag 202's IC, the NFC tag 202 sends a ping 301 to the RTC 204. In response, the RTC 204 begins cycle 1 and sends a signal 302 to the NFC tag 202 that includes the current timestamp, Time 1. The NFC tag 202 appends the current timestamp, Time 1, to the transaction card's unique identifier 307 to generate a salt C1 in step 303. In step 304, the NFC tag 202 appends C1 to the persistent identifier 306 associated with the transaction card to generate an encrypted value of PI+C1. In some embodiments, the encrypted value may be a hash of PI+C1. In some embodiments, the timestamp may itself be the salt and may be appended directly to PI 306 without first being appended and / or added to the identifier 307. The generated encrypted value may be compared to the encrypted value of the persistent identifier and the timestamp at the first clock cycle generated by the SP device 140. 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 may be synchronized by simultaneously starting both RTCs. In this embodiment, authentication by the transaction card 200B is highly secure because the temporary identifier, e.g., salt, at any given clock cycle is only valid for a short period of time. For example, the encrypted value may be valid for a predetermined time frame, e.g., 30 seconds, 60 seconds, etc. In some embodiments, to account for drift between the server clock and the RTC 204, the system may accept a predetermined number of numbers before and after the currently accepted value. While using an RTC to generate the salt is highly secure, the RTC 204 requires a power source 205, e.g., a battery or other power source, to operate accurately.

[0041] 2C is a diagram of yet another exemplary card 200C that may correspond to transaction card 120 (FIG. 1) consistent with disclosed embodiments. 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, e.g., a battery.

[0042] Microprocessor 206 may be, for example, a microprocessor from the Pentium® or Xeon™ families manufactured by Intel™, the Turion™ family manufactured by AMD™, or any of various processors manufactured by Sun Microsystems. In other embodiments, microprocessor 206 may be a programmable logic device. Microprocessor 206 may be configured to execute an algorithm such that a counter stored by NFC tag 202 is incremented by a different value on each clock cycle.

[0043] 3C is a simplified example of a series of clock cycles. As described above, when NFC tag 202 receives a signal from an RFID reader, it sends a ping 301 to microprocessor 206. Microprocessor 206 responds by sending the result of applying an algorithm to X to NFC tag 202. For example, microprocessor 206 may be configured to divide value X by the number of clock cycles. Thus, in the first clock cycle, cycle 1, counter 305 is incremented by X / 1 to generate temporary identifier C1, e.g., a salt (step 303). In cycle 2, salt C1 generated in cycle 1 is incremented by X / 2 to generate salt C2, and so on. More complex algorithms may be executed to generate temporary identifiers at each clock cycle. In step 304, NFC tag 202 appends the salt generated in step 303 to persistent identifier 306 associated with the transaction card to determine encrypted values ​​for persistent identifier 306 and the salt. Depending on the desired complexity, the algorithm stored in the processor may be applied directly to the counter 305. In other embodiments, the result of the algorithm may be a temporary identifier C1. As mentioned above, the user may be authenticated by verifying the encrypted value generated in step 304 with the expected encrypted value generated by the SP device 140.

[0044] In some embodiments, if the transaction card 120 and the SP device 140 are out of sync, the SP device 140 may send instructions 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 some 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 added security, the counter or RTC may be set to a value different from the starting value. In another embodiment, the user device 110 may send a new algorithm to the microprocessor 206 or change the increment by which the counter (see FIG. 3A ) increases.

[0045] FIG. 4 is a flow chart illustrating an example process 400 for authenticating a user using a transaction card with a polymorphic tag.

[0046] In step 401, the system 100 receives, at the SP device 140, a request for authentication from a user device 110. In some embodiments, the authentication request may be made in connection with, for example, a purchase, transfer, or payment via a financial services provider's mobile application. The financial services provider may require one or more factors to authenticate the user. The authentication request may include identifying information, such as a user ID, account number, etc., to associate the user with a transaction card.

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

[0048] In step 403, the SP device 140 generates a temporary identifier. The temporary identifier can be generated using any of the methods described above with reference to Figures 3A-3C.

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

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

[0051] In step 406, SP device 140 verifies the generated encrypted value against the received encrypted value. In some embodiments, the verification may include comparing the encrypted values. If the values ​​are equal, the user may be authenticated. In some embodiments, SP device 140 may store expected encrypted values ​​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 either value, the user may be authenticated.

[0052] In step 407, the SP device 140 may send an authentication command to a portable device associated with the user. For example, the SP device 140 may send instructions over the network 130 to the portable device to complete a transaction that requires authentication by the user.

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

[0054] The persistent identifier may include a private key.

[0055] The radio frequency transmitter may be configured to generate a digital signal when the clock generator performs a cycle.

[0056] The clock generator may be configured to increment the counter value by a preset amount when the clock generator performs a cycle. The clock generator may also be configured to update the temporary identifier, the numerical value, and the incremented counter value when the clock generator performs a cycle. 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 persistent identifier, the counter value, and the numerical value. The near field communication tag may be configured to store the numerical value after transmission by the radio frequency transmitter.

[0057] 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 transmit a time value to the near field communication tag in response to a radio 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 persistent identifier and the time value, generate an encrypted value based on the persistent identifier and the time value in response to the received read signal, and provide the encrypted value to the radio frequency transmitter for transmission to the external radio frequency reader device.

[0058] The power source may comprise a battery. The power source may power at least one of the radio frequency transmitter or the near field communication tag.

[0059] The time value may include a clock timestamp. The time value may include a timestamp and a numeric value unique to the transaction card. The time value may be valid for a preset period of time.

[0060] In another embodiment, a 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 may be configured to calculate an update value in response to a radio read signal received from an external radio frequency reader device. The near field communication tag may be configured to store a persistent identifier and the update value, generate an encrypted value based on the persistent identifier and the update value in response to the received read signal, and provide the encrypted value to the radio frequency transmitter for transmission to the external radio frequency reader device.

[0061] The near field communications tag may be configured to increment the temporary identifier by one of a plurality of update values ​​when the radio frequency transmitter is transmitting.

[0062] The microprocessor may be further configured to change the plurality of updated values ​​between subsequent transmissions. The plurality of updated values ​​may be calculated based on an algorithm. The algorithm may be specific to a user associated with the transaction card.

[0063] The transaction card may further include a memory element coupled to the microprocessor.

[0064] Exemplary disclosed embodiments describe systems and methods for authenticating users with transaction cards that include polymorphic tags. The foregoing description is presented for illustrative purposes. It is not exhaustive and is not limited to the precise form or embodiment disclosed. Modifications and adaptations of the embodiments will be apparent from consideration of the specification and practice of the disclosed embodiments. For example, while the described implementations include both hardware and software, systems and methods consistent with this disclosure can be implemented solely in hardware.

[0065] Computer programs based on this detailed description and the methods of this specification are within the skill of software developers. The various programs or program modules can be created using a variety of programming techniques. For example, program sections or program modules can be designed in or using Java, C, C++, assembly language, or any such programming language. One or more of such software sections or modules can be integrated into a computer system, computer-readable medium, or existing communications software.

[0066] Furthermore, although exemplary embodiments are described herein, the scope includes any and all embodiments having equivalent elements, variations, omissions, combinations (e.g., of aspects across various embodiments), adaptations, or modifications based on this disclosure. Claim elements should be interpreted broadly based on the language used in the claims and not limited to the examples described herein or during prosecution of the application. These examples should be construed as non-exclusive. Furthermore, the steps of the disclosed methods can be modified in any manner, including rearranging steps or inserting or deleting steps.

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

[0068] Therefore, 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 and their full scope of equivalents.

Claims

1. A computing system for authenticating users using transaction cards, Includes a service provider device including a processor and memory, The service provider device, From the user device, via the network, the received encrypted value generated by the transaction card is received. Based on the generated counter value and the private key associated with the transaction card, an encrypted value is generated. The user is authenticated based on a comparison between the generated encrypted value and the received encrypted value. Computing system.

2. The service provider device includes a plurality of distributed servers, The computing system according to claim 1.

3. The aforementioned multiple distributed servers communicate via a public network. The computing system according to claim 2.

4. The aforementioned multiple distributed servers communicate via a dedicated network. The computing system according to claim 2.

5. The service provider device further, The user device receives a signal, In response to the aforementioned signal, the generated counter value is reset to the initial counter value. It is configured in such a way. The computing system according to claim 1.

6. The service provider device further, The user device receives a signal, In response to the aforementioned signal, the generated counter value is reset to a value different from the initial counter value. It is configured in such a way. The computing system according to claim 1.

7. Authenticating the user enables at least one selected from the group of actions: completion of a transaction, login or authentication using a website or device, cash withdrawal, wire transfer, PIN reset, and call center transactions. The computing system according to claim 1.

8. The aforementioned transaction card is further provided, The aforementioned transaction card is A transaction card memory device that stores counter values ​​and persistent identifiers, A transaction card processor that can utilize the counter value and the persistent identifier, A near-field communication (NFC) transmitter configured to transmit to the user device, Equipped with, The computing system according to claim 1.

9. The aforementioned transaction card is The counter value is increased by a pre-set value specific to the transaction card. The persistent identifier is encrypted using the increased counter value to generate the received encrypted value. The encrypted value received is provided to the NFC transmitter for transmission to the user device. It is configured in such a way. The computing system according to claim 8.

10. The transaction card is further configured to increment the counter value by a different value each time. The computing system according to claim 9.

11. The encrypted value includes the hash of the persistent identifier and the incremented counter value. The computing system according to claim 9.

12. The transaction card is further configured to increment the counter value after receiving a signal from the user device. The computing system according to claim 9.

13. The persistent identifier includes a numerical value unique to the transaction card. The computing system according to claim 9.

14. The aforementioned transaction card further, The system is configured to reset the counter value in response to a signal received from the user device. The computing system according to claim 9.

15. The aforementioned counter value is reset to the initial counter value. The computing system according to claim 14.

16. The aforementioned counter value is reset to a value different from the initial counter value. The computing system according to claim 14.

17. A method for authenticating a user using a transaction card, A service provider device, including a processor and memory, receives encrypted values ​​generated by a transaction card from a user device via the network. The service provider device generates an encrypted value based on the generated counter value and the private key associated with the transaction card, and The service provider device authenticates the user based on a comparison between the generated encrypted value and the received encrypted value. including, method.

18. Furthermore, prior to receiving the encrypted value received, the service provider device includes receiving an authentication request from the user device via the network, The method according to claim 17.

19. Furthermore, the service provider device includes generating the generated counter value in response to the authentication request, The method according to claim 18.

20. A non-temporary computer-readable medium containing instructions for execution by a service provider device, When the above instruction is executed, the service provider device will be instructed to: Receiving encrypted values ​​generated by the transaction card from the user device via the network. To generate an encrypted value based on the generated counter value and the private key associated with the transaction card, and Authenticate the user based on a comparison between the generated encrypted value and the received encrypted value. To execute a process that includes A non-temporary computer-readable medium.

Images